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

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



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.

This is (perhaps surprisingly) not particularly common.  But in the
case of perl it's nearly universal, because of the policy
recommendation to depend on the metapackage `perl' rather than
perl-base or perl-modules.

This is why I think the right fix is to add the Breaks to the perl
packages.

Andreas wrote:
> I think this list can be reduced to "Uses 'perl stuff that requires
> strict dependencies' in their maintainer scripts."

I don't think `requires strict dependencies' is a very useful concept
here.  That xfonts-traditional uses (in a maintainer script) a perl
module which has always been implied by `perl' can hardly be unusual.
I don't think it makes sense to regard that as a particularly
`strict'.

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 think searching the archive for other packages which are exposed to
similar issues with perl would be difficult.  At the very least we'd
have to search for every package which relies in its postinst on
modules which are moving between perl packages.

Thanks,
Ian.


Reply to: