RFC: Fedora 8 and KDE 4
kevin.kofler at chello.at
Wed May 23 21:29:59 UTC 2007
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
> How will this stuff work with multilib?
Depending on how exactly we pick the prefix, either there would be one symlink
tree (with a few non-symlink files) under /usr/lib/kde-3.5 and one
under /usr/lib64/kde-3.5, and non-multilib stuff (like the config directories)
could just symlink to the same place, or the /usr/kde-3.5 prefix would be
multilibbed the same way /usr is (/usr/kde-3.5/lib and /usr/kde-3.5/lib64
separate, the rest common). Either way, I don't see the problem there.
> How will it interact with backup systems?
The same way any other symlinks do, if your backup systems don't handle
symlinks, you already lose.
> How will resorption happen in one release cycle?
It would just stay, this would only affect compat libs anyway.
And under the scheme I suggested, kdelibs3 (or compat-kdelibs or
compat-kdelibs3, we're waiting for FPC for a clear naming policy there, as all
3 schemes are in use right now) wouldn't even be affected, only kdelibs3-devel
would, that package you wouldn't let us keep installed at all (except at the
expense of the KDE 4 kdelibs-devel), so apparently you don't need it installed
anyway, so why do you care?
As for SELinux, I'm sure that working together with SELinux policy experts will
get the prefix labeled correctly without any problems, assuming such labeling
is needed at all (as, as I said, most of the content in that prefix would be
symlinks to real files under the regular prefix under that scheme).
There might be other reasons for not using the setup I suggested, but the ones
you gave weren't it. However, it is just a suggestion; we might actually end up
with a completely different solution (ideally, upstream will just fix their
conflicts), and rest assured that technical reasons why such a scheme wouldn't
work won't be ignored. Also note that there are going to be at least 2
experienced packagers (Than Ngo and Rex Dieter) reviewing my suggestions, as
they are the KDE maintainers in Fedora, I'm just the volunteer who packaged the
KDE 4 developer previews.
More information about the fedora-devel-list