1 |
On 12/04/2016 06:58 PM, Mike Gilbert wrote: |
2 |
> On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox <awilfox@×××××××××××.org> wrote: |
3 |
>> Roadmap |
4 |
>> - ------- |
5 |
>> |
6 |
>> Since the shell environment is flexible, this change can be |
7 |
>> implemented almost immediately; the defaults specified in the Gentoo |
8 |
>> base profile ensure that at worst nothing will immediately change. As |
9 |
>> forks, derivatives, and other organisations change the environment |
10 |
>> variables in their profiles or ``make.conf`` files, all updated |
11 |
>> ebuilds will immediately reflect the changes. |
12 |
>> |
13 |
>> During this, the variables can be added to the EAPI=7 specification, |
14 |
>> and may eventually be added to PMS §11.1. |
15 |
> |
16 |
> It's not clear to me why this should be defined in PMS, especially if |
17 |
> this is going to be a profile variable in make.defaults. |
18 |
> |
19 |
> I think we would only need to add it to PMS if you need to package |
20 |
> manager to compute the value based on the running system. Is that what |
21 |
> you had in mind here? If so, you will need to include that algorithm |
22 |
> in your patch. |
23 |
> |
24 |
How would we ensure (or encourage) that other distros based on Gentoo |
25 |
would follow this practice? Adding things to PMS isn't a panacea, sure, |
26 |
but from what I can tell it seems the goal here is to allow distros |
27 |
based on us to correctly *show* that without changing hundreds of lines |
28 |
in the package tree. Maybe that's outside of PMS; if so, where does this |
29 |
belong? |
30 |
|
31 |
Of course, this solution requires action/patching on our behalf as well, |
32 |
but it seems like a long-term goal that, when completed, may be suitable |
33 |
for addition in some sort of standard document, even if it's a wiki page |
34 |
on how to roll your own distro based on us. |
35 |
|
36 |
It didn't seem to me that there was any intention to automatically guess |
37 |
which distro it is; the people in charge of each distro's package tree |
38 |
should be setting those variables to the correct value, and it should be |
39 |
accessible throughout the tree(s). |
40 |
|
41 |
As OP mentioned, at worst it does nothing until it 'spreads' throughout |
42 |
the tree. The end result is anyone could fork us, change DISTRO and |
43 |
DISTRO_BUG_URL, and instantly have a starting point for their new |
44 |
distro. I'm not aware of any other distro that would make forking or |
45 |
spinning off _this_ easy. That could turn into renewed interest in |
46 |
Gentoo or possibly even better inter-distro relations, since bugs would |
47 |
be going to the correct places. |
48 |
|
49 |
To OP: This idea looks good to me; do you have any proofs of concept for |
50 |
use in common places like ebuilds, metadata.xml (if you intend for it to |
51 |
be used there), etc? If we had a more visual idea of how it worked, |
52 |
maybe more people would understand and have an idea of where to put it |
53 |
if it doesn't fit in with PMS's scope. |
54 |
-- |
55 |
Daniel Campbell - Gentoo Developer |
56 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
57 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |