Re: cross-dpkg problems
On Fri, Nov 06, 1998 at 06:09:31PM -0500, Roland McGrath wrote:
> > 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?
Autoconf:
#! /bin/sh -e
test -e /etc/autoconf/acconfig.h && exit 0
test -f /usr/lib/autoconf/acconfig.h || exit 0
mkdir -p /etc/autoconf
mv /usr/lib/autoconf/acconfig.h /etc/autoconf/acconfig.h
Comment from fvwm2:
# This script is required because in version fvwm2_2.0.43-BETA-0, the system
# fvwmrc was renamed. The purpose is to delete the old conffile if it has
# not been changed by the system administrator.
> > 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?
Yes, but if you do mass upgrades, there are some cases where this does not
work reliable (?). Sorting a set of packages and unpack and configure them
in the right order is no trivial task. To save time, dpkg first unpacks as
much as possible, and then configures all packages. This is similar to what
you want, but sometimes you have to cycle through this multiple times.
There is a new tool, apt, a front end to dpkg, which does a much better job
sorting the packages.
> Can you give an example of such a preinst scripts?
bash:
#!/bin/sh
set -e
dpkg --assert-support-predepends
bash needed this script, because bash predepends on libreadline. Because, if
bash is unpacked before libreadline is in place, bash could break in case of
an incompatibility between library versions. This is also only important fro
upgrades.
> > > 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).
Should be trivial to implement, but I couldn't tell you if this would work
in all cases w/o looking very hard at all scripts and the mechanism dpkg
works (the whole process is very complicated).
> > 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.
Yes. The base system is 7 MB compressed.
> 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.
I will investigate boot floppies as soon as we have a minimal working
system. (We sort of have already, but there are some edges).
> > 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.
Okay, as dpkg does this already when mass upgrading, it should be no problem
with the postinst. If you think the preinst are unimportant in an initial
install (an interesting idea, btw, which has to be investigated), this could
work.
> > 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.
I'm not sure. We are currently working on other mechanism, automatic
configuration for network install etc. Well, Debian is all for diversity. If
something works reliable, it is heartly accepted.
> Obviously boot floppies are an essential item too, but there is nontrivial
> hairy hurd work involved in getting hurd boot floppies going.
:) Do not think it is different with Linux. Enrique (our boot floppy
master) is doing an incredible job. Worst problem under Linux is conflicting
hardware.
> 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.
The latter is probably a non-issue (although the dpkg sources are a bit
messy and quite complicated), the first needs further investigation by
someone who knows the install process very well. Maybe we should raise this
issue on debian-devel or debian-dpkg one of these days.
If you want to look at preinst scripts, I can sent you a compressed tar file
of the collection I have.
> We can simply say "you better not use this option if you're not
> doing a fresh install from scratch on an empty filesystem".
Yes.
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: