Re: Bug#656242: perl: .packlist file missing
On Fri, Jan 20, 2012 at 11:02:55AM +0200, Niko Tyni <ntyni@debian.org> 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
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
Reply to: