On 03/21/2017 10:17 AM, Alexis Ballier wrote: > On Tue, 21 Mar 2017 09:43:37 +0100 > Kristian Fiskerstrand <k...@gentoo.org> 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. [b] to the extent more review isn't becoming the de-facto way forwards for all ebuilds anyways (we'd need better tooling) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
