[gentoo-dev] FHS compliant KDE install and multi-version support

[gentoo-dev] FHS compliant KDE install and multi-version support

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

Some members of the KDE team have been talking for some time about
having a FHS compliant install (define KDE prefix as /usr instead of
/usr/kde/<version>). The most important consequence of that option is
that it won't be possible to have 2 or more KDE versions installed at
the same time - it's important to note this restriction doesn't affect
kde-3.5 as it uses different eclasses that install it under /usr/kde/3.5
and the live version as everyone on the team seems to agree that it
should always be installed into /usr/kde/<live-version>.
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.


~ [1] - The commit where it was added was
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=e3a8156bd504e4a377d4eedee123252136da821d

It boiled down to the following:

# setting the slot dep
~                if [[ "${KDEBASE}" == "kde-base" ]]; then
~                        case ${PV} in
~                                3.9*)   _kdedir="3.9" ;;
- -                               4.0.8*| 4.0.9* | 4.1*)  _kdedir="4.1"
- -                                       _pv="-${PV}:4.1" ;;
+                               4.0.8*| 4.0.9* | 4.1*)
+                                       _kdedir="4.1"
+                                       if use multislot; then
+                                               _pv="-${PV}:4.1"
+                                       else
+                                               _pv="-${PV}:4"
+                                       fi
+                                       ;;

# setting the prefix
- -       KDEDIR="/usr/kde/${_kdedir}"
- -       KDEDIRS="/usr:/usr/local:${KDEDIR}"
+       # If the multislot USE flag is set use multiple slots for minor
versions
+       if use multislot; then
+               KDEDIR="/usr/kde/${_kdedir}"
+               KDEDIRS="/usr:/usr/local:${KDEDIR}"
+       else
+               KDEDIR="/usr"
+               KDEDIRS="/usr:/usr/local"
+       fi

# setting the slot
+       # The svn versions always need their own slot
~        if [[ -n ${KDEBASE} ]]; then
~                if [[ ${NEED_KDE} = svn ]]; then
~                        SLOT="kde-svn"
~                else
- -                       case ${PV} in
- -                               4.0.8* | 4.0.9* | 4.1*) SLOT="4.1" ;;
- -                               *) SLOT="kde-4" ;;
- -                       esac
+                       # Assign the slot
+                       if use multislot; then
+                               case ${PV} in
+                                       4.0.8* | 4.0.9* | 4.1*)
+                                               SLOT="4.1" ;;
+                                       *) SLOT="kde-4" ;;
+                               esac
+                       else
+                               SLOT="4"
+                       fi
~                fi
~        fi


~ [2] - The commit where it was added was
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commitdiff;h=e13fabc21a97634c3c9467e02380c99f07f7defe

It boiled down to the following:

# setting the slot dep
~                                4.0.8*| 4.0.9* | 4.1*)
~                                        _kdedir="4.1"
- -                                       if use multislot; then
- -                                               _pv="-${PV}:4.1"
- -                                       else
- -                                               _pv="-${PV}:4"
- -                                       fi
+                                       _pv="-${PV}:4"
~                                        ;;

# setting the prefix
- -       # If the multislot USE flag is set use multiple slots for minor
versions
- -       if use multislot; then
+       # If the kdeprefix USE flag is set use the /usr/kde/ prefix
+       if use kdeprefix; then
~                KDEDIR="/usr/kde/${_kdedir}"
- -               KDEDIRS="/usr:/usr/local:${KDEDIR}"
+               KDEDIRS=":${KDEDIR}:/usr:/usr/local"

# setting the slot
- -                       if use multislot; then
- -                               case ${PV} in
- -                                       4.0.8* | 4.0.9* | 4.1*)
- -                                               SLOT="4.1" ;;
- -                                       *) SLOT="kde-4" ;;
- -                               esac
- -                       else
- -                               SLOT="4"
- -                       fi
+                       case ${PV} in
+                               4.0.8* | 4.0.9* | 4.1*) SLOT="4" ;;
+                               *) SLOT="kde-4" ;;
+                       esac

~ [3] - I haven't commited this anywhere yet, so there's no diff to link to.

The basic idea is the following though:

# relevant vars
FHS_Install        # If set to true the user wants to have KDE installed
under /usr and not /usr/kde/<version>
KDE_SLOTS          # The SLOTS used by KDE (this won't include 3.5 as it
uses other eclasses and the live-ebuilds that will use the following
var. If there's no reason not to, it will include kde-5.X SLOTS when we
get there)
KDE_LIVE_SLOTS     # The slots for live ebuilds (why a var for this? We
currently use kde-svn, but I think we should think on moving to live as
KDE is talking about switching to other SCMs, possibly GIT)

