1 |
On Mon, 2009-03-02 at 16:48 +0000, Ciaran McCreesh wrote: |
2 |
> On Fri, 27 Feb 2009 04:41:23 +0200 |
3 |
> Mart Raudsepp <leio@g.o> wrote: |
4 |
> > So here the reverting of a masking in gentoo-x86 is quite intentional |
5 |
> > and currently desired. |
6 |
> |
7 |
> This is fundamentally broken as a concept. |
8 |
> |
9 |
> Adding an overlay should not have any impact upon other repositories. |
10 |
|
11 |
Adding an overlay conceptually and fundamentally and per dictionary |
12 |
means laying some packages over something else, PORTDIR in this case - |
13 |
the main repository and therefore adding an overlay impacts other |
14 |
repositories - at least the main one. |
15 |
This is how it has always worked and I do not understand why the |
16 |
behaviour should suddenly change to mean something illogical to the |
17 |
term. |
18 |
|
19 |
> It should be possible for a user to add an overlay, and make limited |
20 |
> use of that repository, without having to worry that the mere act of |
21 |
> adding that overlay will make massive changes to what's visible in |
22 |
> other repositories. |
23 |
|
24 |
Perhaps the package manager should add such a support then with |
25 |
PORTDIR_PREVIEW_OVERLAY or some such if you want your users to be able |
26 |
to have the overlay VCS checkout and addition to PORDIR_OVERLAY or the |
27 |
like to be one operation. |
28 |
|
29 |
> Overlays shouldn't be altering the visibility of things outside of that |
30 |
> overlay without explicit user action. |
31 |
|
32 |
Can you repeat the technically sound reasoning to that again please or |
33 |
point to exact archived posts? This discussion has been going on in |
34 |
other mediums as well, I might have missed the core points. |
35 |
|
36 |
> > By this snippet we could simply move the current relevant maskings |
37 |
> > from profiles/package.mask to profiles/base/package.mask and call it |
38 |
> > a day (and screw over the few profiles that don't end up parenting |
39 |
> > base/), as QA forced us to do in case of per-arch mask negations in |
40 |
> > gentoo-x86 a while back. |
41 |
> > But it doesn't seem to be as simple as that. |
42 |
> |
43 |
> Well no, because profiles/base/ in your overlay is entirely unrelated |
44 |
> to profiles/base/ in the master. |
45 |
> |
46 |
> > > Only reason it flies for portage is because it collapses it all |
47 |
> > > into one stack; for managers designed to support multiple |
48 |
> > > standalone repos that assumption no longer applies, thus that |
49 |
> > > behaviour (outside of PMS) breaks. |
50 |
> > |
51 |
> > Last I knew the official council approved PMS was meant to describe |
52 |
> > portage behaviour at the time, which appears to have been the same |
53 |
> > along the way - treating all overlays in the same "stack" as PORTDIR, |
54 |
> > perhaps as there is no means to declare a different "stack". |
55 |
> |
56 |
> PMS does not attempt to document Portage behaviour in the cases where |
57 |
> Portage behaviour is dumb. That's the reason there's as little as |
58 |
> possible mentioned regarding overlays there -- Portage's overlay model |
59 |
> is a horrible hack, and forcing package managers to implement it rather |
60 |
> than offering a true multiple repository model would be a serious hit |
61 |
> on usability. |
62 |
> |
63 |
> The way forward here is to identify what you're trying to achieve, |
64 |
> whilst ignoring how things are currently defined or what is or is not |
65 |
> possible. Then we can look at that and work out whether it can be |
66 |
> mapped to an existing solution or some easily-implementable new |
67 |
> solution. Starting with implementation is the wrong approach. |
68 |
|
69 |
I'm trying to achieve that merely adding an overlay on top of gentoo-x86 |
70 |
repository actually adds that overlay and things work as desired in |
71 |
regards to visibility. |
72 |
In related reasons, we need to do the unmasking of things masked in main |
73 |
repository because the masks there affect the visibility of packages in |
74 |
the overlay by masking those as well. Perhaps that's the actual core |
75 |
problem for us, if playing along with the notion of current Portage |
76 |
behaviour being dumb (Where do I read how it is dumb and how it'd be |
77 |
better and what a true multiple repository model would be like?) |
78 |
|
79 |
|
80 |
Regards, |
81 |
Mart Raudsepp |