On Tue, Feb 02, 2016 at 04:17:45PM +0000, Paul Howarth wrote: > 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'm not sure it would be possible to do it the way you suggest, supporting both versioning schemes at the same time. The conversion could be largely automated and all packages could be altered & rebuilt during the next Perl mass rebuild, for example. With new generators in place. > 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. +1 > 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. Although I originally suggested the weird macros for dependency lists, I think they make the SPEC files harder to read. I still like the idea of a single-macro %prep/%install/%check sections as the code is almost always the same and looking them up in perl-macros isn't a difficult task at all. > Paul. Petr
signature.asc
Description: PGP signature
-- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org
