About placement of dual-life modules
Petr Sabata
psabata at redhat.com
Fri Apr 29 11:08:06 UTC 2011
On Fri, Apr 29, 2011 at 10:45:40AM +0200, Iain Arnell wrote:
> On Tue, Apr 26, 2011 at 2:40 PM, Robin Lee <robinlee.sysu at gmail.com> wrote:
> > On Tue, Apr 26, 2011 at 5:51 PM, Petr Pisar <ppisar at redhat.com> 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.
I suppose somebody brought this up in the past but why don't we just package
modules currently bundled with perl and remove them from the perl package,
maintaining them individually?
They would have their own debug info and all (both those currently bundled and
all others) could be installed to the same path without any issues. Minor
updates wouldn't require updating the perl package, would be smaller and more
people could work on them easily, [insert more obvious advantages here].
I know that's not in line with upstream "packaging" but we differ anyway.
Would there be any real drawbacks?
--
Petr 'contyk' Sabata, Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/perl-devel/attachments/20110429/59f4658b/attachment.sig>
More information about the perl-devel
mailing list