----- "Iain Arnell" <iarnell@xxxxxxxxx> wrote: > On Mon, Mar 1, 2010 at 9:33 PM, Chris Weyl <cweyl@xxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/perl-devel -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
