Re: Bug#774844: xfonts-traditional: fails to upgrade from 'wheezy': Can't locate File/Find.pm in @INC
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.
Reply to: