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 [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
