From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-dev+bounces-35024-garchives=archives.gentoo.org@lists.gentoo.org>) id 1LjlXf-0006JD-EX for garchives@archives.gentoo.org; Wed, 18 Mar 2009 02:30:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 38E70E0630; Wed, 18 Mar 2009 02:30:02 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.44]) by pigeon.gentoo.org (Postfix) with ESMTP id B74EBE0630 for <gentoo-dev@lists.gentoo.org>; Wed, 18 Mar 2009 02:30:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by MXR-5.estpak.ee (Postfix) with ESMTP id 27ABE1EDCBE for <gentoo-dev@lists.gentoo.org>; Wed, 18 Mar 2009 04:30:00 +0200 (EET) X-Virus-Scanned: amavisd-new at estpak.ee Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-5.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIjU5jf9nLFw for <gentoo-dev@lists.gentoo.org>; Wed, 18 Mar 2009 04:29:58 +0200 (EET) Received: from Relayhost2.neti.ee (Relayhost2 [88.196.174.142]) by MXR-5.estpak.ee (Postfix) with ESMTP id 55C6C1EDCAB for <gentoo-dev@lists.gentoo.org>; Wed, 18 Mar 2009 04:29:58 +0200 (EET) X-SMTP-Auth-NETI-Businesmail: no Subject: Re: [gentoo-dev] Repository stacking and complementary overlays From: Mart Raudsepp <leio@dustbite.net> To: gentoo-dev@lists.gentoo.org In-Reply-To: <20090302164807.6324266c@snowcone> References: <1235702483.8324.38.camel@localhost> <20090302164807.6324266c@snowcone> Content-Type: text/plain Date: Wed, 18 Mar 2009 04:30:05 +0200 Message-Id: <1237343405.14481.8.camel@localhost> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 Content-Transfer-Encoding: 7bit X-Archives-Salt: 2a3c31e4-1a9d-49e5-b150-7dd0a04df92b X-Archives-Hash: 1a22bb9eb48ec08e4d1b795f7a30a08d On Mon, 2009-03-02 at 16:48 +0000, Ciaran McCreesh wrote: > On Fri, 27 Feb 2009 04:41:23 +0200 > Mart Raudsepp <leio@gentoo.org> wrote: > > So here the reverting of a masking in gentoo-x86 is quite intentional > > and currently desired. > > This is fundamentally broken as a concept. > > Adding an overlay should not have any impact upon other repositories. Adding an overlay conceptually and fundamentally and per dictionary means laying some packages over something else, PORTDIR in this case - the main repository and therefore adding an overlay impacts other repositories - at least the main one. This is how it has always worked and I do not understand why the behaviour should suddenly change to mean something illogical to the term. > It should be possible for a user to add an overlay, and make limited > use of that repository, without having to worry that the mere act of > adding that overlay will make massive changes to what's visible in > other repositories. Perhaps the package manager should add such a support then with PORTDIR_PREVIEW_OVERLAY or some such if you want your users to be able to have the overlay VCS checkout and addition to PORDIR_OVERLAY or the like to be one operation. > Overlays shouldn't be altering the visibility of things outside of that > overlay without explicit user action. Can you repeat the technically sound reasoning to that again please or point to exact archived posts? This discussion has been going on in other mediums as well, I might have missed the core points. > > 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. > > Well no, because profiles/base/ in your overlay is entirely unrelated > to profiles/base/ in the master. > > > > 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". > > PMS does not attempt to document Portage behaviour in the cases where > Portage behaviour is dumb. That's the reason there's as little as > possible mentioned regarding overlays there -- Portage's overlay model > is a horrible hack, and forcing package managers to implement it rather > than offering a true multiple repository model would be a serious hit > on usability. > > The way forward here is to identify what you're trying to achieve, > whilst ignoring how things are currently defined or what is or is not > possible. Then we can look at that and work out whether it can be > mapped to an existing solution or some easily-implementable new > solution. Starting with implementation is the wrong approach. I'm trying to achieve that merely adding an overlay on top of gentoo-x86 repository actually adds that overlay and things work as desired in regards to visibility. In related reasons, we need to do the unmasking of things masked in main repository because the masks there affect the visibility of packages in the overlay by masking those as well. Perhaps that's the actual core problem for us, if playing along with the notion of current Portage behaviour being dumb (Where do I read how it is dumb and how it'd be better and what a true multiple repository model would be like?) Regards, Mart Raudsepp