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

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Henrique de Moraes Holschuh wrote:

> Are there any real drawbacks?  Would it cause worse behaviour or problems
> for the error-rewind paths if either the pre-deps, or apt fails to install,
> as compared with the current status-quo?

Based on the list

	libc6 (>= 2.3.4),
	libgcc1 (>= 1:4.1.1),
	libstdc++6 (>= 4.5),
	zlib1g (>= 1:1.2.2.3)

I think this should be okay if it is wanted.  (Please do let
debian-devel know when considering changes that would cause that list
to expand.)

But yes, there are some drawbacks.

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.  This seems like a good reason to vet future additions to the
Pre-Depends list.  (See Bug#593177 for more on that subject.)

Pre-Depends currently interact poorly with triggers (arguably this is
a bug in policy, Bug#582109).  dpkg does not consider a pre-depends
satisfied unless the package depended on is not waiting for triggers;
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.  Luckily, none of the four library
packages listed above triggers man-db.

A separate question is "are there benefits?".  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.  Even so, I can see how actual pre-depends
might be simpler and given the modest list of packages to pre-depend
on, it sounds okay to me.

Hope that helps,
Jonathan