On Fri, 27 Feb 2009 04:41:23 +0200 Mart Raudsepp <l...@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
signature.asc
Description: PGP signature
