Bug#656242: perl: .packlist file missing

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 file is needed when programs want to know which files belong to the
perl core, and which don't.

Can you give an example of a program which uses it like this?

To reproduce, use:

perl -e 'do ".packlist"'

on a working perl, this should cause lots of compiletime errors (Bareword
missing...) because the .packlist file is not valid perl.

This isn't a great test case.

On debian, because it is missing, you get no output.

Right. As far as I can tell, the packlist system is intended to tell
you about manually/installed perl modules, which the Debian packaged
ones obviously aren't.

The problem with trying to change this is that without any sort of
specification or general information about this file format (which I
have failed to find) or a use case, it's pretty difficult to know exactly
what should happen.

I note that /usr/lib/perl/.../.packlist is explicitly removed in the
debian/rules file at the moment (as being cruft), and the documentation
has been updated accordingly:

http://patch-tracker.debian.org/pat...local.diff
http://patch-tracker.debian.org/pat...h_doc.diff

Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

On Thu, Jan 19, 2012 at 08:34:57PM +0000, Dominic Hargreaves wrote:

> This file is needed when programs want to know which files belong to the
> perl core, and which don't.

Can you give an example of a program which uses it like this?

perl-libextractor and mkbundle from staticperl. Or ExtUtils::Installed,
or cpanplus, or just about any packager for perl programs whiche xamines
these files to see which fiels are part of a distribution.

I also don't quite see the point of your question. Does it really matter
which programs need those files? You should have a reason why perl removes
those files in the first place, when correct perl installations have them.

> perl -e 'do ".packlist"'
>
> on a working perl, this should cause lots of compiletime errors (Bareword
> missing...) because the .packlist file is not valid perl.

This isn't a great test case.

I can't imagine any better testcase - it easily identifies broken and
correct perl installs and is very small. Why do you claim it isn't a great
testcase?

Any of the above programs I mentioned would need far more complciated tets
programs and interpretations.

It would be far more constructive if you explained what your problem was.
Your above comment is neither constructive, nor helpful, nor useful.

Right. As far as I can tell, the packlist system is intended to tell
you about manually/installed perl modules, which the Debian packaged
ones obviously aren't.

Maybe debian should have asked somebody before removing random files out
of lack of understanding: .packlist files list which files belong to a
perl distribution, it has nothing to do with modules, or who installs
them. If it had, why do you think perl itself doesn't diferentiate between
them (even providing .packlist files for the perl core distribution and
every other installed distribution).

Perl itself provides a .packlist file and every distribution provides one
too, thats the only way to differentiate between them and see which files
belong together when being redistributed for example. Or removed.

There shouldn't be any difference between what you call a manual install
(via e.g. cpan, which is highly automated) or dpkg (which is far more
manual work). Or who provides them (because ultimately, debian just
packages existing software)

The problem with trying to change this is that without any sort of
specification or general information about this file format (which I

man ExtUtils::Packlist - just grepping for packlist will find that.

have failed to find) or a use case, it's pretty difficult to know exactly
what should happen.

Well, debian should simply package programs, and not randomly leave out
files that are part of a package without a good reason. If a program or a
perl distribution installs a file then debian's job is to provide them,
it's that simple.

As it is, debian breaks the perl library by leaving out files. I don't think
it matters whether you can find a specification or not - did you look up a
specification for perl scripts, dynamic libraries or linux elf executables?
If not, why shouldn't they be left out? That kind of argument doesn't make
any sense.

It also reminds me of the openssl desaster and debians attitude to it.
Really, if a debian maintainer doesn't understand something, then he/she
must "fix" it, chances are extreemly high soemthing breaks. The last thing
debian needs is packages that have been broken because nobody at debian
understands what they does, but still feel entitled to change things for
no known reason. That is illogical.

When in doubt, it should be packaged. You need a _reason_ to leave out
files. If you need a specification to package files, then you are doing it
wrong.

I note that /usr/lib/perl/.../.packlist is explicitly removed in the
debian/rules file at the moment (as being cruft), and the documentation
has been updated accordingly:

I can't find any documentation about this, certainly not in these
diffs. The closest I can find is the "locally", but thats of course not
helpful, because everything I install on my box is "locally installed".

If that is supposed to mean "nothing manually installed via dpkg or
apt-get, as opposed to e.g. via CPAN", then debian should have a very good
reason to redefine this mechanism in perl.

