Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Michał Górny]

On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote:
> On Mon, 20 Mar 2017 19:24:58 +0100
> Michał Górny <mgorny@g.o> wrote:
>
> > On pon, 2017-03-20 at 18:01 +0100, Alexis Ballier wrote:
> > > What makes me wonder more are the proposed solutions: So far the
> > > only proposals I've seen are either inlining *all* the code or
> > > moving *all* the code into an eclass. Having a quick look at
> > > autoconf, it seems to me an intermediate solution would work
> > > perfectly fine for the above goals/rules: Put main.eblit into an
> > > eclass. The loading code then would access $FILESDIR only in src_*
> > > phases. This would likely work better for all parties and would
> > > allow to focus on better specifying this gray area of PMS instead.
> >
> > Don't you find it a bad hypocritical that at the same time you oppose
> > committing an eclass for a single package and you support committing
> > an eclass to support half-working hack for a single package?
> >
>
> First, I don't oppose committing an eclass for a single package, I
> consider it out of scope of eclasses, that's all.
>
> But even if I had stronger positions, this one looks like a win-win
> situation to me: From a code reuse POV, it is an aberration to have
> packages reinvent eblit include logic, each of them having or having
> had its different flaws. Still from a code reuse POV, the eclass being
> able to export functions would reduce ebuild boilerplate code, an
> eblit eclass could test the presence of eblit code and call default if
> absent. From a QA POV, eblit functions can die horribly if called
> outside of src_* phases, ensuring PMS assumptions hold and making
> everyone happy.

From a code reuse POV, it is an aberration to have an eclass that
reinvents eclass include logic, having or having had flaws. Still from
a code reuse POV, the package manager being able to export functions
would reduce eclass boilterplate code, a package manager could look for
EXPORT_FUNCTIONS and call default if absent. From a QA POV, eclass can
work properly if called outside of src_* phases, ensuring PMS
assumptions hold and making everyone happy.

...oh wait, we already have that!

> And finally, ebuild code for the libc used by 99% of our users,
> supporting cross-compilers, canadian crosses and what else wouldn't be
> something I'd call a 'half-working hack'.

Especially when it ends up with users reporting things like 'pkg_*
phases are not being called'.

-- 
Best regards,
Michał Górny