Gentoo Archives: gentoo-dev

From: Mart Raudsepp <leio@g.o>
To: gentoo devs <gentoo-dev@l.g.o>
Subject: [gentoo-dev] Repository stacking and complementary overlays
Date: Fri, 27 Feb 2009 02:41:25
Message-Id: 1235702483.8324.38.camel@localhost
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Repository stacking and complementary overlays Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>