Also, pointing at existing bugs in debian and saying "it's documented" is
also not helpful. If debian lacks perl library files then they should be
added, or a good reason for them to not exist should exist. Pointing out
that debian leaves out the files just means debian has a bug, whether it
is fuzzily documented or not.

Likewise if debian wants to fundamentally change how ExtUtils::Installed
works or how .packlists work (and that is what the doc patch tries to
insinuate), then there should be a good reason. There is a lot of code
that looks for dependencies in various ways, and if debian really breaks
this, then debian needs a really good reason to do so.

Or in other words, if debian wanst to provide an incomaptible
ExtUtils::Installed file, then it should do so under a different name, and
leave the original module in working order.

If the change of behaviour is supposed to be useful, then a patch should
be submitted upstream with an explanation of why .packlists should be
removed and/or why the behaviour of ExtUtils::Installed is to be changed.

Of course, I don't think that debian should willfully break perl this way, it
should be compatible to how perl is managed everywhere else.

Unless there is an actual reason, which doesn't seem to exist.

The choice of a Deliantra, the free code+content MORPG
-==-- _ generation
==(_)__ __ ____ __ Marc Lehmann
-==/_/_//_/\_,_/ /_/\_\



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

On Thu, Jan 19, 2012 at 08:34:57PM +0000, Dominic Hargreaves wrote:

> This file is needed when programs want to know which files belong to the
> perl core, and which don't.

Can you give an example of a program which uses it like this?

perl-libextractor and mkbundle from staticperl. Or ExtUtils::Installed,
or cpanplus, or just about any packager for perl programs whiche xamines
these files to see which fiels are part of a distribution.

I also don't quite see the point of your question. Does it really matter
which programs need those files? You should have a reason why perl removes
those files in the first place, when correct perl installations have them.

> perl -e 'do ".packlist"'
>
> on a working perl, this should cause lots of compiletime errors (Bareword
> missing...) because the .packlist file is not valid perl.

This isn't a great test case.

I can't imagine any better testcase - it easily identifies broken and
correct perl installs and is very small. Why do you claim it isn't a great
testcase?

Any of the above programs I mentioned would need far more complciated tets
programs and interpretations.

It would be far more constructive if you explained what your problem was.
Your above comment is neither constructive, nor helpful, nor useful.

Right. As far as I can tell, the packlist system is intended to tell
you about manually/installed perl modules, which the Debian packaged
ones obviously aren't.

Maybe debian should have asked somebody before removing random files out
of lack of understanding: .packlist files list which files belong to a
perl distribution, it has nothing to do with modules, or who installs
them. If it had, why do you think perl itself doesn't diferentiate between
them (even providing .packlist files for the perl core distribution and
every other installed distribution).

Perl itself provides a .packlist file and every distribution provides one
too, thats the only way to differentiate between them and see which files
belong together when being redistributed for example. Or removed.

There shouldn't be any difference between what you call a manual install
(via e.g. cpan, which is highly automated) or dpkg (which is far more
manual work). Or who provides them (because ultimately, debian just
packages existing software)

The problem with trying to change this is that without any sort of
specification or general information about this file format (which I

man ExtUtils::Packlist - just grepping for packlist will find that.

have failed to find) or a use case, it's pretty difficult to know exactly
what should happen.

Well, debian should simply package programs, and not randomly leave out
files that are part of a package without a good reason. If a program or a
perl distribution installs a file then debian's job is to provide them,
it's that simple.

As it is, debian breaks the perl library by leaving out files. I don't think
it matters whether you can find a specification or not - did you look up a
specification for perl scripts, dynamic libraries or linux elf executables?
If not, why shouldn't they be left out? That kind of argument doesn't make
any sense.

It also reminds me of the openssl desaster and debians attitude to it.
Really, if a debian maintainer doesn't understand something, then he/she
must "fix" it, chances are extreemly high soemthing breaks. The last thing
debian needs is packages that have been broken because nobody at debian
understands what they does, but still feel entitled to change things for
no known reason. That is illogical.

When in doubt, it should be packaged. You need a _reason_ to leave out
files. If you need a specification to package files, then you are doing it
wrong.

I note that /usr/lib/perl/.../.packlist is explicitly removed in the
debian/rules file at the moment (as being cruft), and the documentation
has been updated accordingly:

