23 Feb
2012
23 Feb
'12
11:27 p.m.
On 02/23/2012 10:52 AM, Darrell Anderson wrote:
I agree with this, but see below.
Where is KDE4
installed to on a arch linux install?
Oh look it installs into /usr just where tde should also
install to .
The issue is that because of conflicts, tde can not be
installed to /usr so the arch devs simply can not install it
there.
Since it is _not_ installed from a distro... I believe that
LSB states it is a locally installed package that should go
into /usr/local.
After all it is local to the boxen in question.
I have kde-3.5.10 and tde 3.5.13 installed on a single
slackware-12.2 boxen with tde installed to /usr/local. Both
easily work.
The root issue here is not where each individual wants to install
Trinity, or where upstream distro maintainers and packagers should install Trinity, but to
ensure there never is a conflict with other packages.
The sole thorn in our side is and always will be KDE4. Anybody packaging Trinity for a
distro that includes KDE4 needs to work around where KDE4 gets installed. If the upstream
maintainers are installing KDE4 to /usr, then Trinity has to be installed elsewhere. If
the upstream maintainers are installing KDE4 to someplace other than /usr, then Trinity
can be installed to /usr.
Anybody who controls the distro and decides that KDE4 is not an option can install
Trinity to /usr. Most of us do not control those decisions.
One thing is clear: as a team we do a poor job testing Trinity for conflicts with KDE4. I
don't care what KDE4 developers think about Trinity, but I don't want them
accusing us of sloppy programming or packaging. Testing Trinity for potential KDE4
conflicts needs a much higher priority for all of us. That does not mean installing to
/opt or /usr/local merely to avoid conflicts in /usr/bin and /usr/lib, but actually
testing both desktops in real time.
Build your packages where you want according to your distro or personal guidelines, but
let's focus on the real challenge of producing a robust Trinity. :)
Darrell
The reason that all of this is an issue is just because you are not
installing into /usr
Let explain
This works for arch or distros using pacman only
I create my PKGBUILDS to install into /usr.
When a user is using KDE4 that creates an issues as we all know.
I now that the location problem
So I using pacman install the exact same packages relocated to
/usr/local using pacman to do the relocation.
Pacman handles this without error and the result is that those same
packages work in an environment that has KDE4 or on that doesn't, its's
the same binary package , I am not requried to change anything. And I
only have one set of binary packages. When the conflicts are solved I
don't have to change my build script as well, just build and go. Double
win.
Now part II
When using pacman pacman will not overwrite a file that is already
installed and will complain about the file already existing.
So now to get a list os files that conflict with KDE4 all one needs to
do is to build the packages into /usr and attempt to install them on a
system with nKDE4 and bingo you have a list of those conflicts. That
gives you what needs to be renamed all very easy done.
This won't give you all the other issues but at least one has a list of
files that have the same name and installed as in KDE4.
This is central to part of the problem to move ahead and finish this
project. How is the rename to be completed if no ones knows what needs
to be done?