[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev]  Re: FHS compliant KDE install and multi-version support
From:       Ryan Hill <dirtyepic () gentoo ! org>
Date:       2008-09-20 17:40:25
Message-ID: 20080920114025.086d3057 () halo ! dirtyepic ! sk ! ca
[Download RAW message or body]


On Sun, 07 Sep 2008 02:05:07 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:

> We've been trying to find a way that
> will allow users to do an FHS compliant install if they want it,
> while at the same time still allowing those that are not interested
> in it to keep using the current scheme. Our first attempt was to use
> a multislot use flag[1]. According to that flag, we would set the
> SLOT and the PREFIX for the install. That has the a very important
> problem - it breaks the invariancy of the SLOT and as thus been put
> aside. The next step was to use a kdeprefix use flag[2]. This flag no
> longer touches the SLOT that is set to "4" for all kde-4.X versions.
> It only determines if the package will be installed under the FHS
> compliant location (/usr) or under the old location
> (/usr/kde/<version>). This however means the users will no longer
> have the option to have more than one kde-4.X version installed.
> I've been thinking on a different method. With this method [3], we
> would keep using the <major>.<minor> slots (4.1, 4.2, etc) so we also
> wouldn't break the invariancy. We would allow users to select whether
> to have an FHS compliant install or not (the way to allow that still
> needs to be discussed) and we would set the prefix based on that. In
> case the user wants an FHS compliant install, the eclasses would
> block all kde packages on other slots - except 3.5 (uses other
> eclasses) and the live versions (for the above reason that it will
> always be installed under /usr/kde/<live-version>). One way to decide
> whether to install on an FHS compliant location would be to add a use
> flag, but I don't think adding that flag for 200+ ebuilds makes sense
> as it doesn't make sense to have 1 version of some packages and
> possibly 2 or more of other packages.
> 
> So, what am I after in this email? After having an internal discussion
> and then opening it up to users in #gentoo-kde and a few other people
> on #gentoo-portage, it was suggested I sent a mail here to open this
> discussion to everyone and to present the case in a more clear manner.
> So, can anyone suggest a good way to accomplish what were trying to
> do? At least a better solution than the ones I've presented above? I
> would also welcome suggestions on how to configure if the user wants
> an FHS compliant install or not (I've thought about setting this var
> on /etc). In case someone is thinking on suggesting it, ignoring FHS
> or not allowing the install of multiple versions are not valid
> solutions to this problem.

My advice is to either go all in or not.  Dicking around with SLOTs
and USE flags is only going to do more harm than good, as the multislot
USE flag has demonstrated time and time again.

Personally I would just go with upstream.  I don't know why someone
would need 4.1, 4.2, etc. installed simultaneously.  But I'm not the
one supporting it so...


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]