On Fri, Oct 05, 2018 at 02:43:30PM -0000, renodr--- via blfs-book wrote: > Author: renodr > Date: Fri Oct 5 07:43:30 2018 > New Revision: 20579 > > Log: > Update to git-2.19.0 > For some reason, the Git perl module is installed in /usr/share/perl5/Git. I > don't think > it is part of our %INC search path, but I'm not 100% certain. Ken, please > test this, > it's way over my head. >
And mine, but I think I'm getting a little understanding (which is always a dangerous thing). Cast your mind back to the dim past (BLFS-8.0). With git-2.11.1 git installed modules into /usr/lib/perl5/site_perl/x.yy.z : Error.pm, Git.pm and Git/*.pm (the latter were I18N.pm, IndexInfo.pm, SVN.pm and files for SVN). Before 8.1, Pierre noticed Error.pm and made that into a recommended dependency. Git (2.14.1) only installed Git.pm and Git/* in site_perl. That continued through 2.16 versions. With git-2.17.0 things changed, Git was no-longer installed into site_perl and the files in /usr/share/perl5 have existed since then. There are: FromCPAN/ Git/ Git.pm In FromCPAN/ are the sources for Error.pm and Mail/Address.pm In Git/ are: LoadCPAN/ SVN/ and modules I18N.pm, IndexInfo.pm, LoadCPAN.pm, Packet.pm, SVN.pm. Git.pm is so that perl scripts can interface to Git. And yes, you are correct that Git.pm is not directly available to us: ken@origin ~ $perl -e 'use Git;' Can't locate Git.pm in @INC (you may need to install the Git module) (@INC contains: /usr/lib/perl5/site_perl/5.28.0/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.28.0 /usr/lib/perl5/vendor_perl/5.28.0/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.28.0 /usr/lib/perl5/5.28.0/x86_64-linux-thread-multi /usr/lib/perl5/5.28.0) at -e line 1. BEGIN failed--compilation aborted at -e line 1. The LoadCPAN.pm module (actually Git::LoadCPAN) is similarly not directly available. Using perldoc on it gives: |NAME | Git::LoadCPAN - Wrapper for loading modules from the CPAN (OS) or Git's | own copy | |DESCRIPTION | The Perl code in Git depends on some modules from the CPAN, but we don't | want to make those a hard requirement for anyone building from source. | | Therefore the Git::LoadCPAN namespace shipped with Git contains wrapper | modules like "Git::LoadCPAN::Module::Name" that will first attempt to | load "Module::Name" from the OS, and if that doesn't work will fall back | on "FromCPAN::Module::Name" shipped with Git itself. | | Usually distributors will not ship with Git's Git::FromCPAN tree at all | via the "NO_PERL_CPAN_FALLBACKS" option, preferring to use their own | packaging of CPAN modules instead. | | This module is only intended to be used for code shipping in the | "git.git" repository. Use it for anything else at your peril! But note that the text implies it should work. So, I guessed that we should probably add Mail::Address as a recommended dependency, and build with that option. Then I looked for examples of using that option and discovered that Mail:Address is apparently used by git send-mail: https://bugzilla.redhat.com/show_bug.cgi?id=1561086 |$ git send-email -h |BUG: The 'Mail::Address' module is not here, but NO_PERL_CPAN_FALLBACKS | was set! So I tried that command, and got a screenful of options. Gogoling some more - From the Release Notes for 2.17.0 : * As a convenience, we install copies of Perl modules we require which are not part of the core Perl distribution (e.g. Error and Mail::Address). Users and packagers whose operating system provides these modules can set NO_PERL_CPAN_FALLBACKS to avoid installing the bundled modules. So, after googling for git send-email, and creating a patch from my own build scripts, I successfully sent it to myself. What this means is that the versions in /usr/share/perl5 ARE working when invoked from git. So, about an hour after I started writing at this, I now think we have two choices: 1. Remove Error.pm, allow git to use the shipped copy (as well as the shipped copy of Mail::Address), and document that /usr/share/perl5 is an installed directory containing perl modules usable (only) by git commands. 2. "Be a distro" i.e. aim to provide all the necessary modules, so that any user who does NOT install them, but then invokes a command which requires them, will get a message from LoadCPAN.pm (if that is present) - |BUG: The '%s' module is not here, but NO_PERL_CPAN_FALLBACKS was set! | |Git needs this Perl module from the CPAN, and will by default ship |with a copy of it. This Git was built with NO_PERL_CPAN_FALLBACKS, |meaning that whoever built it promised to provide this module. | |You're seeing this error because they broke that promise, and we can't |load our fallback version, since we were asked not to install it. | |If you're seeing this error and didn't package Git yourself the |package you're using is broken, or your system is broken. This error |won't appear if Git is built without NO_PERL_CPAN_FALLBACKS (instead |we'll use our fallback version of the module). I assume "all the necessary modules" means Error, Git, Mail::Address. Looking at fedora, they put 'NO_PERL_CPAN_FALLBACKS = 1' in config.mak, and they also remove LoadCPAN. I have not looked at how debian do this. If requiring the modules, we should ideally NOT install /usr/share/perl5. Summary: When we added Error.pm, it looked simple. But now I wonder if, for our use-case, it would be better to keep the (adequate) shipped versions : Error 0.17025 - current is 0.17026 which merely converted the release to use Dist::Zilla for packaging. Git - by definition this is current, i.e. 0.42. Mail::Address 2.20 - is current. Opinions ? Note: Deciding on how to address this is much less important than upgrading to 2.19.1 (or 2.18.1, 2.17.2, 2.16.5, 2.15.3, 2.14.5 for anyone using an older series) https://lore.kernel.org/lkml/[email protected]/ ĸen -- Well grubbed , old mole! -- http://lists.linuxfromscratch.org/listinfo/blfs-book FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
