On Fri, Mar 12, 2010 at 3:22 PM, Marcela Maslanova <mmaslano@xxxxxxxxxx> 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. -- 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