# setting the slot dep
~                if [[ "${KDEBASE}" == "kde-base" ]]; then
~                        case ${PV} in
~                                3.9*)   _kdedir="3.9" ;;
~                                4.0.8*| 4.0.9* | 4.1*)
~                                        _kdedir="4.1"
~                                        _pv="-${PV}:4.1"
~                                        ;;

# setting the prefix
~        # If the user wants a FHS compliant install
~        if FHS_Install; then
~                KDEDIR="/usr"
~                KDEDIRS="/usr:/usr/local"
~        else
~                KDEDIR="/usr/kde/${_kdedir}"
~                KDEDIRS="/usr:/usr/local:${KDEDIR}"
~        fi

# setting the slot
~                        case ${PV} in
~                                4.0.8* | 4.0.9* | 4.1*)
~                                        SLOT="4.1" ;;
~                                *) SLOT="kde-4" ;;
~                        esac

# setting the slot vars
KDE_SLOTS=( "kde-4" "4.1" )
KDE_LIVE_SLOTS=( "kde-svn" )

# setting the blocks if FHS_Install is set
if [[ ${FHS_Install} == "true" ]]; then
~        for KDE_SLOT in ${KDE_SLOTS[@]}; do
~                # block other slots
~                if [[ ${SLOT} != ${KDE_SLOT} ]]; then
~                        DEPEND="${DEPEND} !kde-base/*:${KDE_SLOT}"
~                        RDEPEND="${RDEPEND} !kde-base/*:${KDE_SLOT}"
~                fi
~        done
fi

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjDNtMACgkQcAWygvVEyAJyMQCfYc0wwbiOXp5Bhj3g0m7ddId4
wxgAoItXCusO4crG0j8eNLLBqhPtP/u2
=C+B6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

On Sun, 2008-09-07 at 02:05 +0000, Jorge Manuel B. S. Vicetto wrote:
> 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>).

The big problem with that idea is that upgrading from one version to
another will be very painful as portage will yell with a million
blockers.

The only proper way to do it is to stop the /usr/kde madness for
everyone and just install everything in /usr like everyone else does, if
upstream wanted it to be parallel installable, they would have made it
that way (like gnome 1.x vs gnome 2.x).


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[George Shapovalov]

Sunday, 7. September 2008, Olivier Crête Ви написали:
> The only proper way to do it is to stop the /usr/kde madness for
> everyone and just install everything in /usr like everyone else does,
I am afraid, that would be quite unacceptable for many of us. So I'd suggest 
another "proper" way of doing this - just keep it as it is :).

George

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Philip Webb]

080907 Jorge Manuel B. S. Vicetto wrote:
> ignoring FHS ... are not valid solutions to this problem.

Why ?  Who is demanding FHS compliance & for what reasons ?
Gentoo is not like other distros & sometimes needs to find its own way.
Given the well-known problems with KDE 4.0 & (still) 4.1 ,
I'ld like to be able to have the option of multiple versions available.

I really do appreciate the hard volunteer work the KDE team donates
& have nothing but thanks to them all, but shouldn't your priority be
to get KDE 4.1 into 'testing', so that users can actually try it out ?
There's also 3.5.10 , which has been released, but isn't in Gentoo yet.

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Josh Saddler]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

Philip Webb wrote:
> I really do appreciate the hard volunteer work the KDE team donates
> & have nothing but thanks to them all, but shouldn't your priority be
> to get KDE 4.1 into 'testing', so that users can actually try it out ?
> There's also 3.5.10 , which has been released, but isn't in Gentoo yet.

In fairness, their priority is whatever they *want* to do. No one has 
the right to dictate what they should and should not be doing -- except 
themselves. Maybe figuring out the install path is a precursor to all that?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Peter Volkov]

В Вск, 07/09/2008 в 02:05 +0000, Jorge Manuel B. S. Vicetto пишет:
> 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.

Could you explain in a little bit more details why it's bad? How portage
workarounds this now for binutils?

In any case as FHS and /usr/kde/<version> installations should set
differently SLOT seems that new portage feature is required... May be
portage should allow setting SLOT in dependence on USE flag? Or new
property for PROPERTIES called multislot which will workaround the
problem with "invariancy of the SLOT"?

-- 
Peter.

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Richard Freeman]

Josh Saddler wrote:
> In fairness, their priority is whatever they *want* to do. No one has 
> the right to dictate what they should and should not be doing -- except 
> themselves. Maybe figuring out the install path is a precursor to all that?
> 

