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

[Ian Jackson]

Niko Tyni writes ("Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC"):
> 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.

Again, that would be an indirect dependency, although of a different
kind.

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

No, that's not it.  At the time when the bug occurs perl has always
been happily configured.

> > 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.

Earlier I described a repro where xfonts-traditional's postinst fails
the `configure' operation.  The trigger is not a necessary component
of the failure.

> Consider, in a wheezy chroot:
...
> 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.

I think this does't normally actually arise because apt prefers to
configure things in a different order.

> 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.

The loop is nothing to do with it.  The problem is that the dependency
checking has always been a bit loose in these kind of cases, but it
hasn't mattered very much until now.

It would be better if dpkg would avoid configuring (or invoking
trigger processing for) A when A->B->C and C is not configured, but B
is.  That's not a practical solution for jessie.

I still think the Breaks as suggested earlier is the correct solution.

Ian.