dual lived modules

[Iain Arnell]

On Fri, Mar 12, 2010 at 3:22 PM, Marcela Maslanova <mmaslano at redhat.com> wrote:
> I created testing repo [1] with two updated core modules
> and updates repo with perl(core) packages.
> I've tested this scenario:
> 1/ perl package with perl-Module-Build-0.3500-110.fc13 and perl-version-0.77-110.fc13
> 2/ update from [1] to perl-Module-Build-0.3603-1.perltestrepo.noarch.rpm and perl-version-0.79-1.perltestrepo.i686.rpm
> 3/ enable 'marcaperl-update.repo'
> 4/ update to perl-5.10.1-112.1.perltestrepo.i386.rpm, perl-version-0.80-112.1.perltestrepo.i386.rpm, perl-Module-Build-0.3500-112.1.perltestrepo.i386.rpm
>
> This should test whether yum can handle lower version in main and higher
> in separated package (Module::Build). The update of packages went fine if
> 'Obsoletes' is used in new package [2].

Aha. Of course - 'Obsoletes' is necessary, but not why you think.  The
problem here is that we may be moving from arch-dependent packages
(i.e. 1:perl-Module-Build-0.3500-110.fc13.x86_64) to noarch packages
(i.e. 1:perl-Module-Build-0.3603-1.perltestrepo.noarch). Even though
ENVR is higher in the noarch package, yum wont automatically update
from arch-dependant to noarch. I guess that we should really fix
perl.spec so that the noarch subpackages are really noarch too.

> My proposal of updates shouldn't
> be included in packaging guidelines, so we should be able to change it
> flexibly to the current situation. Not sure if this change of packaging
> core modules must be discussed by FESCO because it's not mentioned in
> Packaging:Perl, but it could be viewed as conflict with common PackagingGuidelines.
> Also the time is not good with further disscusion on other channels,
> so please check/test, whether I missed something.

Maybe we should get in quick and package/review all existing core
modules separately while everyone else is busy fighting over update
policies ;)

I don't see anything in the existing guidelines that would prevent a
single binary rpm coming from more than one source rpm. But I guess we
shouldn't try to sneak this in - it would certainly be better to have
this loophole codified in the guidelines to prevent what you're
proposing by default, but to allow FPC/FESCO approved exceptions (come
to think of it, is there anything in the guidelines that prohibits me
from having '%package -n kernel' in a spec?). I'd even suggest that
the owner of the main package MUST be the owner of any independent
sub-packages too.


-- 
Iain.