Couldn't agree more that (within reason) the ebuild team really ought to 
be making the decisions since they have to implement it.

As far as the benefits of FHS-compliance goes - I for one would love to 
not have to reference paths to kde files that change every time a new 
version comes out.  Then again, that could potentially be solved with 
symlinks as is commonly done with /usr/src/linux.

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Marcus D. Hanwell]

Olivier Crête wrote:
> On Sun, 2008-09-07 at 02:05 +0000, Jorge Manuel B. S. Vicetto wrote:
>   
>> 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>).
>>     
>
> The big problem with that idea is that upgrading from one version to
> another will be very painful as portage will yell with a million
> blockers.
>
> The only proper way to do it is to stop the /usr/kde madness for
> everyone and just install everything in /usr like everyone else does, if
> upstream wanted it to be parallel installable, they would have made it
> that way (like gnome 1.x vs gnome 2.x).
>   
I agree that this blocker idea is a non-starter. Personally I don't see 
what is wrong with the idea of having ebuilds in an overlay using the 
4.2 slot when it is time, developers/interested users test the ebuilds 
there, they can be in their own slot and when the release is made that 
are moved to slot 4 and put in the tree.

There is nothing stopping us from having multiple slotted versions in 
overlays for testing purposes. We can only have one FHS compliant 
install. This means users do not build up multiple minor versions of KDE 
over the years, possibly not realising and not removing them.

It also means third party KDE applications can be installed in /usr (as 
they always have been) and will simply relink to the latest version of 
kdelibs after an upgrade, rather than requiring a rebuild if you want 
them to use the latest kdelibs. I do not think we are removing that many 
options and I think for most users have one slot for KDE 4 would be most 
useful, I myself would rather use it that way.

I am sure it would be possible to multiply slot Gnome minor versions too 
if the team really wanted to, I don't honestly think it is necessary for 
most people. For those that need it we can have slotted ebuilds in an 
overlays that could still coexist with the ebuilds in the tree. To offer 
ultimate flexibility being able to change the slot would be nice, but 
honestly I think having some ebuilds in an overlay with a different slot 
would be fine.

Another point is that currently everything is still slotted, 4.0, 4.1 
and scm versions. It is only when 4.2 is released that we will have an 
actual version that cannot be slotted if we stay with this scheme, which 
I think we should.

Thanks,

Marcus

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

On Sun, 07 Sep 2008 17:24:55 +0400
Peter Volkov <pva@gentoo.org> wrote:
> В Вск, 07/09/2008 в 02:05 +0000, Jorge Manuel B. S. Vicetto пишет:
> > 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.
> 
> Could you explain in a little bit more details why it's bad? How
> portage workarounds this now for binutils?

Portage uses the metadata cached slot when doing dep resolution, so it
goes spectacularly wrong.

> In any case as FHS and /usr/kde/<version> installations should set
> differently SLOT seems that new portage feature is required... May be
> portage should allow setting SLOT in dependence on USE flag?

So what's the slot when SLOT="foo? ( 1 ) bar? ( 2 )"? And should you be
able to have the same KDE version with both USE=multislot and
USE=-multislot installed at the same time?

Unfortunately, the issue's not as simple as allowing conditionals in
SLOT in a future EAPI.

> Or new property for PROPERTIES called multislot which will workaround
> the problem with "invariancy of the SLOT"?

Uh, how would that work?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Philip Webb wrote:
> 080907 Jorge Manuel B. S. Vicetto wrote:
>   
>> ignoring FHS ... are not valid solutions to this problem.
>>     
>
> Why ?  Who is demanding FHS compliance & for what reasons ?
> Gentoo is not like other distros & sometimes needs to find its own way.
> Given the well-known problems with KDE 4.0 & (still) 4.1 ,
> I'ld like to be able to have the option of multiple versions available.
>
> I really do appreciate the hard volunteer work the KDE team donates
> & have nothing but thanks to them all, but shouldn't your priority be
> to get KDE 4.1 into 'testing', so that users can actually try it out ?
> There's also 3.5.10 , which has been released, but isn't in Gentoo yet.
>
>   

As a lowly user, I would like to keep KDE 3.5.* for quite a while and 
will most likely not switch until at least 4.3 or better is out.  Even 
that mostly depends on how many "issues" are still left out there.

I realize that I'm not behind the scenes doing the work to keep both 
maintained but they are going to both be maintained anyway and leaving 
it like it is has worked fine so far.  Unless there is some requirement 
upstream, I would prefer it be like it is so that we can still choose.  
I will most likely maintain both KDE 3 and KDE 4 until things get sorted 
out and I make sure everything works.

