[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 
But it would be great if something like command
  dpkg-buildpackage --prefix=/opt/kde3 --use-pkg1==/opt/pkg1 
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 

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 

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: