On Tue, 21 Mar 2017 10:41:58 +0100 Kristian Fiskerstrand <[email protected]> wrote:
> On 03/21/2017 10:17 AM, Alexis Ballier wrote: > > On Tue, 21 Mar 2017 09:43:37 +0100 > > Kristian Fiskerstrand <[email protected]> wrote: > > > > (up to discussion ofc) > > > > Pros for eblits vs the above eclasses: > > - Let eclass/, which is a toplevel directory, be a place for code > > useful to several packages, not a random dump of whatever people > > want to share between ebuilds of the same package (yes, I'm looking > > at you toolchain or apache2.eclass :) ). > > - Eblits being in package directory, repoman checks can be extended > > to look there. > > - Have a guarantee that eblits are specific to a single package and > > cannot "leak" to others by mistake: It greatly simplifies changing > > and updating them. > > - Eblits can be versionned, just the same as ebuilds or eclasses, > > but old versions have a life expectancy more of the order of an > > ebuild than that of an eclass. "Newborn" eblits would be expected > > to be much more frequent than eclasses but less frequent than > > ebuilds. > > - Eblits being per-package they'd obey to package rules, not eclass > > rules wrt additions, removals, api-preservation, etc. > > This would be a policy question more than a technical one; we could > decide e.g on a package-namespace[a] for eclasses following similar > laxer rules[b]. > > > > > Cons: > > - Need a new, somewhat redundant, mechanism. > > - Can be done without new EAPI but is then restricted to src_* > > phases. > > - Very few consumers at the moment (though, considering the current > > crusade that's not really a relevant metric to me). > > > > Endnotes: > [a] without changing any PMS (since review requirement is gentoo > specific) it could be done by namespacing using hyphen or whatnot > instead of separate directory. yes, that's the naming i suggested in the part you cut :) but then you'd need boilerplate duplicated code to ensure nothing but the dedicated package can use that, and still, this doesn't rule out overlays: you can atomically change cat/pkg/*.ebuild, cat-pkg.eclass, but then an overlay with cat/pkg and ::gentoo as master will break if it didn't copy cat-pkg.eclass. with eblits in e.g. $FILESDIR, $FILESDIR points to the overlay's location so it is clear that changing it in ::gentoo wont affect the overlay. (that's probably something to add to the 'pros' section too actually) I'm one of those that believe "if you exposed an API, then it becomes public and you have to maintain that properly; no matter if there are obvious consumers or not, since the possibility exists you have to account for that", which is what happens with every eclass wrt overlays.
