dual lived modules

[Chris Weyl]

On Mon, Mar 1, 2010 at 8:32 PM, 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).

This seems to be the way we're going -- it's a reasonable choice, and
I'm OK with that :)

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

Hmmm...  You know.  I like this :)  That would go a long way to
helping keep a level of consistency...  And hopefully help prevent any
screams of "Hey!  RedHat broke Perl AGAIN!" from the great unwashed.

>> * We should have a defined workflow in place to help speed the
>> updating of the core perl package.
[...snip...]
> or simpler,
[...snip...]

Sounds good to me.  I was thinking we'd keep a "Fedora" clone of
upstream Git, and maintain patches off of there, but if we're going
with upstream CPAN for the dual-lifed bits, no need to do that.
(Well, for this at any rate.)

So, to sum up (and also pulling in points made elsewhere in this thread):

* Initial dual-lifed packages will flow from perl core package
* ...until they need an update, at which point standalone packages
will be used to update
* "perl-tests" off core needs to be created, and standalone packages
should run perl core tests in %check after their own tests as a sanity
check
* core perl "owner" will be co-maintainer -- though I'd like to say
all those with commit bits on core perl have them for the subpackages
* Iain's workflow is adopted (yes?  no?  thoughts on Bodhi?)
* dead independent dual-lifed packages will be resurrected; reviews
will be done for the remaining as necessary

I don't think we need any variances from the packaging gods for this,
but it would probably be helpful to incorporate these bits in
PackagingDrafts/Perl as we hash this out.

Sound about right?
                                                 -Chris
-- 
Chris Weyl
Ex astris, scientia