Bug#656242: perl: .packlist file missing

[Niko Tyni]

On Tue, Jan 17, 2012 at 07:04:23PM +0100, Marc Lehmann wrote:
 
> Neither perl, perl-base nor perl-moduels contain the .packlist file that is part
> of a standard perl installation.

This is a very longstanding Debian deviation for both the core and the
vendor directories. I can't easily find the full rationale and this was
way before my time, so I'm taking the debian-perl list in the loop.
I hope the discussion stays civil.

The history of the perl Debian packaging that I have available only
ranges back to 2005, and the .packlist files have been removed from the
core packages for all that time.

The Debian Perl policy states that .packlist files should not be
installed for packaged Perl modules (the vendor side). This has been
the case since at least 2001 and is the reason for
 http://patch-tracker.debian.org/patch/series/view/perl/5.14.2-6/debian/no_packlist_perllocal.diff

I don't see any mention of the core side in the policy, but I assume the
core .packlist was dropped for the same reasons. Including a .packlist
file in the perl core packages while omitting them from the vendor
modules in all the libfoo-bar-perl packages doesn't seem very useful or
consistent to me.

There's a little rationale for the vendor part in our lintian tool; from
 http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob;f=checks/files.desc

  Packages built using the perl MakeMaker package will have a file
  named .packlist in them.  Those files are useless, and (in some cases)
  have the additional problem of creating an architecture-specific
  directory name in an architecture-independent package.

I'm personally not quite convinced about the 'useless' part, but there's
obvious overlap with the Debian packaging tools. Perhaps part of
the rationale was to prevent uninstallation of packaged modules behind
dpkg's back?

I'm not sure if the architecture-specific part applies anymore. A quick
test shows that the .packlist file for libfile-slurp-perl (which is
Architecture:all) would go in /usr/lib/perl5/auto/File/Slurp/.packlist,
which isn't really architecture-specific, although it is in /usr/lib.

Other than that, it's not clear to me if .packlist files for vendor
directories are compatible with the Debian binary packaging:

 - is it guaranteed that every CPAN distribution generates a separate
   .packlist file, or are there cases where two distributions would have
   to touch the same .packlist ?

 - what should happen with diversions? For example, both
   libmodule-corelist-perl and perl ship /usr/bin/corelist, and the perl
   one gets diverted away when libmodule-corelist-perl is installed. So
   should the binary end up in two .packlist files?

I see a related thread from 2002:
 http://lists.debian.org/debian-policy/2002/12/msg00009.html
where it was suggested that ExtUtils::Installed should keep working
somehow even if we don't / can't ship .packlist files. This would probably
mean a package post-install / remove script that would register and
unregister the modules, changing the ExtUtils::Installed implementation
but keeping its interface.

This looks to me like a rather big change for little gain, which is
presumably why it never got implemented in the first place. After all,
this is apparently the second time this issue came up in ten years.
-- 
Niko Tyni   ntyni at debian.org