I can't find any documentation about this, certainly not in these
diffs. The closest I can find is the "locally", but thats of course not
helpful, because everything I install on my box is "locally installed".

If that is supposed to mean "nothing manually installed via dpkg or
apt-get, as opposed to e.g. via CPAN", then debian should have a very good
reason to redefine this mechanism in perl.

Also, pointing at existing bugs in debian and saying "it's documented" is
also not helpful. If debian lacks perl library files then they should be
added, or a good reason for them to not exist should exist. Pointing out
that debian leaves out the files just means debian has a bug, whether it
is fuzzily documented or not.

Likewise if debian wants to fundamentally change how ExtUtils::Installed
works or how .packlists work (and that is what the doc patch tries to
insinuate), then there should be a good reason. There is a lot of code
that looks for dependencies in various ways, and if debian really breaks
this, then debian needs a really good reason to do so.

Or in other words, if debian wanst to provide an incomaptible
ExtUtils::Installed file, then it should do so under a different name, and
leave the original module in working order.

If the change of behaviour is supposed to be useful, then a patch should
be submitted upstream with an explanation of why .packlists should be
removed and/or why the behaviour of ExtUtils::Installed is to be changed.

Of course, I don't think that debian should willfully break perl this way, it
should be compatible to how perl is managed everywhere else.

Unless there is an actual reason, which doesn't seem to exist.

The choice of a Deliantra, the free code+content MORPG
-==-- _ generation
==(_)__ __ ____ __ Marc Lehmann
-==/_/_//_/\_,_/ /_/\_\



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

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/pat...local.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...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-poli...00009.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



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

On Fri, Jan 20, 2012 at 11:02:55AM +0200, Niko Tyni 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.

I really don't see why this needs this discussion: I reported an obvious
bug (missing file(s)) in debians perl package.

It turned out that this breakage was done deliberately by the
maintainer(s) of the perl package, because they thought they know better
what perl should do then upstream and changed semantics.

Even documentation was changed in an attempt to make the new, incompatible
syntax, somehow less broken.

Unfortunately, when debian redefined .packlist semantics this way, it
_kept_ the name of perl, instead of renaming it to, say debperl.

The result is a debian perl, which is incompatible to standard perl, but
confusingly uses the same name. Standard perl has not been packaged.

So the situation is quite simple: either debian fixes its perl by adding
the missing files, or it creates a real perl package and packages both or
it simply stays broken.

This is not my decision, but a question of how much breakage debian wants
to introduce into standard programs.

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.

Well, the underlying problem here is action without understanding. The
fact that perl has a .packlist for it's core library shows that .packlists
are not some module management mechanism.

obvious overlap with the Debian packaging tools. Perhaps part of
the rationale was to prevent uninstallation of packaged modules behind
dpkg's back?

And whats your evidence for this conjecture?

Even if it were true (it's not, because using this to remove .packlists is
not a common way to remove packages. In fact, if you want to uninstall a
module, you have to do this manually, and .packlists can be of help).

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

Then removal is obviously wrong. Again, debian must have a reason to
remove these files, not a reason to add them.

- 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 ?

No, of course not - a distribution that has the same name needs to use the
same location for the .packlist file.

- 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?

You can break your system with diversions in any number of ways. What
happens when you divert /sbin/init? Well, you better provide a compatible
executable there.

Likewise, if you divert, say, a .pm file, then obviously something has to
fill the gap. If the perl .packlist says there is a strict.pm, and it's
diverted, too bad, you better provide a replacement for it or very few
perl programs will run.

Lack of capability in dpkg should not result in removal of files,
obviously. If something is imperfect under very special circumstances
then it's still better than breaking it for everybody.

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.

Well, it doesn't work like the original module does, and somebody felt
compelled to patch it's documentation so debian can claim "works as
documented".

Nevertheless, this makes debians perl an incompatible fork of perl,
because library semantics have changed. Documenting that doesn't make it
go away.

This is the last mail I will write about this - I really don't think debian
should require lengthy discussion to fix this bug, but intead, it should be
fixed unless there are known reasons not to.

Guessing and claiming lack of specification is approaching the problem
form the wrong side: you need a rationale for removing stuff, not for
keeping it, when managing software.

Good luck,

The choice of a Deliantra, the free code+content MORPG
-==-- _ generation
==(_)__ __ ____ __ Marc Lehmann
-==/_/_//_/\_,_/ /_/\_\



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact