dual lived modules

[Marcela Maslanova]

----- "Iain Arnell" <iarnell at gmail.com> wrote:

> On Mon, Mar 1, 2010 at 9:33 PM, Chris Weyl <cweyl at alumni.drew.edu>
> wrote:
> > I originally opposed the split of the perl package into perl +
> > sub-package for each included dual-life dist.  My thinking then was
> > that "upstream is upstream, and why should we move away from what
> > they've decided?"...  But in the intervening years, my perspective
> has
> > changed.  Having the dists as subpackages at least allows people to
> > build rpms to override them as needed.  (e.g. someone needs a newer
> > "parent", nothing intrinsically stops them from building a
> perl-parent
> > package and updating their system with it.)
> 
> Why not do this ourselves? Keep our core perl as it is with the
> separate sub-packages for modules. As and when new versions of core
> modules are available from the CPAN, build them as separate packages
> too. Initially, the separate packages are newer, so RPM will happily
> update from core-supplied perl-version-0.74 to separately-packaged
> perl-version-0.80 (or whatever). When core perl again supplies a new
> version, there's also no problem to upgrade from separately-packaged
> version to core-supplied version again (not withstanding minor
> complications from MODULE_COMPAT changes, epoch bumps, etc. that we
> have to cope with anyway).
> 
> > * significant numbers of "Modern Perl" packages require newer levels
> > of certain packages than core provides -- and mean it (Test::More
> > comes to mind here), and
> > * upstream itself is pushing to make such "in-place" updates easier
> > (e.g. including the dist  under ext/ rather than under different
> > points in the source dist).
> >
> > With upstream's efforts along these lines, the effort required to
> > generate the patches we need to update dual-lifers is significantly
> > lessened.
> 
> Ugh, but those patches are still painful and require rebuilding (and
> eventually, upgrading) the whole core perl for a single change.
> 
> > Given that our core perl package no longer makes a distinction
> between
> > vendor and core, I don't think that it makes sense to package
> > dual-lifed modules in entirely distinct packages from the core perl
> > package.  Also, as these are "core", we ought to "keep them close"
> to
> > help protect the health of core perl... Splitting them entirely will
> > make this more difficult.
> 
> Given that our core perl package no longer makes a distinction between
> vendor and core, I don't think that it makes sense to package
> dual-lifed modules solely in the core perl package! Let's follow
> upstream and give them a dual-life of our own.
> 
> But I do agree that we should try to protect the health of the core.
> I'd like to extend your ideas on testing for this. Let's package the
> core perl test suite and require separately-packaged dual-life modules
> to run the entire suite in %check.
> 
> > So, my initial thoughts are:
> >
> > * We should allow for more frequent updating of dual-lifed dists
> > through updating as requested/needed.
> 
> +1
> 
> > * We should keep dual-lifed packages as sub-packages of core perl.
> 
> And give them a dual-life of our own with their own independent
> packages too.
> 
> > * We should have a defined workflow in place to help speed the
> > updating of the core perl package.
> >
> > What might help here is a couple guidelines to updating, or at least
> a
> > little statement of workflow, a la Moose[1]...  maybe something like
> > (VERY roughly):
> >
> > 1) User X wants a newer Core::Pkg than currently provided; they file
> a
> > BZ requesting it.
> > 2) Patch is generated -- either by an interested core perl person or
> > User X; attached to the BZ as, e.g., a pointer to a commit patch off
> > Perl git, etc.
> > 3) Two people with a commit bit on core perl CVS OK the change; one
> if
> > User X has a commit bit.
> > 4) Patch applied; pkg built, pushed to testing.
> > 5) Barring bad karma, new core perl is pushed in 3-5 days after
> > landing in -testing.
> 
> or simpler,
> 
> 1) User X wants a new Core::Pkg than currently provided; they file a
> package review request for perl-Core-Pkg (or file a bug requesting
> update existing perl-Core-Pkg rpm to latest version)
> 2a) New package is reviewed, built, pushed to testing
> 2b) Existing package is updated, built, pushed to testing
> 3) Barring bad karma, new module is pushed in 3-5 days after landing
> in -testing.
> 
> Technically, I know that rpm and createrepo have no problem with the
> same perl-Core-Pkg rpm coming from two different sources; I'm not so
> sure that koji, mash, and friends will be as happy (but I have a
> private koji I can test with).
> 
I thought about process which you proposed, because that's how it works
in some other distributions.
I see only one problem. In perl tarball are quite often packaged
older modules. It could happen that in perl-5.10.1 would be perl-A-1.0.
We would update to perl-A-1.2 in separate cvs branch. And then would
be released perl-5.10.2, which would contain perl-A-1.1. That's common
example. I hope there is different way than updating epoch.

> 
> --
> Iain.
> --
> Fedora Extras Perl SIG
> http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
> perl-devel mailing list
> perl-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/perl-devel