On pon, 2017-03-20 at 22:12 +0100, Alexis Ballier wrote: > On Mon, 20 Mar 2017 19:24:58 +0100 > Michał Górny <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
