On 02/23/2012 10:52 AM, Darrell Anderson wrote: >> 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. I agree with this, but see below. > > 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?