Re: deb 'streams', 'capabilities', relocation
Colin Watson wrote:
>
> "Christopher W. Curtis" <ccurtis@aet-usa.com> wrote:
> >Another capability that I would like to see is "Relocatable". This
> >option would allow you to move a package from the default location, say
> >/usr/bin, to a shared structure, like /export/linux/i386/bin.
> >
> >The method I have in mind for making this possible would not require the
> >assistance of a package building tool. Quite simply, when doing a
> >'configure', make the target directory something like
> >'--prefix=/DEBIAN_RELOCATABLE_PACKAGE_FORMAT_DEFAULT_TARGET_INSTALL_DIRECTORY=/usr/bin//'.
> >Then add the 'Relocatable' capability to the package.
>
> I think a much better solution if you need this sort of thing is to
> chroot() to the relevant directory and do the installation there. It
> doesn't provide the ability to completely translate paths, but I think
> that has bad implications for stability anyway.
In no way does that solve anything. The reason for doing this and
parsing the executables is to find hardcoded strings that point off to
directories. That is, replace the string "/usr/local/var/myname/" with
a user-specified installation target that is different from the default
and that is shared among many computers. In this specific instance,
that data can be either truly local with machine-specific data and a
shared executable, or it can point to a shared directory for the data.
chroot() is not a reasonable solution.
As far as stability, I don't see the problem. The SA choses to relocate
relocatable packages and should be knowledgeable enough about the
network to do it properly. Not every package would be a candidate for
relocation (base-files, for instance). But things like the gimp most
certainly can live in a completely shared space, as can packages like
amanda, which would need both shared and local settings. If you want to
put a big disclaimer about relocating packages that's fine, but there's
no inherant stability problem with them.
Christopher
Reply to: