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