dual lived modules

[Iain Arnell]

On Tue, Mar 2, 2010 at 10:30 AM, Marcela Maslanova <mmaslano at 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.