Nothing worse than upgrading, realizing that the new version isn't ready 
for my needs yet and having to recompile KDE all over again.  Having 
both would be really nice. 

My $0.02 worth.

Dale

:-)

[-- Attachment #2: Type: text/html, Size: 1987 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Marcus D. Hanwell]

Dale wrote:
> Philip Webb wrote:
>> 080907 Jorge Manuel B. S. Vicetto wrote:
>>   
>>> ignoring FHS ... are not valid solutions to this problem.
>>>     
>>
>> Why ?  Who is demanding FHS compliance & for what reasons ?
>> Gentoo is not like other distros & sometimes needs to find its own way.
>> Given the well-known problems with KDE 4.0 & (still) 4.1 ,
>> I'ld like to be able to have the option of multiple versions available.
>>
>> I really do appreciate the hard volunteer work the KDE team donates
>> & have nothing but thanks to them all, but shouldn't your priority be
>> to get KDE 4.1 into 'testing', so that users can actually try it out ?
>> There's also 3.5.10 , which has been released, but isn't in Gentoo yet.
>>     
> As a lowly user, I would like to keep KDE 3.5.* for quite a while and 
> will most likely not switch until at least 4.3 or better is out.  Even 
> that mostly depends on how many "issues" are still left out there.
The slotting of KDE 3.* and KDE 4.* was never a question - these will 
always remain slottable. The question is whether we really need to keep 
slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 and 4.2 
slotted on the same system. I think the benefits of an FHS compliant, 
non-slottable (with other KDE 4 minor versions) install is the best 
thing for our general user base.

I also see how we can have slots outside of FHS for developers, power 
users and the ones who just like to be different ;-) These can be 
maintained in an overlay and use different slots than the ebuilds in the 
main tree. It is no real issue to be able to run a slotted KDE 4.2 
install alongside an FHS install of KDE 4.* and so FHS installs can be 
successfully slotted with other kdeprefix installs too.

This helps to make the normal KDE install much simpler to maintain with 
less gradual build up of cruft over the years (multiple older slots the 
user is no longer using). It also brings us into line with the FHS 
compliant Qt 4 ebuilds  and other desktops such as Gnome. The purpose of 
these posts was to solicit further feedback before things are pushed to 
the main tree.

Most other distributions install KDE into the main /usr hierarchy, that 
is the way upstream intends KDE to be installed and I think it will work 
well for most users. I do think Gentoo is about choice and so having 
overlays with ebuilds in a different slot seems to be the best solution 
we can offer given the constraint of slot invariance.

Thanks,

Marcus

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Dale]

Marcus D. Hanwell wrote:
> Dale wrote:
>> Philip Webb wrote:
>>> 080907 Jorge Manuel B. S. Vicetto wrote:
>>>  
>>>> ignoring FHS ... are not valid solutions to this problem.
>>>>     
>>>
>>> Why ?  Who is demanding FHS compliance & for what reasons ?
>>> Gentoo is not like other distros & sometimes needs to find its own way.
>>> Given the well-known problems with KDE 4.0 & (still) 4.1 ,
>>> I'ld like to be able to have the option of multiple versions available.
>>>
>>> I really do appreciate the hard volunteer work the KDE team donates
>>> & have nothing but thanks to them all, but shouldn't your priority be
>>> to get KDE 4.1 into 'testing', so that users can actually try it out ?
>>> There's also 3.5.10 , which has been released, but isn't in Gentoo yet.
>>>     
>> As a lowly user, I would like to keep KDE 3.5.* for quite a while and 
>> will most likely not switch until at least 4.3 or better is out.  
>> Even that mostly depends on how many "issues" are still left out there.
> The slotting of KDE 3.* and KDE 4.* was never a question - these will 
> always remain slottable. The question is whether we really need to 
> keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 
> and 4.2 slotted on the same system. I think the benefits of an FHS 
> compliant, non-slottable (with other KDE 4 minor versions) install is 
> the best thing for our general user base.
>
> I also see how we can have slots outside of FHS for developers, power 
> users and the ones who just like to be different ;-) These can be 
> maintained in an overlay and use different slots than the ebuilds in 
> the main tree. It is no real issue to be able to run a slotted KDE 4.2 
> install alongside an FHS install of KDE 4.* and so FHS installs can be 
> successfully slotted with other kdeprefix installs too.
>
> This helps to make the normal KDE install much simpler to maintain 
> with less gradual build up of cruft over the years (multiple older 
> slots the user is no longer using). It also brings us into line with 
> the FHS compliant Qt 4 ebuilds  and other desktops such as Gnome. The 
> purpose of these posts was to solicit further feedback before things 
> are pushed to the main tree.
>
> Most other distributions install KDE into the main /usr hierarchy, 
> that is the way upstream intends KDE to be installed and I think it 
> will work well for most users. I do think Gentoo is about choice and 
> so having overlays with ebuilds in a different slot seems to be the 
> best solution we can offer given the constraint of slot invariance.
>
> Thanks,
>
> Marcus
>
>

