| 1 |
On 03/21/2017 11:00 AM, Alexis Ballier wrote: |
| 2 |
> On Tue, 21 Mar 2017 10:41:58 +0100 |
| 3 |
> Kristian Fiskerstrand <k_f@g.o> wrote: |
| 4 |
> |
| 5 |
|
| 6 |
|
| 7 |
> yes, that's the naming i suggested in the part you cut :) |
| 8 |
|
| 9 |
Indeed |
| 10 |
|
| 11 |
> |
| 12 |
> but then you'd need boilerplate duplicated code to ensure nothing but |
| 13 |
> the dedicated package can use that, and still, this doesn't rule out |
| 14 |
|
| 15 |
Or just a policy, technical solutions isn't needed for everything, and |
| 16 |
it'd make it explicit that should not be depended on by others so can't |
| 17 |
complain about breakages etc. |
| 18 |
|
| 19 |
> overlays: you can atomically change cat/pkg/*.ebuild, cat-pkg.eclass, |
| 20 |
> but then an overlay with cat/pkg and ::gentoo as master will break if |
| 21 |
> it didn't copy cat-pkg.eclass. |
| 22 |
> |
| 23 |
> with eblits in e.g. $FILESDIR, $FILESDIR points to the overlay's |
| 24 |
> location so it is clear that changing it in ::gentoo wont affect the |
| 25 |
> overlay. |
| 26 |
> (that's probably something to add to the 'pros' section too actually) |
| 27 |
> |
| 28 |
|
| 29 |
Interesting.. |
| 30 |
|
| 31 |
> I'm one of those that believe "if you exposed an API, then it becomes |
| 32 |
> public and you have to maintain that properly; no matter if there are |
| 33 |
> obvious consumers or not, since the possibility exists you have to |
| 34 |
> account for that", which is what happens with every eclass wrt overlays. |
| 35 |
> |
| 36 |
|
| 37 |
Depends on the stated policies, but in general I agree it is a good |
| 38 |
approach to plan like it is (and quite useful to ensure planning a bit |
| 39 |
instead of just rolling something out). |
| 40 |
|
| 41 |
-- |
| 42 |
Kristian Fiskerstrand |
| 43 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 44 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives