From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LcsfE-0006Lb-NU for garchives@archives.gentoo.org; Fri, 27 Feb 2009 02:41:25 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 642E0E03F4; Fri, 27 Feb 2009 02:41:23 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.44]) by pigeon.gentoo.org (Postfix) with ESMTP id BA37EE03F4 for ; Fri, 27 Feb 2009 02:41:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by MXR-4.estpak.ee (Postfix) with ESMTP id C337725253A for ; Fri, 27 Feb 2009 04:41:21 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at Relay4.estpak.ee Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-4.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg4-Yd36GhkE for ; Fri, 27 Feb 2009 04:41:21 +0200 (EET) Received: from Relayhost1.neti.ee (Relayhost1 [88.196.174.141]) by MXR-4.estpak.ee (Postfix) with ESMTP id 164E42524ED for ; Fri, 27 Feb 2009 04:41:21 +0200 (EET) X-SMTP-Auth-NETI-Businesmail: no Subject: [gentoo-dev] Repository stacking and complementary overlays From: Mart Raudsepp To: gentoo devs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Yta7po3rBmx3veGmsZXL" Date: Fri, 27 Feb 2009 04:41:23 +0200 Message-Id: <1235702483.8324.38.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 X-Archives-Salt: ee30c86a-d544-4782-ae39-d970e966abae X-Archives-Hash: cfdb02b85bd255a1a6dd6d66f09592cc --=-Yta7po3rBmx3veGmsZXL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A. =EF=BB=BFOn 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=C3=A9vrier 2009 =C3=A0 09:47 -0800, Brian Harring a =C3= =A9crit : > > > 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=20 > > > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-counci= l @=20 > > > > irc.freenode.net) ! > > >=20 > > > Informal request, but it would be useful to get an idea of the=20 > > > councils views on portage overlay compatibility issues. > > >=20 > > > Specifically, when it comes to gentoo repositories, there is one, and= =20 > > > only one definition of what that is- pms's repo spec. The problem=20 > > > here is that the only repository truly conformant to that spec is=20 > > > gentoo-x86, for the rest of the repositories (overlays realistically)= =20 > > > whatever portage supports seems to be the eventual standard they grow= =20 > > > towards. > > >=20 > > > Problem with this is that there is *zero* way to spot these non-pms=20 > > > repositories as it stands. Simplest example, under portage overlays=20 > > > can unmask pkgs globally (gnome overlay reverting masks in=20 > > > gentoo-x86), > >=20 > > 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. >=20 > Suspect I wasn't clear; you *can* use things from the parent (although=20 > that whole relationship is outside of PMS); the problem here is that=20 > y'all are reverting something in the *master*. >=20 > Literally, bug-buddy was masked in gentoo-x86; enabling your overlay=20 > reverts that masking in *gentoo-x86*. Only reason this even works is=20 > due to portage internals being limited (everything is stacked=20 > 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=20 > directly)- >=20 > """ > Note that the \t{-spec} syntax can be used to remove a mask in a=20 > parent profile, but not necessarily a global mask (from=20 > \t{profiles/package.mask}, section~\ref{profiles-package.mask}). >=20 > \note Portage currently treats \t{profiles/package.mask} as being on=20 > the leftmost branch of the inherit tree when it comes to \t{-lines}.=20 > 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=20 > can't be reversed for that repo, not sure (reasonably sure several=20 > profiles rely on it). Either way, your overlay is trying to revert=20 > 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=20 > one stack; for managers designed to support multiple standalone repos=20 > that assumption no longer applies, thus that behaviour (outside of=20 > 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. --=20 Mart Raudsepp Gentoo Developer Mail: leio@gentoo.org Weblog: http://planet.gentoo.org/developers/leio --=-Yta7po3rBmx3veGmsZXL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEABECAAYFAkmnUtMACgkQkeYb6olFHJc0JACffEuf1O/zoduOFkhaT5Hd7dYk 7ncAoIF0amlBKt5R68knIvB7MMoYZ/IE =sDBC -----END PGP SIGNATURE----- --=-Yta7po3rBmx3veGmsZXL--