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

[Alexis Ballier]

On Mon, 20 Mar 2017 22:19:16 +0100
Michał Górny <mgorny@g.o> wrote:

> 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!

Since you still seem to fail to understand the difference, there's
nothing I can do for you there. Feel free to convince maintainers, get
them kicked if you fail to persuade them, or fork gentoo if you can't
get them kicked. Nice team work.