Re: [gentoo-dev] Repository stacking and complementary overlays

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

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.
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.

Overlays shouldn't be altering the visibility of things outside of that
overlay without explicit user action.

> 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.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]