Re: cross-dpkg problems
> There are different cases where a preinst is needed (not every package has
> it) [then list may be far from complete]:
>
> 1) You have a link on the system you want to remove before the package is
> unpacked.
> 2) You have f*cked up completely in a prior package and needs to fix it
> before the package is upgraded.
These are certainly safe to omit when installing on a fresh filesystem.
> 3) If you want to move things around (configuration files), sometimes a
> preinst is necessary.
What do you mean exactly? Can you give an example?
> 4) You need to assure that all "predepends" are fulfilled (packages which
> must be installed before this package may even be unpacked). This is
> necessary for some base packages.
Doesn't dpkg already have an explicit dependency mechanism to do this?
Can you give an example of such a preinst scripts?
> > Can they be bypassed?
>
> I am not sure what you mean. I'mnot sure if there is an option for dpkg to
> not run them. You could write a small script which removes the scripts from
> the package before installation.
No, I want something clean (i.e. an option to not run them).
> In an initial install, Debian (the base floppies)
> just unpack a tar file. We essentially want to do the same.
Yes, that is a fine way to bootstrap the system. We would of course like
to have as little as possible installed in this way, so that dpkg does
everything it reasonably can do.
We need someone (you? Gord?) to come up with a hurd "base" package that has
just enough to get a system that can run dpkg. This needs grub, gnumach,
libc shared objects, and the base hurd servers and shared libs.
> > Is it safe to say that they won't be required if installing onto
> > an empty filesystem where we can say a priori there is nothing conflicting
> > or relevant already installed?
>
> Yes. For this, we should investigate the boot-floppy package, which builds a
> tar file for initial install. This may be easier than reinventing the wheel.
OK, let me know what you come up with.
> > I'm glad to hear it is flexible in these ways. I think what we should
> > recommend for people installing a hurd system from another system is the
> > dpkg command that does this "half-install" without even trying to run the
> > post-install scripts (so people don't get strange errors and core dumps and
> > whatnot).
>
> I'm not confident that there is such an option. Currently, my native hurd
> packages (hurd, gnumach, glibc2) don'ßt have any install scripts, so they
> work without errors.
Well, it can't be hard to add the option to dpkg. It seems worthwhile to
me, especially since dpkg already handles recovering from this state so well.
> This will be the effect. However, using the boot floppies and then running
> dpkg to install the rest of the distribution may be the better approach.
Both are desireable to have. In the long run, it is very desireable to be
able to mostly install the system (linux or hurd, or anything else) from
another system, so you populate disks on one system and then deploy them
with only a little post-boot install finishing to do.
Obviously boot floppies are an essential item too, but there is nontrivial
hairy hurd work involved in getting hurd boot floppies going.
> > We still need to figure out the pre-install script issue. But I think it
> > would be a good feature for dpkg in general to be able to do pure
> > cross-system installs in this way without attempting anything that needs to
> > be run on the target system, so I would like to see a general resolution to
> > this question rather than just getting by for the hurd.
>
> Mmmh. Why would you want to do that? The preinst script is not there for
> fun. They contain important adjustments, that MUST be executed before even
> unpacking the files (during an upgrade). Everything that can be configured
> after unpacking is in the postinst script. So, as soon as the base system
> is ready, one would use the native dpkg to install packages, and not the Linux dpkg.
As I said above, I think it is important and useful functionality in any
installation-management system to be able to cross-install onto a
filesystem from another system, for many administrative uses as well as
just bootstrapping. It is not so important to be able to incrementally
upgrade an installation in this way.
If it can be definitively said that preinst scripts can safely be omitted
when doing a fresh install, and add a dpkg option to do that, then I am
happy. We can simply say "you better not use this option if you're not
doing a fresh install from scratch on an empty filesystem".
Reply to: