Re: cross-dpkg problems
On Fri, Nov 06, 1998 at 04:06:12PM -0500, Roland McGrath wrote:
> > > Basically, dpkg is not suitable for cross-platform installations,
> > > because the --instroot option uses the chroot call, which breaks all
> > > the installation scripts (i.e. they see only Hurd binaries, rather
> > > than the current system's). There's no easy solution to this problem,
> > > aside from running dpkg under the Hurd.
> >
> > Yes. Dpkg was never intended to cope with this.
>
> This is a real shame. Is there any likelihood of this getting improved?
> It is a very useful and important feature of an installation system to be
> able to wholly install a new system on a fresh filesystem without running
> the new system.
This is a feature that is supported, actually. The problem is that GNU
binaries don't run under Linux.
> Is the problem that there are "post-install" scripts and the like that are
> essentially shell scripts that must be run native?
Yes. It is not even guaranteed that the postinst executables are shell
scripts. We have no policy about this, although most are shell scripts, few
are perl or bash scripts, and at least one is an executable (libreadline).
But the postinst scripts are not a big deal. If the postinst fails, the
package is "half-installed" and only needs to be "configured". The real
problem are .preinst scripts, which are run before the package is unpacked.
The installation process is a bit difficult. There are four scripts,
{pre,post}{rm,inst} which are run before and after removal or installation
of packages. The scripts are run with an argument, which defines if it is an
upgrade, a new install, a removal or purge (removes configuration too) etc.
However, the problem we face here is that the scripts must be run on the
native machine, or must at least work in a chroot'ed environment. W7o binary
compatibility, we have lost (although I use dpkg --root=/gnu, and do the
configuration step manually).
> Can the installation of
> files, which can be done "cleanly" to another filesystem, and the running
> of scripts, be separated? What I have in mind is doing the "install
> everything on the filesystem" in a first phase that can be done from
> another system writing onto the filesystem, leaving the system in a state
> where you can boot up and do "dpkg --finish-install" or something or other
> to have it it do the final phases that require the native system.
If the postinst fails, the package is left in a "half-installed" state.
Running "dpkg --pending --configure" after reboot will do what you want.
There are other options, for a fine adjustment of dpkg's behaviour.
You can also only unpack the files, which is sometimes dangerous (in
a running system, at least :)
Thank you,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: