1 |
A. On K, 2009-02-25 at 04:56 -0800, Brian Harring wrote: |
2 |
> On Wed, Feb 25, 2009 at 01:42:38PM +0100, Gilles Dartiguelongue wrote: |
3 |
> > Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit : |
4 |
> > > On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote: |
5 |
> > > > This is your friendly reminder! Same bat time (typically the 2nd & 4th |
6 |
> > > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ |
7 |
> > > > irc.freenode.net) ! |
8 |
> > > |
9 |
> > > Informal request, but it would be useful to get an idea of the |
10 |
> > > councils views on portage overlay compatibility issues. |
11 |
> > > |
12 |
> > > Specifically, when it comes to gentoo repositories, there is one, and |
13 |
> > > only one definition of what that is- pms's repo spec. The problem |
14 |
> > > here is that the only repository truly conformant to that spec is |
15 |
> > > gentoo-x86, for the rest of the repositories (overlays realistically) |
16 |
> > > whatever portage supports seems to be the eventual standard they grow |
17 |
> > > towards. |
18 |
> > > |
19 |
> > > Problem with this is that there is *zero* way to spot these non-pms |
20 |
> > > repositories as it stands. Simplest example, under portage overlays |
21 |
> > > can unmask pkgs globally (gnome overlay reverting masks in |
22 |
> > > gentoo-x86), |
23 |
> > |
24 |
> > I reply here as part of the gnome herd and partly responsible for the |
25 |
> > mask reverting in the overlay. I didn't know something used in |
26 |
> > gentoo-x86 couldn't be used in an overlay. |
27 |
> |
28 |
> Suspect I wasn't clear; you *can* use things from the parent (although |
29 |
> that whole relationship is outside of PMS); the problem here is that |
30 |
> y'all are reverting something in the *master*. |
31 |
> |
32 |
> Literally, bug-buddy was masked in gentoo-x86; enabling your overlay |
33 |
> reverts that masking in *gentoo-x86*. Only reason this even works is |
34 |
> due to portage internals being limited (everything is stacked |
35 |
> together, no true standalones possible). |
36 |
|
37 |
So here the reverting of a masking in gentoo-x86 is quite intentional |
38 |
and currently desired. The problem is that |
39 |
a) most importantly - no way to explicitly express a complementary |
40 |
overlay to a given repository |
41 |
b) less importantly - gentoo-x86 has no true base profile where to mask |
42 |
things, as base/ isn't really the base of everything, and the global |
43 |
package.mask is for some reason defined as something different from a |
44 |
really base profile (global mask negation disallowed even in arch |
45 |
profiles of the same repository, etc) |
46 |
|
47 |
This mail thread is about a) |
48 |
|
49 |
> > Could you point me to the PMS section that treat this ? |
50 |
> Flip through the package.mask section (snagging from profiles.tex |
51 |
> directly)- |
52 |
> |
53 |
> """ |
54 |
> Note that the \t{-spec} syntax can be used to remove a mask in a |
55 |
> parent profile, but not necessarily a global mask (from |
56 |
> \t{profiles/package.mask}, section~\ref{profiles-package.mask}). |
57 |
> |
58 |
> \note Portage currently treats \t{profiles/package.mask} as being on |
59 |
> the leftmost branch of the inherit tree when it comes to \t{-lines}. |
60 |
> This behaviour may not be relied upon. |
61 |
> """ |
62 |
|
63 |
By this snippet we could simply move the current relevant maskings from |
64 |
profiles/package.mask to profiles/base/package.mask and call it a day |
65 |
(and screw over the few profiles that don't end up parenting base/), as |
66 |
QA forced us to do in case of per-arch mask negations in gentoo-x86 a |
67 |
while back. |
68 |
But it doesn't seem to be as simple as that. |
69 |
|
70 |
The wording "but not _necessarily_ a global mask" is quite inconclusive |
71 |
as well. |
72 |
|
73 |
> Note the 'parent profile'. Why they're claiming repo level masking |
74 |
> can't be reversed for that repo, not sure (reasonably sure several |
75 |
> profiles rely on it). Either way, your overlay is trying to revert |
76 |
> entries it doesn't have in that stack. |
77 |
|
78 |
We'd like the stack to be the same as gentoo-x86. It is a complementary |
79 |
overlay to gentoo-x86 and definitely not a separate stand-alone |
80 |
repository. |
81 |
|
82 |
> Only reason it flies for portage is because it collapses it all into |
83 |
> one stack; for managers designed to support multiple standalone repos |
84 |
> that assumption no longer applies, thus that behaviour (outside of |
85 |
> PMS) breaks. |
86 |
|
87 |
Last I knew the official council approved PMS was meant to describe |
88 |
portage behaviour at the time, which appears to have been the same along |
89 |
the way - treating all overlays in the same "stack" as PORTDIR, perhaps |
90 |
as there is no means to declare a different "stack". |
91 |
There are claims that this behaviour (everything in the same stack) is |
92 |
simply a bug - I dare to disagree and claim instead that this behaviour |
93 |
is simply about defaulting PORTDIR_OVERLAYs to be complementary to |
94 |
PORTDIR (as the relation in the variable names quite clearly and |
95 |
logically states!) and therefore in the same "stack" and that we need a |
96 |
different way to declare a different stack and standalone repository. |
97 |
I also claim other PMs than portage should default to extending the |
98 |
PORTDIR repo_name "stack" as well with overlay entries in |
99 |
PORTDIR_OVERLAY instead of making a new "stack" as they do now. An |
100 |
PORTDIR_OVERLAY overlay is an overlay on top of PORTDIR and therefore in |
101 |
the same "stack", not a new repository that gets a new "stack". |
102 |
|
103 |
|
104 |
|
105 |
With a very quick thought I see some possible ways to make this more |
106 |
clear and formal: |
107 |
|
108 |
a) Declare in a reposity/overlay what its parent repository is, if any - |
109 |
gnome overlay profiles/parent_repo (or some such) would contain |
110 |
"gentoo". Could also perhaps extend repo_name, e.g "gentoo+gnome" |
111 |
b) Declaring what "stack" a repository/overlay belongs to - e.g, both |
112 |
gentoo main repository and gnome overlay (and quite all other existing |
113 |
_overlays_) both saying "gentoo" in their profiles/stack_name (with a |
114 |
better name) file. |
115 |
c) Maintain the behaviour of portage as is, and assume PORTDIR_OVERLAY |
116 |
is _overlaying_ PORTDIR as the name suggests, but have some kind of |
117 |
sanity checks that can be performed where appropriate either by means of |
118 |
options a) or b) or some different way |
119 |
d) Make use of sets for solving the current use case in question, as has |
120 |
been suggested - this seems to involve portage work and actually |
121 |
understanding why this is a good solution -- concrete explanation on |
122 |
that is most welcome for consideration and evaluation. |
123 |
|
124 |
Keep in mind that this (especially options presented as a), b) and c)) |
125 |
covers more than just package.mask negation, as the triggering reason |
126 |
for this discussion. Knowing that an overlay is complementary to a given |
127 |
repository or repositories, and knowing that a repository is standalone |
128 |
from gentoo-x86 could be beneficial in more cases than this specific |
129 |
one. |
130 |
|
131 |
|
132 |
For package.mask negation as done in GNOME overlay it's also about |
133 |
profiles/package.mask vs profiles/base/package.mask behaviour (in |
134 |
addition to negation of masks in a different repository/overlay) - the |
135 |
discussion of that is not a subject to this thread, so please make a new |
136 |
thread when wanting to discuss about that. |
137 |
|
138 |
|
139 |
Note that I'm on devaway for up to a week from this moment, just getting |
140 |
an actual discussion going on this topic meanwhile as promised at |
141 |
council meeting. |
142 |
|
143 |
|
144 |
-- |
145 |
Mart Raudsepp |
146 |
Gentoo Developer |
147 |
Mail: leio@g.o |
148 |
Weblog: http://planet.gentoo.org/developers/leio |