On Tue, Apr 26, 2011 at 2:40 PM, Robin Lee <robinlee.sysu@xxxxxxxxx> wrote:
> On Tue, Apr 26, 2011 at 5:51 PM, Petr Pisar <ppisar@xxxxxxxxxx> wrote:
>> On Fri, Apr 22, 2011 at 11:00:46PM +0800, Robin Lee wrote:
>>>
>>> Some dual-life modules, like PathTools and CGI, are placed within
>>> vendor path in Fedora 15. This situation is not expected by some
>>> applications, for example, "cpanm -L" command will definitely fail if
>>> an installing package needs such dual-life modules.
>>>
>> This is problem of that applications. They should not expect exact location.
Not really. I think it's legitimate to assume that core modules are
available in archlib/privlib. In a "normal" perl installation, that's
always true. When upgrading a dual-lifed module from the CPAN, you
don't remove or overwrite the files from core, you just install the
new version in sitearch/sitelib.
>> Formally, some packagers wanted to install all Fedora modules into core.
That would also break "cpanm -L" by making it think that *all*
installed modules were part of core and then failing to pick up any
non-core dependencies. This is a good reason to keep the proper
core/vendor split with all of our modules going to vendor.
>> But
>> there are some RPM-related problems (files in debuginfo subpackages would
>> conflict because debug data are delivered by one subpackage for all
>> subpackages together) and some packagers were against it.
> I agree that this is the true obstacle.
Yep, this prevents a simple workaround of installing arch-specific
dual-lifed modules from the cpan in core directories. I think for
noarch packages, we're okay.
There is a possible solution, though - basically replicating what
"normal" perl does. Rather than uninstalling the core module when
replaced with cpan version, arrange things so that both core version
and cpan version are installed simultaneously (or core version only if
that's newer than cpan version).
In perl.spec, we can create additional perlcore-Dist-Name sub-packages, e.g:
%package Scalar-List-Utils
Summary: A selection of general-utility scalar and list subroutines
Group: Development/Libraries
License: GPL+ or Artistic
%global Scalar_List_Utils_epoch 0
%global Scalar_List_Utils_version 1.22
Epoch: %{Scalar_List_Utils_epoch}
Version: %{Scalar_List_Utils_version}
Requires: perl = %{perl_epoch}:%{perl_version}-%{release}
Requires: perlcore-Scalar-List-Utils = %{epoch}:%{version}-%{release}
Obsoletes: perlcpan-Scalar-List-Utils <= %{epoch}:%{version}-%{release}
%description Scalar-List-Utils
Scalar::Util and List::Util contain a selection of subroutines that people have
expressed would be nice to have in the perl core, but the usage would not
really be high enough to warrant the use of a keyword, and the size so small
such that being individual extensions would be wasteful.
%package -n perlcore-Scalar-List-Utils
Summary: Scalar-List-Utils from Perl core
Group: Development/Libraries
License: GPL+ or Artistic
Epoch: %{Scalar_List_Utils_epoch}
Version: %{Scalar_List_Utils_version}
Requires: perl = %{perl_epoch}:%{perl_version}-%{release}
Requires: perl-Scalar-List-Utils >= %{epoch}:%{version}-%{release}
%description -n perlcore-Scalar-List-Utils
Scalar-List-Utils implementation from Perl core.
%files Scalar-List-Utils
%{_mandir}/man3/List::Util*
%{_mandir}/man3/Scalar::Util*
%files -n perlcore-Scalar-List-Utils
%defattr(-,root,root,-)
%{archlib}/List/
%{archlib}/List/Util/
%{archlib}/List/Util.pm
%{archlib}/Scalar/
%{archlib}/Scalar/Util/
%{archlib}/Scalar/Util.pm
%{archlib}/auto/List/
%{archlib}/auto/List/Util/
And in each of the dual-lifed perl-Dist-Name packages, create
perlcpan-Dist-Name sub-packages, e.g:
%package -n perlcpan-Scalar-List-Utils
Summary: Scalar-List-Utils from the CPAN
Group: Development/Libraries
License: GPL+ or Artistic
Requires: perl-Scalar-List-Utils = %{epoch}:%{version}-%{release}
%description -n perlcpan-Scalar-List-Utils
Scalar-List-Utils implementation from the CPAN.
%files
%defattr(-,root,root,-)
%doc Changes README
%{_mandir}/man3/*
%files -n perlcpan-Scalar-List-Utils
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/List*
%{perl_vendorarch}/Scalar*
So that we end up with:
perl-Scalar-List-Utils-1.22-158.fc15.x86_64.rpm
perlcore-Scalar-List-Utils-1.22-158.fc15.x86_64.rpm
and
perl-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
perlcpan-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
Where perlcpan-Scalar-List-Utils-1.23 is the "best" provider of
perl(Scalar::Util) and the dependencies ensure that perlcpan package
pulls in perl-Scalar-List-Utils-1.23, which in turn pulls in
perlcore-Scalar-List-Utils-1.22.
If at some point in the future, perl 5.14.x comes with a newer
Scalar-List-Utils, we end up with
perl-Scalar-List-Utils-1.24-199.fc16.x86_64.rpm
perlcore-Scalar-List-Utils-1.24-199.fc16.x86_64.rpm
and
perl-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
perlcpan-Scalar-List-Utils-1.23-2.fc15.x86_64.rpm
Where perlcore-Scalar-List-Utils-1.24 is now the "best" provider of
perl(Scalar::Util) which pulls in perl-Scalar-List-Utils-1.24 and
obsoletes perlcpan-Scalar-List-Utils-1.23.
Of course, it's a bit of effort to implement, and potentially doubles
the installed size of any dual-lifed modules, but fairly easy to
revert if and when debuginfo plays nice with sub-packages. (And may
help to avoid another "Redhat perl != perl" debate).
--
Iain.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
