1 |
On Wed, Feb 25, 2009 at 01:42:38PM +0100, Gilles Dartiguelongue wrote: |
2 |
> Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit : |
3 |
> > On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote: |
4 |
> > > This is your friendly reminder! Same bat time (typically the 2nd & 4th |
5 |
> > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ |
6 |
> > > irc.freenode.net) ! |
7 |
> > |
8 |
> > Informal request, but it would be useful to get an idea of the |
9 |
> > councils views on portage overlay compatibility issues. |
10 |
> > |
11 |
> > Specifically, when it comes to gentoo repositories, there is one, and |
12 |
> > only one definition of what that is- pms's repo spec. The problem |
13 |
> > here is that the only repository truly conformant to that spec is |
14 |
> > gentoo-x86, for the rest of the repositories (overlays realistically) |
15 |
> > whatever portage supports seems to be the eventual standard they grow |
16 |
> > towards. |
17 |
> > |
18 |
> > Problem with this is that there is *zero* way to spot these non-pms |
19 |
> > repositories as it stands. Simplest example, under portage overlays |
20 |
> > can unmask pkgs globally (gnome overlay reverting masks in |
21 |
> > gentoo-x86), |
22 |
> |
23 |
> I reply here as part of the gnome herd and partly responsible for the |
24 |
> mask reverting in the overlay. I didn't know something used in |
25 |
> gentoo-x86 couldn't be used in an overlay. |
26 |
|
27 |
Suspect I wasn't clear; you *can* use things from the parent (although |
28 |
that whole relationship is outside of PMS); the problem here is that |
29 |
y'all are reverting something in the *master*. |
30 |
|
31 |
Literally, bug-buddy was masked in gentoo-x86; enabling your overlay |
32 |
reverts that masking in *gentoo-x86*. Only reason this even works is |
33 |
due to portage internals being limited (everything is stacked |
34 |
together, no true standalones possible). |
35 |
|
36 |
> Could you point me to the PMS section that treat this ? |
37 |
Flip through the package.mask section (snagging from profiles.tex |
38 |
directly)- |
39 |
|
40 |
""" |
41 |
Note that the \t{-spec} syntax can be used to remove a mask in a |
42 |
parent profile, but not necessarily a global mask (from |
43 |
\t{profiles/package.mask}, section~\ref{profiles-package.mask}). |
44 |
|
45 |
\note Portage currently treats \t{profiles/package.mask} as being on |
46 |
the leftmost branch of the inherit tree when it comes to \t{-lines}. |
47 |
This behaviour may not be relied upon. |
48 |
""" |
49 |
|
50 |
Note the 'parent profile'. Why they're claiming repo level masking |
51 |
can't be reversed for that repo, not sure (reasonably sure several |
52 |
profiles rely on it). Either way, your overlay is trying to revert |
53 |
entries it doesn't have in that stack. |
54 |
|
55 |
Only reason it flies for portage is because it collapses it all into |
56 |
one stack; for managers designed to support multiple standalone repos |
57 |
that assumption no longer applies, thus that behaviour (outside of |
58 |
PMS) breaks. |
59 |
|
60 |
~harring |