dual lived modules

[Chris Weyl]

On Mon, Mar 1, 2010 at 6:30 AM, Marcela Maslanova <mmaslano at redhat.com> wrote:
> Hello,
> I'd like to ask on your opinion on dual lived modules in
> our distro. I knew that Mandriva has the main perl package
> and also provide rpms of sub-packages, which are easier to
> update. They are using patch that allows them override the
> core modules. Also debian has perl core and sub-packages
> as separated modules.
>
> This question was raised again in [1]. I suppose there would
> be conflicts after every update of main perl package, which
> could complicate it.
>
> So I'd like to hear pros and cons on this issue. Thanks.

Hey Marcela --

Some initial thoughts.  I'm not inflexibly attached to the below, it's
just a summation of what I happen to be thinking about it at the
moment.

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.)  Another two things:

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

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.

So, my initial thoughts are:

* We should allow for more frequent updating of dual-lifed dists
through updating as requested/needed.
* We should keep dual-lifed packages as sub-packages of core perl.
* 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.

The process suggestion above is an not to attempt to create more
layers of rules and procedures, but rather to normalize the update
workflow for core.  We all know how the individual package process
works, but in this area having a framework to operate in might make
life a little easier around this area.  If the above sounds relatively
sane, I'll put together something a little more comprehensive that we
can rip apart.  (Yeah, I know this was more than you asked about, but
I'm going with it :))

                                     -Chris

[1] http://search.cpan.org/perldoc?Moose::Manual::Contributing

-- 
Chris Weyl
Ex astris, scientia