To try to make my point clearer, if I can set a USE flag or some other 
config so that I can have both KDE 3.* and KDE 4.* installed at the same 
time and select which one to login into, I'm cool.  That option doesn't 
have to be available forever but long enough for KDE to get some of the 
"kinks" worked out.  I'm talking maybe 6 months to a year which will 
vary depending on the speed KDE gets things worked out and 
fixed?implemented.

I'm not hard to please by any means but I do like changes to not be a 
overnight thing.  I'm to old for things to "soak in" in a rush. 

Thanks

Dale

:-) 

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Marcus D. Hanwell]

Dale wrote:
> Marcus D. Hanwell wrote:
>> Dale wrote:
>>> Philip Webb wrote:
>>>> 080907 Jorge Manuel B. S. Vicetto wrote:
>>>>  
>>>>> ignoring FHS ... are not valid solutions to this problem.
>>>>>     
>>>>
>>>> Why ?  Who is demanding FHS compliance & for what reasons ?
>>>> Gentoo is not like other distros & sometimes needs to find its own 
>>>> way.
>>>> Given the well-known problems with KDE 4.0 & (still) 4.1 ,
>>>> I'ld like to be able to have the option of multiple versions 
>>>> available.
>>>>
>>>> I really do appreciate the hard volunteer work the KDE team donates
>>>> & have nothing but thanks to them all, but shouldn't your priority be
>>>> to get KDE 4.1 into 'testing', so that users can actually try it out ?
>>>> There's also 3.5.10 , which has been released, but isn't in Gentoo 
>>>> yet.
>>>>     
>>> As a lowly user, I would like to keep KDE 3.5.* for quite a while 
>>> and will most likely not switch until at least 4.3 or better is 
>>> out.  Even that mostly depends on how many "issues" are still left 
>>> out there.
>> The slotting of KDE 3.* and KDE 4.* was never a question - these will 
>> always remain slottable. The question is whether we really need to 
>> keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 4.1 
>> and 4.2 slotted on the same system. I think the benefits of an FHS 
>> compliant, non-slottable (with other KDE 4 minor versions) install is 
>> the best thing for our general user base.
>>
>> I also see how we can have slots outside of FHS for developers, power 
>> users and the ones who just like to be different ;-) These can be 
>> maintained in an overlay and use different slots than the ebuilds in 
>> the main tree. It is no real issue to be able to run a slotted KDE 
>> 4.2 install alongside an FHS install of KDE 4.* and so FHS installs 
>> can be successfully slotted with other kdeprefix installs too.
>>
>> This helps to make the normal KDE install much simpler to maintain 
>> with less gradual build up of cruft over the years (multiple older 
>> slots the user is no longer using). It also brings us into line with 
>> the FHS compliant Qt 4 ebuilds  and other desktops such as Gnome. The 
>> purpose of these posts was to solicit further feedback before things 
>> are pushed to the main tree.
>>
>> Most other distributions install KDE into the main /usr hierarchy, 
>> that is the way upstream intends KDE to be installed and I think it 
>> will work well for most users. I do think Gentoo is about choice and 
>> so having overlays with ebuilds in a different slot seems to be the 
>> best solution we can offer given the constraint of slot invariance.
>
> To try to make my point clearer, if I can set a USE flag or some other 
> config so that I can have both KDE 3.* and KDE 4.* installed at the 
> same time and select which one to login into, I'm cool.  That option 
> doesn't have to be available forever but long enough for KDE to get 
> some of the "kinks" worked out.  I'm talking maybe 6 months to a year 
> which will vary depending on the speed KDE gets things worked out and 
> fixed?implemented.
Your point was perfectly clear and I thought I had been clear in that 
option is present and will continue to be so for as long as KDE 3.5 is 
in the tree. That could be years, depending mainly upon whether upstream 
continues to provide security fixes in some form.
>
> I'm not hard to please by any means but I do like changes to not be a 
> overnight thing.  I'm to old for things to "soak in" in a rush.
> Thanks
I think we all know that most people will try KDE 4 whilst maintaining 
their old KDE 3.5 desktop. I only use KDE 3.5 for testing things now but 
still run quite a few KDE 3 apps in my KDE 4 desktop session. I hope 
this reply makes it very clear that slotting of KDE 3.5 with with KDE 4 
is not something that is going away. You will have at least two options 
(KDE 3.5 or KDE 4), some people might prefer more (KDE 3.5, KDE 4.0, KDE 
4.1, KDE 4.2, KDE 4.3...) but I think that is overkill for most (and 
probably always was).

