1 |
On Sun, 07 Sep 2008 02:05:07 +0000 |
2 |
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o> wrote: |
3 |
|
4 |
> We've been trying to find a way that |
5 |
> will allow users to do an FHS compliant install if they want it, |
6 |
> while at the same time still allowing those that are not interested |
7 |
> in it to keep using the current scheme. Our first attempt was to use |
8 |
> a multislot use flag[1]. According to that flag, we would set the |
9 |
> SLOT and the PREFIX for the install. That has the a very important |
10 |
> problem - it breaks the invariancy of the SLOT and as thus been put |
11 |
> aside. The next step was to use a kdeprefix use flag[2]. This flag no |
12 |
> longer touches the SLOT that is set to "4" for all kde-4.X versions. |
13 |
> It only determines if the package will be installed under the FHS |
14 |
> compliant location (/usr) or under the old location |
15 |
> (/usr/kde/<version>). This however means the users will no longer |
16 |
> have the option to have more than one kde-4.X version installed. |
17 |
> I've been thinking on a different method. With this method [3], we |
18 |
> would keep using the <major>.<minor> slots (4.1, 4.2, etc) so we also |
19 |
> wouldn't break the invariancy. We would allow users to select whether |
20 |
> to have an FHS compliant install or not (the way to allow that still |
21 |
> needs to be discussed) and we would set the prefix based on that. In |
22 |
> case the user wants an FHS compliant install, the eclasses would |
23 |
> block all kde packages on other slots - except 3.5 (uses other |
24 |
> eclasses) and the live versions (for the above reason that it will |
25 |
> always be installed under /usr/kde/<live-version>). One way to decide |
26 |
> whether to install on an FHS compliant location would be to add a use |
27 |
> flag, but I don't think adding that flag for 200+ ebuilds makes sense |
28 |
> as it doesn't make sense to have 1 version of some packages and |
29 |
> possibly 2 or more of other packages. |
30 |
> |
31 |
> So, what am I after in this email? After having an internal discussion |
32 |
> and then opening it up to users in #gentoo-kde and a few other people |
33 |
> on #gentoo-portage, it was suggested I sent a mail here to open this |
34 |
> discussion to everyone and to present the case in a more clear manner. |
35 |
> So, can anyone suggest a good way to accomplish what were trying to |
36 |
> do? At least a better solution than the ones I've presented above? I |
37 |
> would also welcome suggestions on how to configure if the user wants |
38 |
> an FHS compliant install or not (I've thought about setting this var |
39 |
> on /etc). In case someone is thinking on suggesting it, ignoring FHS |
40 |
> or not allowing the install of multiple versions are not valid |
41 |
> solutions to this problem. |
42 |
|
43 |
My advice is to either go all in or not. Dicking around with SLOTs |
44 |
and USE flags is only going to do more harm than good, as the multislot |
45 |
USE flag has demonstrated time and time again. |
46 |
|
47 |
Personally I would just go with upstream. I don't know why someone |
48 |
would need 4.1, 4.2, etc. installed simultaneously. But I'm not the |
49 |
one supporting it so... |
50 |
|
51 |
|
52 |
-- |
53 |
gcc-porting, by design, by neglect |
54 |
treecleaner, for a fact or just for effect |
55 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |