| 1 |
On Fri, 27 Feb 2009 04:41:23 +0200 |
| 2 |
Mart Raudsepp <leio@g.o> wrote: |
| 3 |
> So here the reverting of a masking in gentoo-x86 is quite intentional |
| 4 |
> and currently desired. |
| 5 |
|
| 6 |
This is fundamentally broken as a concept. |
| 7 |
|
| 8 |
Adding an overlay should not have any impact upon other repositories. |
| 9 |
It should be possible for a user to add an overlay, and make limited |
| 10 |
use of that repository, without having to worry that the mere act of |
| 11 |
adding that overlay will make massive changes to what's visible in |
| 12 |
other repositories. |
| 13 |
|
| 14 |
Overlays shouldn't be altering the visibility of things outside of that |
| 15 |
overlay without explicit user action. |
| 16 |
|
| 17 |
> By this snippet we could simply move the current relevant maskings |
| 18 |
> from profiles/package.mask to profiles/base/package.mask and call it |
| 19 |
> a day (and screw over the few profiles that don't end up parenting |
| 20 |
> base/), as QA forced us to do in case of per-arch mask negations in |
| 21 |
> gentoo-x86 a while back. |
| 22 |
> But it doesn't seem to be as simple as that. |
| 23 |
|
| 24 |
Well no, because profiles/base/ in your overlay is entirely unrelated |
| 25 |
to profiles/base/ in the master. |
| 26 |
|
| 27 |
> > Only reason it flies for portage is because it collapses it all |
| 28 |
> > into one stack; for managers designed to support multiple |
| 29 |
> > standalone repos that assumption no longer applies, thus that |
| 30 |
> > behaviour (outside of PMS) breaks. |
| 31 |
> |
| 32 |
> Last I knew the official council approved PMS was meant to describe |
| 33 |
> portage behaviour at the time, which appears to have been the same |
| 34 |
> along the way - treating all overlays in the same "stack" as PORTDIR, |
| 35 |
> perhaps as there is no means to declare a different "stack". |
| 36 |
|
| 37 |
PMS does not attempt to document Portage behaviour in the cases where |
| 38 |
Portage behaviour is dumb. That's the reason there's as little as |
| 39 |
possible mentioned regarding overlays there -- Portage's overlay model |
| 40 |
is a horrible hack, and forcing package managers to implement it rather |
| 41 |
than offering a true multiple repository model would be a serious hit |
| 42 |
on usability. |
| 43 |
|
| 44 |
The way forward here is to identify what you're trying to achieve, |
| 45 |
whilst ignoring how things are currently defined or what is or is not |
| 46 |
possible. Then we can look at that and work out whether it can be |
| 47 |
mapped to an existing solution or some easily-implementable new |
| 48 |
solution. Starting with implementation is the wrong approach. |
| 49 |
|
| 50 |
-- |
| 51 |
Ciaran McCreesh |
Archives