1 |
On Sun, 2009-12-06 at 00:40 -0700, Denis Dupeyron wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> Here's the agenda for the meeting on Monday. Two topics didn't make it for this |
5 |
> meeting. I will be addressing the reasons why this happened in a different |
6 |
> email as I don't want to delay this agenda any longer. One obvious reason |
7 |
> though is time: you'll see that it's pretty packed. |
8 |
|
9 |
I have a work meeting that will conflict with this council meeting. I |
10 |
have yet to find a suitable proxy so I'll just put in my votes/notes in |
11 |
here by email. |
12 |
|
13 |
However leio pointed out a vote by mail doesn't consider points made |
14 |
during any discussion during the meeting. So if no objections from the |
15 |
council I'd like to vote post meeting after reading the logs. But if |
16 |
that not acceptable then here are my pre meeting votes. |
17 |
|
18 |
|
19 |
> 1. Intro (5 minutes, including late arrivals) |
20 |
> 1.1. Make sure somebody is logging |
21 |
> 1.2. Roll call |
22 |
> 1.3 Who wants to chair? I can volunteer if nobody doesn't as I know the |
23 |
> topics already. |
24 |
> 1.4. Last chance for remarks on the agenda (in particular does anybody mind |
25 |
> extending the duration of topics as the timing is tight) |
26 |
> |
27 |
> 2. EAPI3 status (10 minutes) |
28 |
> Can we have an ETA? Even a vague one would help. |
29 |
> |
30 |
> 3. Prefix (15 minutes) |
31 |
> 3.1. The prefix team has answered all questions (see full thread at [1]), |
32 |
> provided a PMS patch [2], and have a portage branch ready with most if |
33 |
> not all features. Vote for or against it. If voting against please |
34 |
> suggest improvements. |
35 |
> 3.2. EAPI bump |
36 |
> 3.2.1. Should we make a quick, prefix-specific EAPI bump? |
37 |
|
38 |
3.2.1: Yes to the PM defining these variables internally. |
39 |
|
40 |
|
41 |
> 3.2.2. Should we wrap together prefix plus whatever features of EAPI3 which |
42 |
> are already ready into an intermediate EAPI and ship that now? |
43 |
3.2.2: Not really if getting a status update will come no sooner then |
44 |
the meeting. |
45 |
|
46 |
> 3.2.3. Should we add prefix to EAPI3 and ship it all together when what's |
47 |
> missing of EAPI3 is ready? |
48 |
|
49 |
3.2.3: No reason to delay the introduction of the internal variables. |
50 |
|
51 |
|
52 |
|
53 |
> 4. GLEPs 58, 59, 60 and 61 (15 minutes) |
54 |
> Read more about this as well as a nice summary at [3]. Vote for or against |
55 |
> each of these 4 GLEPs. If voting against please suggest improvements and/or |
56 |
> alternatives. |
57 |
|
58 |
This was asked to be handled in January vs Dec. |
59 |
http://archives.gentoo.org/gentoo-dev/msg_da4bd914abf0d830cbd063328abf742f.xml |
60 |
|
61 |
If we must vote then I would most likely have to go with. |
62 |
|
63 |
58: Yes (obsolete sha1 in favor of sha512. keep sha256) |
64 |
59: Yes |
65 |
60|60: January (or reviewed the meeting after 58 & 59 are completed in |
66 |
the tree) |
67 |
|
68 |
|
69 |
> 5. mtime preservation (15 minutes) |
70 |
> Three alternatives have been proposed: |
71 |
> 5.1. The package manager must preserve modification times of regular files. |
72 |
> This includes files being compressed before merging. Exceptions to this |
73 |
> are: |
74 |
> - Files newly created by the package manager |
75 |
> - Binary object files being stripped of symbols |
76 |
> - Maybe others |
77 |
> Depending on the exact wording and exceptions this can be made |
78 |
> equivalent to 5.3 below. |
79 |
5.1: Yes || 5.3 |
80 |
But this seems like a lot of overhead. Why not just tag the ebuilds |
81 |
needing this behavior vs potentially slowing down the PM all the time? |
82 |
What are some real world cases of needing to keep the mtime? *.py[c|o] |
83 |
files? |
84 |
|
85 |
|
86 |
> 5.2. Let ebuilds call dopreservemtimes (with an API similar to docompress) in |
87 |
> both src_install and pkg_preinst. Doing so would instruct the package |
88 |
> manager that it must preserve mtimes (including subsecond, if supported |
89 |
> on the filesystem) for a particular set of paths, even if doing so means |
90 |
> no stripping etc. All other mtimes may be rewritten as the package |
91 |
> manager sees fit, and from this next EAPI onwards must be rewritten at |
92 |
> merge time for anything predating the start of the build. |
93 |
|
94 |
5.2: No. This sounds overly complex |
95 |
|
96 |
> 5.3. Just document precisely the current behavior of portage and what can be |
97 |
> relied upon. |
98 |
|
99 |
5.3: Yes (as there seems to be no consensus among the PM devs on this |
100 |
topic) |