Thanks,

Marcus

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Philip Webb]

080907 Marcus D. Hanwell wrote:
> The slotting of KDE 3.* and KDE 4.* was never a question
> but whether we really need to keep slotting of minor KDE versions
> in the new 4.* line, i.e. KDE 4.1 and 4.2 slotted on the same system.

Yes, I understood that (smile).

> It is no real issue to be able to run a slotted KDE 4.2 install
> alongside an FHS install of KDE 4.* <via an overlay>.

In that case, much of my unease disappears:
users should be willing to learn how to use overlays.

> This helps to make the normal KDE install much simpler to maintain
> with less gradual build up of cruft over the years,
> ie multiple older slots the user is no longer using.
> It also brings us into line with the FHS compliant Qt 4 ebuilds

Yes, if there is a genuine improvement in maintainability for the devs,
that's a real reason for making the change.

In another msg, you said nothing will change till 4.2 ( 0901xx )
& by then hopefully KDE 4 will have settled down to normal usability.

> The purpose of these posts was to solicit further feedback
> before things are pushed to the main tree.

Well, you have mine (grin).

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Dale]

Marcus D. Hanwell wrote:
> Dale wrote:
>> Marcus D. Hanwell wrote:
>>> Dale wrote:
>>>> Philip Webb wrote:
>>>>> 080907 Jorge Manuel B. S. Vicetto wrote:
>>>>>  
>>>>>> ignoring FHS ... are not valid solutions to this problem.
>>>>>>     
>>>>>
>>>>> Why ?  Who is demanding FHS compliance & for what reasons ?
>>>>> Gentoo is not like other distros & sometimes needs to find its own 
>>>>> way.
>>>>> Given the well-known problems with KDE 4.0 & (still) 4.1 ,
>>>>> I'ld like to be able to have the option of multiple versions 
>>>>> available.
>>>>>
>>>>> I really do appreciate the hard volunteer work the KDE team donates
>>>>> & have nothing but thanks to them all, but shouldn't your priority be
>>>>> to get KDE 4.1 into 'testing', so that users can actually try it 
>>>>> out ?
>>>>> There's also 3.5.10 , which has been released, but isn't in Gentoo 
>>>>> yet.
>>>>>     
>>>> As a lowly user, I would like to keep KDE 3.5.* for quite a while 
>>>> and will most likely not switch until at least 4.3 or better is 
>>>> out.  Even that mostly depends on how many "issues" are still left 
>>>> out there.
>>> The slotting of KDE 3.* and KDE 4.* was never a question - these 
>>> will always remain slottable. The question is whether we really need 
>>> to keep slotting of minor KDE versions in the new 4.* line, i.e. KDE 
>>> 4.1 and 4.2 slotted on the same system. I think the benefits of an 
>>> FHS compliant, non-slottable (with other KDE 4 minor versions) 
>>> install is the best thing for our general user base.
>>>
>>> I also see how we can have slots outside of FHS for developers, 
>>> power users and the ones who just like to be different ;-) These can 
>>> be maintained in an overlay and use different slots than the ebuilds 
>>> in the main tree. It is no real issue to be able to run a slotted 
>>> KDE 4.2 install alongside an FHS install of KDE 4.* and so FHS 
>>> installs can be successfully slotted with other kdeprefix installs too.
>>>
>>> This helps to make the normal KDE install much simpler to maintain 
>>> with less gradual build up of cruft over the years (multiple older 
>>> slots the user is no longer using). It also brings us into line with 
>>> the FHS compliant Qt 4 ebuilds  and other desktops such as Gnome. 
>>> The purpose of these posts was to solicit further feedback before 
>>> things are pushed to the main tree.
>>>
>>> Most other distributions install KDE into the main /usr hierarchy, 
>>> that is the way upstream intends KDE to be installed and I think it 
>>> will work well for most users. I do think Gentoo is about choice and 
>>> so having overlays with ebuilds in a different slot seems to be the 
>>> best solution we can offer given the constraint of slot invariance.
>>
>> To try to make my point clearer, if I can set a USE flag or some 
>> other config so that I can have both KDE 3.* and KDE 4.* installed at 
>> the same time and select which one to login into, I'm cool.  That 
>> option doesn't have to be available forever but long enough for KDE 
>> to get some of the "kinks" worked out.  I'm talking maybe 6 months to 
>> a year which will vary depending on the speed KDE gets things worked 
>> out and fixed?implemented.
> Your point was perfectly clear and I thought I had been clear in that 
> option is present and will continue to be so for as long as KDE 3.5 is 
> in the tree. That could be years, depending mainly upon whether 
> upstream continues to provide security fixes in some form.
>>
>> I'm not hard to please by any means but I do like changes to not be a 
>> overnight thing.  I'm to old for things to "soak in" in a rush.
>> Thanks
> I think we all know that most people will try KDE 4 whilst maintaining 
> their old KDE 3.5 desktop. I only use KDE 3.5 for testing things now 
> but still run quite a few KDE 3 apps in my KDE 4 desktop session. I 
> hope this reply makes it very clear that slotting of KDE 3.5 with with 
> KDE 4 is not something that is going away. You will have at least two 
> options (KDE 3.5 or KDE 4), some people might prefer more (KDE 3.5, 
> KDE 4.0, KDE 4.1, KDE 4.2, KDE 4.3...) but I think that is overkill 
> for most (and probably always was).
>
> Thanks,
>
> Marcus
>
>

