Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^2: Module packlists vs. vendors

by mbethke (Hermit)
on Sep 07, 2012 at 21:07 UTC ( [id://992377]=note: print w/replies, xml ) Need Help??


in reply to Re: Module packlists vs. vendors
in thread Module packlists vs. vendors

Marc Lehman states the problem pretty well, if you want to call it perl instead of debperl, you should not break it by removing .packlist files , so this is a debian bug, and they should fix it

If it was just about not removing the files, that'd be easy, I solved that part in 15 minutes on Gentoo. Alas, the files are not even installed by a standard Makefile as produced by ExtUtils:MM when using the vendor_install target, so it doesn't seem only Debian's problem but intended behavior---with ExtUtils::MM being a core module I presume even some sort of official Perl policy. I'd be interested in why this is so and if I can/should circumvent it.

Edit: so far every single vendor I've looked at (OK, just Linuxen: Gentoo, Debian, Ubuntu and CentOS) doesn't package the packlists. If someone could point me to one who does so I can look at their policy and build system, that would be enormously helpful already.

Replies are listed 'Best First'.
Re^3: Module packlists vs. vendors
by Anonymous Monk on Sep 07, 2012 at 21:27 UTC

    If it was just about not removing the files, that'd be easy, I solved that part in 15 minutes on Gentoo. Alas, the files are not even installed by a standard Makefile as produced by ExtUtils:MM when using the vendor_install target, so it doesn't seem only Debian's problem but intended behavior---with ExtUtils::MM being a core module I presume even some sort of official Perl policy. I'd be interested in why this is so and if I can/should circumvent it.

    That is really hard to read/disgest.

    I think you're wrong, I used make install_vendor and I got ../lib/perl5/MSWin32-x86-multi-thread/auto/Foo/.packlist

    Ball is in your court.

      Thanks, that's a neat way to test a minimal setup! I always just traced the build process for some popular CPAN modules. Something weird is going on, I do the exact same thing and get no packlists, both on Gentoo and on Ubuntu:

      Whereas install_site does the right thing:

      $ make install_site Appending installation info to ../lib/perl5/x86_64-linux-thread-multi/ +perllocal.pod $ find .. -name .packlist ../lib/perl5/x86_64-linux-thread-multi/auto/Foo/.packlist

      Which seems logical when I compare the respective sections in the Makefile:

      pure_site_install :: all $(NOECHO) $(MOD_INSTALL) \ read $(SITEARCHEXP)/auto/$(FULLEXT)/.packlist \ write $(DESTINSTALLSITEARCH)/auto/$(FULLEXT)/.packlist + \ $(INST_LIB) $(DESTINSTALLSITELIB) \ $(INST_ARCHLIB) $(DESTINSTALLSITEARCH) \ $(INST_BIN) $(DESTINSTALLSITEBIN) \ $(INST_SCRIPT) $(DESTINSTALLSITESCRIPT) \ $(INST_MAN1DIR) $(DESTINSTALLSITEMAN1DIR) \ $(INST_MAN3DIR) $(DESTINSTALLSITEMAN3DIR) $(NOECHO) $(WARN_IF_OLD_PACKLIST) \ $(PERL_ARCHLIB)/auto/$(FULLEXT) pure_vendor_install :: all $(NOECHO) $(MOD_INSTALL) \ $(INST_LIB) $(DESTINSTALLVENDORLIB) \ $(INST_ARCHLIB) $(DESTINSTALLVENDORARCH) \ $(INST_BIN) $(DESTINSTALLVENDORBIN) \ $(INST_SCRIPT) $(DESTINSTALLVENDORSCRIPT) \ $(INST_MAN1DIR) $(DESTINSTALLVENDORMAN1DIR) \ $(INST_MAN3DIR) $(DESTINSTALLVENDORMAN3DIR)

      How do these parts look in your Makefile? Mine seem to come almost verbatim (modulo some path concatenation rituals) from MM_Unix.pm and as far as I can see, MM_Win32 just inherits these.

        Something weird is going on, I do the exact same thing and get no packlists, both on Gentoo and on Ubuntu:

        Upgrade, See https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/58ec782413fdfb03f30c0de39131e7eb228f8bc9

        How do these parts look in your Makefile?

        Pretty much as you'd expect
        pure_site_install :: all $(NOECHO) $(MOD_INSTALL) \ read $(SITEARCHEXP)\auto\$(FULLEXT)\.packlist \ write $(DESTINSTALLSITEARCH)\auto\$(FULLEXT)\.packlist \ $(INST_LIB) $(DESTINSTALLSITELIB) \ $(INST_ARCHLIB) $(DESTINSTALLSITEARCH) \ $(INST_BIN) $(DESTINSTALLSITEBIN) \ $(INST_SCRIPT) $(DESTINSTALLSITESCRIPT) \ $(INST_MAN1DIR) $(DESTINSTALLSITEMAN1DIR) \ $(INST_MAN3DIR) $(DESTINSTALLSITEMAN3DIR) $(NOECHO) $(WARN_IF_OLD_PACKLIST) \ $(PERL_ARCHLIB)\auto\$(FULLEXT)
        pure_vendor_install :: all $(NOECHO) $(MOD_INSTALL) \ read $(VENDORARCHEXP)\auto\$(FULLEXT)\.packlist \ write $(DESTINSTALLVENDORARCH)\auto\$(FULLEXT)\.packlist \ $(INST_LIB) $(DESTINSTALLVENDORLIB) \ $(INST_ARCHLIB) $(DESTINSTALLVENDORARCH) \ $(INST_BIN) $(DESTINSTALLVENDORBIN) \ $(INST_SCRIPT) $(DESTINSTALLVENDORSCRIPT) \ $(INST_MAN1DIR) $(DESTINSTALLVENDORMAN1DIR) \ $(INST_MAN3DIR) $(DESTINSTALLVENDORMAN3DIR)

Re^3: Module packlists vs. vendors
by Anonymous Monk on Sep 08, 2012 at 01:19 UTC

    Edit: so far every single vendor I've looked at (OK, just Linuxen: Gentoo, Debian, Ubuntu and CentOS) doesn't package the packlists. If someone could point me to one who does so I can look at their policy and build system, that would be enormously helpful already.

    :) ActiveState has long included packlists .... I doubt they have an official documented policy

    search engines and websites (centos.org .... ) are useless for getting this kind of information

    The only policy I've ever seen is http://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://992377]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (3)
As of 2024-03-19 07:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found