Re: creating relocatable packages with dpkg
On Mon, Dec 13, 2004 at 06:05:51PM -0800, No Spam wrote:
> --- No Spam <nospam420@yahoo.com> wrote:
>
> > I would like the user to be able to do the following:
> >
> > 1) Install the software in a location other than the default.
>
> --- Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
>
> > Debian handles dependencies, and so
> > to do this thoroughly and correctly, for an arbitrary package, could
> > certainly require a completely different root filesystem.
> I don't understand why this breaks dependencies, especially if I know that
> nothing else outside of my software will be depending on my software. Even if
> something else did depend on it, it ought to be possible to query the
Consider the following situation.
Package A is a text-based program. It has two major versions, 1 and
2. Major versions are incompatible because its output is in a
different format. Package B is a GUI frontend for A; it parses A's
output and is thus dependent on A's major version:
B-1 depends: A-1, conflicts: A-2.
B-2 depends: A-2, depends: A-1.
You have A-1 and B-1 installed in / (the root directory). You then
request that B-2 is installed into /alternate_fs/. As a dependency,
A-2 is pulled in, and also installed to that location. However, when
you run /alternate_fs/usr/bin/B, it just sees /usr/bin/A and crashes.
Crashing is always a bug, but the point is still valid.
This is just one package, but now imagine that every Debian package
has such dependency problems. You can imagine a case whereby you
would have to reinstall the entire system.
This is hypothetical example and its certainly unlikely that the
problem is this extreme. My point, however, remains: it is
impossible, in full generality, to meet your goal without a chroot
(debootstrap) or some other solution, considerably more complex than
what is presently in place.
> packaging system and find out where it was located. A valid answer might be
> that the general case supported is that anything can depend on anything else
> and ought to be able to rely on hardcoded paths. But that kind of system does
> cause some limitations (as I'm discovering), and having some way for the user
> to override that, if hardcoded paths are not desired, would be nice.
Right. Debian package management does not take your goal into
consideration. You would likely have to rethink all of the tools.
> --- Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
> > The maint scripts are also an interesting dilemma. Once again, it is
> > definitely possible (at least hypothetically) to do this correctly
> > without a complete "reinstall" under a new chroot.
I did not say what I intended to say.. What I meant is:
It is definitely possible (at least hypothetically) for this to
require a complete reinstall under chroot().
> --- Lo%/1€Œiso8859-15?c Minier <lool+debian@via.ecp.fr> wrote:
> > It's not an easy task you're into. I see multiple problems with
> > relocation of Debian packages:
> > - packages have dependencies which ensure that a package in a
> > particular version gets all the libs it needs installed at the
> > proper
> > place,
> > - packages expect some standard utilities in certain places (in fact
> > they can assume any part of the base system is available for
> > example
> > in maintainer scripts),
> But if I want to let a user put my software in /foo/bar, that shouldn't have
> to imply that, for example, a shell is at /foo/bar/bin/sh. I don't see how
> relocating my software should change the fact that sh is at /bin/sh. And, as
> I said above, even if that was installed elsewhere, it could be possible to
> design a packaging system that could be queried to determine that.
See above. Here, you don't seem to want a second install of sh. Above,
however, you need it (Package B).
> > - packages expect to be able to reach their own files with
> > hard-coded
> > pathnames, for example a gnome app might expect to reach its
> > pixmaps
> > in /usr/share/pixmaps.
>
> This is an assumption which may or may not be true for a given package. None
> of my packages expect to be able to reach their own files with hard-coded
> pathnames. They all rely on an environment variable to specify their own
> relative root, and everything else is relative to that.
No, that's bad. Example: The FHS says that sharable data must be in
/usr/, and if it is sharable across architectures, it should be in
/usr/share/. If every package installs itself wholly into some
subdirectory, we call it windows. If I want to run an NFS server and
share all of my sharable data, it requires (dpkg -l |wc -l) = 1269
different NFS shares.
> I guess my main point is that if I know that in my situation, that relocating
> my software is not going to be problematic, it would be nice if the packaging
> system allowed me to allow users to relocate the software without jumping
> through a bunch of hoops (like installing an entire duplicate root partition
> for each relocation instance). For what its worth, neither rpm (redhat) nor
> pkgadd (solaris) have this limitation. But I can see the viewpoint that
> allowing arbitrary user relocation of software is a bug and not a feature,
> which perhaps is the view where the debian design decision came from.
Do RPM and Solaris solve the package dependency problem of Package B?
Its not that "allowing ..." is a bug; indeed, it would be a nice
feature. However, it was not a design goal when Debian tools were
built.
IANADD,
Justin
Reply to: