On 20 January 2012 20:02, Niko Tyni <nt...@debian.org> wrote: > 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 changes in the handling of .packlist files and perllocal.pod were made be me over ten years ago. The masses have not been storming the gates demanding their return over that decade. As best as I recall, the main rationale for removing .packlist was that in a system which was installed by dpkg, rather than ExtUtils::Install it was redundant information, and required maintainer scripts to manage updates to a common file for little benefit. The location would also likely need to be changed to something under /var rather than /usr/lib if it were being managed by maintainer scripts in such a fashion. In response to Marc's comment in the bug that "Unfortunately, when debian redefined .packlist semantics this way, it _kept_ the name of perl, instead of renaming it to, say debperl." I would say that this is a ridiculous exaggeration. Unless things have changed greatly since last I looked, the contents of .packlist are a convenient way for the admin to know what is installed, and not used for dependency checking by Makefiles (where "eval { require Foo }" is more likely more reliable). If it is essential for ExtUtils::Installed to work, then I'd say that an appropriate fix for Debian would be to patch that module to query dpkg first. Patches are welcome from those who believe that this behaviour is required. --bod -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org