1 |
On 15:17 Fri 17 Apr , Donnie Berkholz wrote: |
2 |
> If you have something you'd wish for us to chat about, maybe even vote |
3 |
> on, let us know! Simply reply to this e-mail for the whole Gentoo dev |
4 |
> list to see. |
5 |
|
6 |
I've got a few items pending that I would like to propose. It should be |
7 |
clear that there are way too many topics in this list for a single |
8 |
meeting, so we'll have to prioritize a bit and discuss on list in |
9 |
advance as much as possible. |
10 |
|
11 |
Feel free to reply to this email regarding any of the below items. |
12 |
Please change the subject so it's easier to parse through the |
13 |
subthreads. |
14 |
|
15 |
|
16 |
GLEP 54: Dealing with live SCM packages |
17 |
--------------------------------------- |
18 |
|
19 |
Goal: Vote on approval of GLEP 54. |
20 |
|
21 |
|
22 |
Handling EAPI versioning in a forwards-compatible way |
23 |
----------------------------------------------------- |
24 |
|
25 |
Goal: Vote on the implementation for the problem solved in GLEP 55. |
26 |
|
27 |
|
28 |
EAPI=3: Progress update |
29 |
----------------------- |
30 |
|
31 |
Zac agreed to have the feature list implemented by this meeting, April |
32 |
23. Assuming this will be the case, what else is left? |
33 |
|
34 |
|
35 |
EAPI 4: Inclusion of prefix-related variables |
36 |
--------------------------------------------- |
37 |
|
38 |
Fabian Groffen wrote: |
39 |
|
40 |
I would like the council to discuss the addition of three variables to |
41 |
EAPI3. |
42 |
|
43 |
- EPREFIX |
44 |
The offset prefix of a Gentoo Prefix installation. When Gentoo Prefix |
45 |
is not used, ${EPREFIX} should be "". |
46 |
This variable should be available everywhere. |
47 |
- EROOT |
48 |
The offset prefix appended to ${ROOT}, e.g. ${ROOT%/}${EPREFIX}/ |
49 |
This variable is available where ROOT is, following PMS: pkg_* |
50 |
- ED |
51 |
The offset prefix appended to ${D}, e.g. ${D%/}${EPREFIX}/ |
52 |
This variable is available where D is, following PMS: src_install |
53 |
|
54 |
While the first variable (EPREFIX) can be set using an eclass, the |
55 |
latter two need to be set by the package manager. In particular ED, |
56 |
because the value of D might not be known. EROOT and ED are convenience |
57 |
variables. Making them available already now, even though initialised |
58 |
as ROOT and D respectively, allows Prefix enabled ebuilds to be shared |
59 |
between gentoo-x86 and Prefix trees without modifications. |
60 |
|
61 |
|
62 |
Goal: Get opinions from council members. |
63 |
|
64 |
Time allotted: 15 minutes |
65 |
|
66 |
|
67 |
EAPI 4: Inclusion of "mtime preservation" |
68 |
----------------------------------------- |
69 |
|
70 |
Ulrich Mueller proposed this for inclusion. |
71 |
|
72 |
Consider inclusion of "mtime preservation" (see bug 264130, and the |
73 |
thread "Preserving mtimes for EAPI3" in this ML). |
74 |
|
75 |
As I see it, there are three options: |
76 |
A. Always preserve timestamps when merging from D to ROOT, what was my |
77 |
original suggestion. Portage and Pkgcore already comply with this. |
78 |
B. Preserve timestamps, but optionally allow the package manager to update |
79 |
"old" ones. This is the suggestion from comment #12. Again, Portage and |
80 |
Pkgcore would be compliant already (since updating mtimes would be |
81 |
optional). |
82 |
C. As B, but with mandatory updating of "old" mtimes. For this, all three |
83 |
package managers would have to be changed. |
84 |
|
85 |
|
86 |
Goal: Bring up concerns. Vote on this. |
87 |
|
88 |
Time allotted: 10 minutes |
89 |
|
90 |
|
91 |
Portage changing behavior in ebuild-visible ways |
92 |
------------------------------------------------ |
93 |
|
94 |
David Leverton wrote: |
95 |
|
96 |
I would like the Council to discuss the matter of Portage repeatedly |
97 |
changing behaviour in ebuild-visible ways without an EAPI bump or even |
98 |
an announcement that anything changed. Notable examples include .lzma |
99 |
support in unpack (bug 207193), the change in pkg_* phase ordering (bug |
100 |
222721) and the preservation of timestamps during merge (bug 264130). |
101 |
It is quite frustrating to spend considerable effort determining |
102 |
Portage's behaviour and matching it in Paludis, only to find a few |
103 |
months later that Portage changed and now users are getting broken |
104 |
packages if not broken systems because ebuilds are starting to rely on |
105 |
the new rules. |
106 |
|
107 |
Goal: David proposes having a policy that this won't happen in the |
108 |
future or admitting that we don't really care. |
109 |
|
110 |
Time allotted: 15 minutes |
111 |
|
112 |
-- |
113 |
Thanks, |
114 |
Donnie |
115 |
|
116 |
Donnie Berkholz |
117 |
Developer, Gentoo Linux |
118 |
Blog: http://dberkholz.wordpress.com |