I agree, having slots for 4.1, 4.2, 4.3 etc is a bit much.  KDE 3 and 
KDE 4 are supposed to be very different desktops.  The difference 
between KDE 4.1, 4.2 should only be bug fixes and adding more 
features/programs.

I think I will be a happy camper after your posts.  Thanks for shedding 
some light on this for me, and most likely others.

Dale

:-)  :-)

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Jan Kundrát]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Jorge Manuel B. S. Vicetto wrote:
> Some members of the KDE team have been talking for some time about
> having a FHS compliant install (define KDE prefix as /usr instead of
> /usr/kde/<version>).

What are benefits of such a change? What happens when KDE release a 
version breaking ABI (like "KDE 5")?

Right now [1], there's a conflict between some non-kdelibs kde3 
libraries (kexiv2, kdcraw) from KDE3 and KDE4, mainly KDE4 applications 
being linked with KDE3 libraries. I don't expect ABI breakage in 4.x, 
but what happens after it?

Will I be able to use my desktop in the middle of an upgrade from 4.x to 
4.(x+1), when only half of the packages are already updated?

> 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.

I might have missed something in your mail, but if you put, say, 4.1 and 
4.2 libraries straight into /usr/lib, are you completely positive stuff 
won't break?

[1] "Now" being the 3.5.9 release in Portage tree and 4.1.0 in an overlay

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Marcus D. Hanwell]

Jan Kundrát wrote:
> Jorge Manuel B. S. Vicetto wrote:
>> Some members of the KDE team have been talking for some time about
>> having a FHS compliant install (define KDE prefix as /usr instead of
>> /usr/kde/<version>).
> What are benefits of such a change? What happens when KDE release a 
> version breaking ABI (like "KDE 5")?
We would have the option of using a kde prefix in order to slot it with 
KDE 4, other distros have worked hard to actually slot KDE 3 and 4 
installed in /usr/ this time around. Ideally we would work with them to 
achieve a similar outcome. We would certainly still have options if and 
when this happens, i.e. using an alternate prefix so that they can be 
slotted or truly slotting the two in /usr.
>
> Right now [1], there's a conflict between some non-kdelibs kde3 
> libraries (kexiv2, kdcraw) from KDE3 and KDE4, mainly KDE4 
> applications being linked with KDE3 libraries. I don't expect ABI 
> breakage in 4.x, but what happens after it?
kexiv2 etc are effectively KDE libraries that have recently moved to be 
developed in KDE's repository. We were discussing whether they should 
continue to be bumped in the media-libs category or not. This is a 
recent move and they are certainly not core libs. I haven't checked yet 
but I am not sure whether they break API or not.
>
> Will I be able to use my desktop in the middle of an upgrade from 4.x 
> to 4.(x+1), when only half of the packages are already updated?
The KDE apps should just link to the latest kdelibs, KDE guarantees ABI 
stability and so this should be an easy process. It is possible this 
will not always be as smooth as we would like with libkdeedu etc. Can 
Gnome guarantee that everything will continue to work at all stages of 
the upgrade too? I am not sure how I can effectively test that and make 
a promise but from my experience as long as we upgrade the libs first 
and the apps second everything will work well.
>> 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.
>
> I might have missed something in your mail, but if you put, say, 4.1 
> and 4.2 libraries straight into /usr/lib, are you completely positive 
> stuff won't break
So long as things are upgraded libraries first, then applications (as 
specified by the deps) then this should not cause any issues. Although 
we will continue having KDE 4.2 applications depend on >= 4.2.

