Gentoo Archives: gentoo-dev

From: Ryan Hill <dirtyepic@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: FHS compliant KDE install and multi-version support
Date: Sat, 20 Sep 2008 17:41:22
Message-Id: 20080920114025.086d3057@halo.dirtyepic.sk.ca
In Reply to: [gentoo-dev] FHS compliant KDE install and multi-version support by "Jorge Manuel B. S. Vicetto"
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

Attachments

File name MIME type
signature.asc application/pgp-signature