Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC

[Niko Tyni <ntyni@debian.org>]

On Mon, Jan 19, 2015 at 05:09:31PM +0000, Ian Jackson wrote:
> Niko Tyni writes ("Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC"):
> > My point was that this is potentially a much wider issue, not
> > limited to perl.
> 
> I should reply to this.  You are right that it is, potentially, a
> wider issue.
> 
> But it mostly occurs when a dependency is indirected through an
> intermediate package.  That is, A uses some feature in C, but the
> dependency is declared on B which depends on C.

I don't think this indirection is the key here. The same issue could just
as well have happened if the xfonts-traditional postinst functionality
needed for example Time::Piece (which is in the perl package.)

In that case the dependency on perl would be direct, but the script would
fail in exactly the same way when a newer perl-modules is unpacked -
because Time::Piece needs Time::Local from perl-modules, and that wouldn't
be on the search path anymore.

I suspect it has more to do with the circular dependency between
perl and perl-modules.

> We see the bug with xfonts-traditional because both (a) it has a
> trigger and (b) luck means that the usual ordering exposes the bug.
> But as I explained earlier, this situation is not limited to packages
> with triggers.  It can be repro'd with xfonts-traditional without
> triggers being involved.

I don't quite buy this argument about triggers not being involved.

Consider, in a wheezy chroot:

  # apt-get install file
  # dpkg --unpack libmagic1_5.22+15-1_amd64.deb # from sid
  # file /usr/bin/perl
  file: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib/x86_64-linux-gnu/libmagic.so.1)
  file: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib/x86_64-linux-gnu/libmagic.so.1)
  # dpkg -l file
  [...]
  ii  file                   5.11-2+deb7u6    amd64            Determines file type using "magic" numbers

In this situation dpkg would agree to install and configure a package
that Depends on 'file' and uses that command in 'postinst configure',
but the configure step would fail.  Does that imply that the new libmagic1
package should Break older versions of file? I don't think that makes sense.

So why does it after s/file/perl/ and s/libmagic1/perl-modules/ ?

It looks to me like this new Breaks: requirement arises from the dpkg
triggers implementation and possibly concerns only circular dependencies.
The loop breaking logic that looks for postinst scripts (policy 7.2)
seems related. Clearly we don't have this for triggers, only for the
configure step.
-- 
Niko Tyni   ntyni@debian.org