[gentoo-dev] Re: FHS compliant KDE install and multi-version support

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Hi,

"Marcus D. Hanwell" <cryos@gentoo.org>:
> We would have the option of using a kde prefix in order to slot it
> with KDE 4, other distros have worked hard to actually slot KDE 3 and
> 4 installed in /usr/ this time around. Ideally we would work with
> them to achieve a similar outcome. We would certainly still have
> options if and when this happens, i.e. using an alternate prefix so
> that they can be slotted or truly slotting the two in /usr.

 Be FHS compliant if upstream intends so (I read that from your blog)
and make major versions slottable as you intend.  I say, go for it.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Peter Volkov]

В Вск, 07/09/2008 в 15:34 +0100, Ciaran McCreesh пишет:
> On Sun, 07 Sep 2008 17:24:55 +0400
> Peter Volkov <pva@gentoo.org> wrote:
> > In any case as FHS and /usr/kde/<version> installations should set
> > differently SLOT seems that new portage feature is required... May be
> > portage should allow setting SLOT in dependence on USE flag?
> 
> So what's the slot when SLOT="foo? ( 1 ) bar? ( 2 )"?

This syntax is not applying in our situation. Expression in SLOT should
return only one value at a time. Something like this

SLOT="foo:enabled?disabled"
SLOT="foo:fooenabled?bar:barenabled?bardisabled"

> And should you be able to have the same KDE version with both
> USE=multislot and USE=-multislot installed at the same time?

There are different SLOTs for different USE flags combination and
package manager should allow installation same package in different
SLOTs. But may be it's useful give developer possibility to disable that
( SLOT="foo::enabled?disabled" ).

Ah, and this is bug 174407.

> > Or new property for PROPERTIES called multislot which will workaround
> > the problem with "invariancy of the SLOT"?
> 
> Uh, how would that work?

For ebuilds with such property (may be better name dynamicslot or
dynslot) PM should source package with use flags set to get SLOT. Of
course it's possible to cache results, sourcing package with all
different USE flags combinations during cache generation.

-- 
Peter.

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

On Mon, 08 Sep 2008 11:48:03 +0400
Peter Volkov <pva@gentoo.org> wrote:
> > And should you be able to have the same KDE version with both
> > USE=multislot and USE=-multislot installed at the same time?
> 
> There are different SLOTs for different USE flags combination and
> package manager should allow installation same package in different
> SLOTs.

That'd require fairly hefty vdb changes. Which, whilst a good thing,
makes it very definitely a long term feature.

> > > Or new property for PROPERTIES called multislot which will
> > > workaround the problem with "invariancy of the SLOT"?
> > 
> > Uh, how would that work?
> 
> For ebuilds with such property (may be better name dynamicslot or
> dynslot) PM should source package with use flags set to get SLOT. Of
> course it's possible to cache results, sourcing package with all
> different USE flags combinations during cache generation.

a) PROPERTIES can't be used to implement any mandatory feature, and b)
multiply half a second to however many packages there are using this
feature and add that to the resolution time. The metadata cache is
necessary.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] FHS compliant KDE install and multi-version support

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> a) PROPERTIES can't be used to implement any mandatory feature

This is true in the absence of an EAPI bump. However, for
completeness, I'd like to mention that it is possible to specify
that a given PROPERTIES value have mandatory support in a new EAPI.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjFUMoACgkQ/ejvha5XGaOe3QCeMpfjBytS4QRGLVxb/DDQ2B6O
ynkAnAjNiIQmK6I3LPQUQ4HwMGR4HRMy
=+P7L
-----END PGP SIGNATURE-----

[gentoo-dev] Re: FHS compliant KDE install and multi-version support

[Steve Long]

Jorge Manuel B. S. Vicetto wrote:

> 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.
If that stops _all_ users from doing so, I'd vote against.

> 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.
>
Perhaps FHS is more of a feature than a USE flag? It certainly could apply
to other packages, and as you say adding and maintaining the USE flag
to/for so many ebuilds is a bit of a pain.
 
> 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?

Just a thought, but this sounds an awful lot like a prefix ebuild. Is there
any relevance from grobian's work?

Wrt to the blocks, it doesn't strike me that major iff the user has set FHS
in FEATURES (or w/e the mechanism is) since in that case they will be on
the "manage everything for me, for this install" track.

[gentoo-dev] Re: FHS compliant KDE install and multi-version support

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 3197 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]