Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo Council Reminder for February 26
Date: Wed, 25 Feb 2009 12:55:48
Message-Id: 20090225125621.GE3506@hrair
In Reply to: Re: [gentoo-dev] Gentoo Council Reminder for February 26 by Gilles Dartiguelongue
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