On Tue, Mar 2, 2010 at 10:30 AM, Marcela Maslanova <mmasl...@redhat.com> wrote: > 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.
Is that really common? Surely once perl-5.10.2 is released (including perl-A-1.1), we would still want the latest-and-greatest perl-A-1.2 anyway. All we would miss is automatically running the full core test suite against perl-A-1.2 (which could easily be handled by bumping release for all separately packaged core modules once the new perl-5.10.2 is available). Wouldn't have the same problem with the current patch-based system if perl-A-1.2 was included in perl-5.10.1 as a patch? We'd either keep it as a patch in 5.10.2 or have to bump the epoch of the sub-package to revert to perl-A-1.1 from core. On the other hand, if perl-5.10.2 includes a newer perl-A-1.3, we'd get that automatically as a subpackage (and the separate perl-A branch would just sit there and do nothing until A-1.4 comes along and we decide to update it again). -- Iain. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
