Re: creating relocatable packages with dpkg
--- Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
> Right. I'm not sure what your end goal is, though, so I hesitate to
> provide a less general solution.
I'm trying to do two related but somewhat different things, but for now let me
keep things simple and just concentrate on the first item that I originally
stated:
--- 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
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.
--- 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.
The problem that I see with the maintenance scripts is that they are looking
for utilities in <instdir>/ rather than /. There wouldn't be a problem if
they looked in /, or if there was at least an option for that.
--- 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.
> - 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.
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.
- Rich
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Reply to: