Re: Relocatable packages
>> What if you need 2 versions of the same package?
>
> That might be a reason when you first look at it. But this is quite a
> complex situation. Supporting multiple versions of one package is quite
> more difficult than simple relocation. You have to make sure that the
> one version only uses its own files and under no way those of the other
> one. You would have to make sure that each of those knows where it is
> and what to use. I doubt any system is possible, that makes this easier
> than installing on of them by compiling the source.
I agree that just installing files from binary package to a different
location is completely incorrect. I am talking about much deeper level.
The real-world situation is that people do need to have different versions
of the same package (or set of packages) on the same computer.
E.g. I want to have KDE1 and KDE2 and KDE3 installed on the server that is
used in our lab to feed X terminals. (Well, it is not the best example
because in case of KDE only KDE2 is in Debian now, just it is the first
example comes to mind).
Currently, to achieve this, someone will have to install at most one
version as .deb, and all others as sources. It is not really bad that local
compilation from sources is required - after all, there is nothing
difficult with this. The problem is that when locally compiled stuff is
installed, no tool will track which file is from where, and when some sort
of package upgrade and remove will be needed, this can be done only by
hands and will cause problems. Good example of this is KDE's "make install"
over some old KDE installations - this will result in mess in configure
modules and in other places.
In Debian, there is dpkg to handle this problem.
I realize that adding complete relocation to binary package is quite
difficult for many reasons. But why not add relocation at source level?
Of course, all packages in the archive should be compiled to go to standard
places.
But it would be great if something like command
dpkg-buildpackage --prefix=/opt/kde3 --use-pkg1==/opt/pkg1
--use-pkg2=/opt/pkg2
made a binary deb from sources, using package (library?) pkg1 installation
from /opt/pkg1, package pkg2 installation from /opt/pkg2, and the rest from
the standard places. The resulting binary package should depend on special
version of pkg1 that MUST be in /opt/pkg1 on the target system, same about
pkg2.
Even better, there may be both binary-relocatable and source-relocatable
packages. If the package contents itself supports relocation (e.g. in
contains just a binary and a manpage, and it is known that the binary does
not depend on where it is installed), it may be declared
binary-relocatable, and installed anywhere user wishes (of course, default
shoud be /usr). If the package is known to relocate correctly at
compile-time, it may be marked as source-relocatable, so if local admin
wishes to install it somewhere outside of /usr, he will just need to type a
few commands to create relocated debs (and futher automation here is
possible, up to automatic download and build-to-relocate new versions of
the package). At last, if some technical reasons don't allow a package to
be relocatable even at source level, the package should be marked as
non-relocatable.
To make it to work, dpkg should handle location-aware dependences, and some
build-time and runtime problems should be solved. But I believe it is
possible, and it is the right solution of problem of non-standard setups. I
believe that the current situation (everything that slightly differs from
standard setup requires tons of dirty handwork) is bad - definitly there
are better ways to spend time than hand-cleaning hand-made "make install"'s.
Reply to: