Bug#656242: perl: .packlist file missing

[Marc Lehmann]

On Thu, Jan 19, 2012 at 08:34:57PM +0000, Dominic Hargreaves <dom at earth.li> 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
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\