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

creating relocatable packages with dpkg



I'm not sure if this is the proper list for this.  I considered both
debian-user and debian-mentors.  It relates to the packaging of
software, but not that of software that will be included with the
Debian distribution, so I don't know if that's considered more of a
developer question or more of a user question.  This list
(debain-mentors) was the list mentioned in the Debian New Maintainers'
Guide, which has been my main reference point other than the man pages,
so that's why I ultimately decided on this.  Please feel free to
redirect me to the appropriate forum for this question if this is not
it.

Besides a bunch of trial and error, I've also looked at man pages, the
Debian New Maintainers' Guide, and searched through USENET and Debian
mailing list archives.  I think that I may understand what the problem
is and that the answer is just that what I want to do is not possible
(or not easily possible in the manner that I want), but I'm not totally
positive, hence this request.  If there is some other documentation
specifically dealing with package relocation of which I am not aware,
feel free to point me to it.

I am attempting to package software via OS-dependent packaging systems
and have it function cross platform across redhat, debian, and solaris.

I would like the user to be able to do the following:

1) Install the software in a location other than the default.
2) Install multiple simultaneous instances of the software (likely
   because they are different versions) in different locations.

On solaris, I can accomplish both of these with 'pkgadd -R'.  On
redhat, I can accomplish both of these with 'rpm --prefix', the only
restriction being that for (2) to work properly, the multiple instances
have to be different versions.  I am having trouble, however, getting
this to work on debian with dpkg.

Being able to do (1) is a prerequisite to doing (2), so I'll first
concentrate on the difficulties I'm having there.

If I don't have any preinst, postinst, prerm, or postrm scripts, I can
do (1) using, for example 'dpkg --instdir=/opt/foo1 -i'.  But if I have
any such scripts, it doesn't work, complaining about:

dpkg (subprocess): unable to execute new pre-installation script: No
such file or directory

My understanding is that the problem is that it's trying to chroot to
/opt/foo1, but there is no root filesystem there (for example, no
/bin/sh at /opt/foo1/bin/sh), so there's no way for it to do anything
other than simple copying of files.  Is this really what's going on? 
Is there no simple way to allow the user to relocate a small subset of
packages without relocating the whole base / install?

I wouldn't think that using --root instead of --instdir would help
matters at all.  Actually, I'm having a different set of problems using
--root, but should probably first confirm whether or not my
understanding of the --instdir problem is correct.

If I limit my package to have no scripts, such that (1) works, the
problem with (2) is that the second installation of the package sort of
overwrites the first installation:

Preparing to replace wmtestpkg1 1.0 (using .../wmtestpkg1_2.0-1.deb)
...
Unpacking replacement wmtestpkg1 ...

That is, they are both now on the filesystem (because I put 1.0 in
/opt/foo1 and 2.0 in /opt/foo2), but dpkg only thinks that one copy is
installed.  Is the gist here that I need to have a complete private
copy of the packaging database (using --root, which also sets
--admindir, rather than just using --instdir) for each instance?  If
so, is there a systematic way that one is supposed to set that up? 
(I've tried just creating empty files and directories as it complains
about things and am still having trouble getting it to work).  But this
will be a somewhat moot point in that if I can't get (1) to work, it's
probably not worth worrying about (2).

Thanks for any help or pointers that anyone might be able to provide.

- Rich



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 



Reply to: