Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424
Date: Mon, 20 Mar 2017 21:19:45
Message-Id: 1490044756.1400.4.camel@gentoo.org
In Reply to: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 by Alexis Ballier
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies