dual lived modules

[Iain Arnell]

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).


-- 
Iain.