1 |
On Sun, 4 Dec 2016 21:13:23 -0600 |
2 |
"A. Wilcox" <awilfox@×××××××××××.org> wrote: |
3 |
|
4 |
> -----BEGIN PGP SIGNED MESSAGE----- |
5 |
> Hash: SHA256 |
6 |
> |
7 |
> On 04/12/16 20:58, Mike Gilbert wrote: |
8 |
> > On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox <awilfox@×××××××××××.org> |
9 |
> > wrote: |
10 |
> >> Roadmap - ------- |
11 |
> >> |
12 |
> >> Since the shell environment is flexible, this change can be |
13 |
> >> implemented almost immediately; the defaults specified in the |
14 |
> >> Gentoo base profile ensure that at worst nothing will immediately |
15 |
> >> change. As forks, derivatives, and other organisations change |
16 |
> >> the environment variables in their profiles or ``make.conf`` |
17 |
> >> files, all updated ebuilds will immediately reflect the changes. |
18 |
> >> |
19 |
> >> During this, the variables can be added to the EAPI=7 |
20 |
> >> specification, and may eventually be added to PMS §11.1. |
21 |
> > |
22 |
> > It's not clear to me why this should be defined in PMS, especially |
23 |
> > if this is going to be a profile variable in make.defaults. |
24 |
> |
25 |
> > |
26 |
> > I think we would only need to add it to PMS if you need to package |
27 |
> > manager to compute the value based on the running system. Is that |
28 |
> > what you had in mind here? If so, you will need to include that |
29 |
> > algorithm in your patch. |
30 |
> > |
31 |
> |
32 |
> Thinking on it a little more, that wouldn't be a good way to go. We |
33 |
> can't really rely on lsb_release being present, especially if Portage |
34 |
> is being run on FreeBSD or a more exotic prefix; sys-apps/lsb-release |
35 |
> isn't even installed on my relatively 'normal' amd64 Gentoo Linux |
36 |
> machine. Additionally, it wouldn't have the bug URL even if it were |
37 |
> present. |
38 |
|
39 |
Strictly speaking, it could use $EPREFIX/etc/os-release which has all |
40 |
the info you need, is installed by baselayout and doesn't require |
41 |
special wrappers to print it. |
42 |
|
43 |
Benefits of os-release approach: |
44 |
|
45 |
- distros don't have to override profiles (which can get problematic if |
46 |
a distro uses pretty-much standard Gentoo profiles), |
47 |
|
48 |
- works for people with custom profiles. |
49 |
|
50 |
Drawbacks of os-release approach: |
51 |
|
52 |
- can't do it via profiles, |
53 |
|
54 |
- doesn't work before baselayout is installed. |
55 |
|
56 |
The other alternative is to provide an eclass that reads data from |
57 |
$EPREFIX/os-release and supplies it to the packages that need it. |
58 |
|
59 |
-- |
60 |
Best regards, |
61 |
Michał Górny |
62 |
<http://dev.gentoo.org/~mgorny/> |