On Mon, 2009-03-02 at 16:48 +0000, Ciaran McCreesh wrote:
> On Fri, 27 Feb 2009 04:41:23 +0200
> Mart Raudsepp <leio@g.o> 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