On Tue, Jun 26, 2001 at 11:20:57AM -0400, Ben Collins wrote:
> On Tue, Jun 26, 2001 at 05:13:17PM +0200, Santiago Vila wrote:
> > I wonder why woody's libc6 depends on libdb2 in the first place.
> > What is the exact nature of this dependency?
> I'm looking into a means for ensuring upgrades wiht this setup, but I'm
> open to suggestions (and moving a hacked libdb.so.3 back to libc6 is not
> an option I want to work with).
You might have to...
Hrm. libdb2 isn't essential: yes, so everything that uses it has to depend
or pre-depend on it. But they might also depend or pre-depend on libc6,
and assume that'll imply a functional libdb2.
This can be a problem only when an upgrade goes like:
start with old libc6 from potato
... [anything but libc6 being unpacked]
libdb2 is unpacked
... [anything but libc6 being unpacked; libdb2 can't be configured yet]
a pre/post inst/rm is run that expects libdb2 to work
The latter can only happen in packages that don't (Pre-)Depend:
on libdb2. So we might be able to fix this by getting *EVERYTHING*
that uses libdb2 in woody to have a libdb2 dependency (rather than a
libc6 one, and assuming). If there are any packages that use libdb2 in
a pre/postrm though, that won't work. Ditto for indirect dependencies when
db2 is being used for NIS or something.
It can also be a problem if the upgrade goes like:
start with old libc6 from potato
... [anything but libdb2 unpacked]
libc6 is unpacked
... [anything but libdb2 unpacked]
a pre/post inst/rm is run that expects libdb2 to work
.
Hrm.
So you want to be able to say something like:
libc6 -- as soon as I'm unpacked, make sure libdb2 is >= ...
libdb2 -- as soon as I'm unpacked, make sure libc6 is >= ...
Saying:
libc6 -- before I'm configured, unpack and configure libdb2 (>= ..)
libdb2 -- before I'm unpacked, unpack libc6 (>= ..)
would come close to having the same result, but the closest you can
get to saying that is:
libc6 -- before I'm configured, unpack and configure libdb2 (>= ..)
libdb2 -- before I'm unpacked, unpack and configure libc6 (>= ..)
(libc6 Depends: libdb2; libdb2 Pre-Depends: libc6), but that obviosuly can't
be done.
If you could manage to get a libdb2 that worked with the old libc6, and you
could set up something like:
Package: libdb2
Replaces: libc6 (<= woody-ver)
Pre-Depends: libc6 (>= potato-ver)
Package: libc6
Pre-Depends: libdb2 (>= woody-ver)
you could get things to work reliably to an extent (although you'd break
upgrades from slink and earlier completely). And it'd be a bitch to build,
so that mightn't work.
You could re-merge the packages, and add a
Provides: libdb2
to libc6 for woody, and have packages that link against libdb.so.3 have
a dependency on:
libdb2, libc6 (>= ...)
. Then for sarge, you could have:
Package: libdb2
Depends: libc6 (>= sarge-version)
Package: libc6
libdb2 would be automatically installed because it'd be depended on by other
packages, and no longer provided by libc6. You could still get bad install
behaviour, but it mightn't be too horrible.
This isn't necessarily a solvable problem; Debian's package relationships
don't give you particularly much control over installation ordering. Not
really surprising considering "installation ordering" was historically
done by the user cycling between [I]nstall/[C]onfigure in dselect...
We could also just make the upgrade instructions:
apt-get update
apt-get install libc6 libdb2
apt-get install dpkg apt
apt-get dist-upgrade
I don't see any ideal solutions.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpwBJ0RTaEPI.pgp
Description: PGP signature