[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Repository stacking and complementary overlays
From:       Mart Raudsepp <leio () gentoo ! org>
Date:       2009-02-27 2:41:23
Message-ID: 1235702483.8324.38.camel () localhost
[Download RAW message or body]


     A. On K, 2009-02-25 at 04:56 -0800, Brian Harring wrote:
> On Wed, Feb 25, 2009 at 01:42:38PM +0100, Gilles Dartiguelongue wrote:
> > Le mardi 24 février 2009 à 09:47 -0800, Brian Harring a écrit :
> > > On Sun, Feb 22, 2009 at 11:26:48PM -0800, Donnie Berkholz wrote:
> > > > This is your friendly reminder! Same bat time (typically the 2nd & 4th 
> > > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ 
> > > > irc.freenode.net) !
> > > 
> > > Informal request, but it would be useful to get an idea of the 
> > > councils views on portage overlay compatibility issues.
> > > 
> > > Specifically, when it comes to gentoo repositories, there is one, and 
> > > only one definition of what that is- pms's repo spec.  The problem 
> > > here is that the only repository truly conformant to that spec is 
> > > gentoo-x86, for the rest of the repositories (overlays realistically) 
> > > whatever portage supports seems to be the eventual standard they grow 
> > > towards.
> > > 
> > > Problem with this is that there is *zero* way to spot these non-pms 
> > > repositories as it stands.  Simplest example, under portage overlays 
> > > can unmask pkgs globally (gnome overlay reverting masks in 
> > > gentoo-x86),
> > 
> > I reply here as part of the gnome herd and partly responsible for the
> > mask reverting in the overlay. I didn't know something used in
> > gentoo-x86 couldn't be used in an overlay.
> 
> Suspect I wasn't clear; you *can* use things from the parent (although 
> that whole relationship is outside of PMS); the problem here is that 
> y'all are reverting something in the *master*.
> 
> Literally, bug-buddy was masked in gentoo-x86; enabling your overlay 
> reverts that masking in *gentoo-x86*.  Only reason this even works is 
> due to portage internals being limited (everything is stacked 
> together, no true standalones possible).

So here the reverting of a masking in gentoo-x86 is quite intentional
and currently desired. The problem is that
a) most importantly - no way to explicitly express a complementary
overlay to a given repository
b) less importantly - gentoo-x86 has no true base profile where to mask
things, as base/ isn't really the base of everything, and the global
package.mask is for some reason defined as something different from a
really base profile (global mask negation disallowed even in arch
profiles of the same repository, etc)

This mail thread is about a)

> > Could you point me to the PMS section that treat this ?
> Flip through the package.mask section (snagging from profiles.tex 
> directly)-
> 
> """
> Note that the \t{-spec} syntax can be used to remove a mask in a 
> parent profile, but not necessarily a global mask (from 
> \t{profiles/package.mask}, section~\ref{profiles-package.mask}).
> 
> \note Portage currently treats \t{profiles/package.mask} as being on 
> the leftmost branch of the inherit tree when it comes to \t{-lines}. 
> This behaviour may not be relied upon.
> """

By this snippet we could simply move the current relevant maskings from
profiles/package.mask to profiles/base/package.mask and call it a day
(and screw over the few profiles that don't end up parenting base/), as
QA forced us to do in case of per-arch mask negations in gentoo-x86 a
while back.
But it doesn't seem to be as simple as that.

The wording "but not _necessarily_ a global mask" is quite inconclusive
as well.

> Note the 'parent profile'.  Why they're claiming repo level masking 
> can't be reversed for that repo, not sure (reasonably sure several 
> profiles rely on it).  Either way, your overlay is trying to revert 
> entries it doesn't have in that stack.

We'd like the stack to be the same as gentoo-x86. It is a complementary
overlay to gentoo-x86 and definitely not a separate stand-alone
repository.

> Only reason it flies for portage is because it collapses it all into 
> one stack; for managers designed to support multiple standalone repos 
> that assumption no longer applies, thus that behaviour (outside of 
> PMS) breaks.

Last I knew the official council approved PMS was meant to describe
portage behaviour at the time, which appears to have been the same along
the way - treating all overlays in the same "stack" as PORTDIR, perhaps
as there is no means to declare a different "stack".
There are claims that this behaviour (everything in the same stack) is
simply a bug - I dare to disagree and claim instead that this behaviour
is simply about defaulting PORTDIR_OVERLAYs to be complementary to
PORTDIR (as the relation in the variable names quite clearly and
logically states!) and therefore in the same "stack" and that we need a
different way to declare a different stack and standalone repository.
I also claim other PMs than portage should default to extending the
PORTDIR repo_name "stack" as well with overlay entries in
PORTDIR_OVERLAY instead of making a new "stack" as they do now. An
PORTDIR_OVERLAY overlay is an overlay on top of PORTDIR and therefore in
the same "stack", not a new repository that gets a new "stack".



With a very quick thought I see some possible ways to make this more
clear and formal:

a) Declare in a reposity/overlay what its parent repository is, if any -
gnome overlay profiles/parent_repo (or some such) would contain
"gentoo". Could also perhaps extend repo_name, e.g "gentoo+gnome"
b) Declaring what "stack" a repository/overlay belongs to - e.g, both
gentoo main repository and gnome overlay (and quite all other existing
_overlays_) both saying "gentoo" in their profiles/stack_name (with a
better name) file.
c) Maintain the behaviour of portage as is, and assume PORTDIR_OVERLAY
is _overlaying_ PORTDIR as the name suggests, but have some kind of
sanity checks that can be performed where appropriate either by means of
options a) or b) or some different way
d) Make use of sets for solving the current use case in question, as has
been suggested - this seems to involve portage work and actually
understanding why this is a good solution -- concrete explanation on
that is most welcome for consideration and evaluation.

Keep in mind that this (especially options presented as a), b) and c))
covers more than just package.mask negation, as the triggering reason
for this discussion. Knowing that an overlay is complementary to a given
repository or repositories, and knowing that a repository is standalone
from gentoo-x86 could be beneficial in more cases than this specific
one.


For package.mask negation as done in GNOME overlay it's also about
profiles/package.mask vs profiles/base/package.mask behaviour (in
addition to negation of masks in a different repository/overlay) - the
discussion of that is not a subject to this thread, so please make a new
thread when wanting to discuss about that.


Note that I'm on devaway for up to a week from this moment, just getting
an actual discussion going on this topic meanwhile as promised at
council meeting.


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]