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

Re: [RFC] Changing APT to pre-depend on ${shlibs:Depends}



[Jonathan Nieder]
> 	libc6 (>= 2.3.4),
> 	libgcc1 (>= 1:4.1.1),
> 	libstdc++6 (>= 4.5),
> 	zlib1g (>= 1:1.2.2.3)
> 
> It would create a false sense of security regarding use of those
> packages without configuring apt.  If apt is in the middle of an
> upgrade, packages that it pre-depends on can also be in the middle of
> an upgrade and might not be functioning (yes, many higher-level
> package managers provide stronger guarantees).  Luckily, the four
> libraries listed above are meant to be usable during an upgrade
> already.

It's true that, in the general case, there's a window before a package
is configured where it may not work.  But most of these libraries are
in the Essential transitive closure (I don't think libstdc++6 is), so
they will.

If zlib1g (>= 1:1.2.2.3) were replaced by, say, zlib1g (>= 1:1.4.0) or
libz2 (finally losing the 'g' left over from the libc5 -> glibc
transition in Debian hamm), and if you don't want a window where apt is
broken, you have to make sure the new zlib is unpacked before the new
apt is unpacked.  And note that this situation is not under control of
the apt maintainers - just normal SONAME and shlibs lifecycles.  So
yes, I think the Pre-Depends is a good idea.

> in practice, that means a costly "dpkg --triggers-only --pending"
> before upgrading any package that pre-depends on a package with a
> manpage that has been upgraded.

Ugh, yeah, that's suboptimal.  Good thing, as you say, it doesn't
affect those libraries.

> As discussed elsewhere in this thread, anyone relying on apt for
> upgrades would be using apt to upgrade apt, so an alternative to
> consider would be making apt fake the pre-depends internally.

Is it feasible for apt to fake the pre-depends even when it's being
used as a backend to, e.g., aptitude?  I have no idea.  Sounds
complicated, anyway.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


Reply to: