On 29/01/16 12:34, Petr Pisar wrote:
Compatibility ============= Introducing this normalization requires changing both build-requires and run-requires at the same time (you cannot provide "perl(Foo) = 1.2" and build-require "perl(Foo) >= 1.200"), the normalization would be enabled at one of the Perl mass rebuilds. But we could start using the macros gradually even before the big switch. For those who would not find all the macros appealing and would not convert their spec files, we could just wrap the version strings in BuildRequire and Requires statements into %perl_v macro automatically by a script.
I think it would be very difficult to change all perl packages to normalized version numbers in one go, which makes me think that maybe the existing and normalized schemes should have their own namespaces, both provided by perl dependency generators. I think the provides probably need to appear prior to the requires so that the new scheme can be bootstrapped (maybe just before a mass rebuild?). If the two schemes co-exist then packages can be migrated at a more leisurely pace by maintainers that are keen on this apporach.
I think having a versioning scheme that works the same way as rpm's versioning is a good thing and would avoid plenty of hacks and the need for some epoch bumps.
As for replacing much of the existing boilerplate with macros, I'm personally less keen on that because I think it actually makes specs harder to read, at least until I know what each of those macros actually does under the hood. It's like when I see some SuSE package specs and have to go figure out what all those macros actually do so I can see what's happening in the package build.
Paul. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
