summaryrefslogtreecommitdiff
blob: b9314d08c18fd9b7261671ed5f0249614f71683a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
\summary{2012}{11}{13}




\agendaitem{Handling separate /usr support}
\index{separate /usr}\index{package!sys-fs/udev}\index{gen_usr_ldscript}
\index{package!sys-fs/eudev}

References:
\begin{enumerate}
 \item 
 \url{https://lkml.org/lkml/2012/10/2/303}
 \item
 http://thread.gmane.org/gmane.linux.gentoo.project/2208 (dead link)
 \item
 \agoref{gentoo-project}{05049f71afe57feda13c2f4c4adafc7c}
 \item
 \bug{411627}
 \item
 \bug{435756}
 \item
 \bug{441004}
\end{enumerate}

WilliamH requested approval for two methods to support separate /usr
systems [2].  The discussion is closely related to recent opinons on udev, such
as e.g. [1], because the main reason to force a system without separate /usr
during boot is to allow newer versions of udev to be used.
The originally announced item of discussing the removal of gen_usr_ldscript
has been retracted [3]. --- approve / disapprove plan (forcing everyone to take 
action, and implement one of the two "supported" solutions)

WilliamH requests a council vote to allow migrating everyone after bugs
[4,5,6] are resolved.  He proposes a news item to announce this that allows to
assume after a given period of time that everyone who is using split /usr is
using a method to mount /usr before boot.  The focus is purely on this topic.

rich0 prefers to move on until suport for separate /usr becomes a
barrier, and handle things from there.  This allows for alternative
solutions to be developed and put forward.  He favours waiting somewhat
to see developments of the udev fork.

Chainsaw is a strong proponent for waiting a month and see how the new
udev fork develops itself.  If within a month no solution is provided by
the udev fork, things need to be moved forward in WilliamH's proposed
way.

scarabeus approves the plan.

betelgeuse likes to ensure users won't be caught off guard, but has no
preference for any direction taken in particular.

graaff's main concern is how the problem is tied to udev, or not.  A fork of
udev may not change the situation regarding separate /usr, hence delaying a
decision now is not sensical.  Opt-in system for people to ensure they can
boot is pre-requisite.  If this cannot be ensured, we have to wait.

grobian disapproves the plan, since there will be systems that cannot easily
be changed to ensure /usr being mounted at boot, and it is no good to expel
users of (security) updates just because of that.  With the use of a special
profile (masks/unmasks, variables and/or use-flags), users that want to move
on, can opt-in to getting packages that require non separate /usr.


\agendaitem{Policy on "$<$" versioned dependencies}
\index{$<$ dependencies}

Reference: \agoref{gentoo-project}{b20048140e8a261569fe4a1d561df6c6}

chithahn requested the council to clear up confusion around "$<$" versioned
dependencies.  This issue seems to combine
\begin{enumerate}
 \item 
 notorious behaviour from the usual suspects
 \item
 QA policies whether or not they are properly documented/advertised
 \item
 the technical problem of "$<$" dependencies causing downgrades
\end{enumerate}

The council sees no rule that makes it illegal to use $<$ dependencies, but
strongly discourages their use.  It must be noted that for some
packages, a downgrade is very undesirable.  This has triggered package
removals in the past.  However, the council requests the teams responsible for
that removal to act reasonably and in good cooperation with the maintainers of
the packages in question.


\agendaitem{Open bugs with council involvement}

\begin{itemize}
 \item 
 \bug{383467}:
 ulm has done the work here, waiting for a confirmation that we can really
  close the bug
 \item
 \bug{438338}: no progress and/or actions planned for this
\end{itemize}


\agendaitem{Open Floor}

No issues were brought up to the council.