On 2018-10-05 16:21, Ken Moffat via blfs-book wrote:
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]/
Thanks for the heads up on that, I have a working exploit for it.
I'm going to update to 2.18.1 right now. Ken, are you of the opinion
that an email to the lists is necessary?
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
