Re: About versions and macros

2016-03-03 Thread Petr Šabata
On Thu, Mar 03, 2016 at 03:47:57PM +0100, Emmanuel Seyman wrote: > > > 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

Re: About versions and macros

2016-03-03 Thread Emmanuel Seyman
* Petr Šabata [03/03/2016 14:44] : > > 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.

Re: About versions and macros

2016-03-03 Thread Petr Šabata
On Tue, Feb 02, 2016 at 04:17:45PM +, 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 >

Re: About versions and macros

2016-02-02 Thread Paul Howarth
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

About versions and macros

2016-01-29 Thread Petr Pisar
Hello, Warning: This e-mail is long and proposes changes in Perl packaging. The Problem === I decided to tackle the long standing issue with Perl versions that are not compatible with RPM. For example, you have a module or distribution in version 1.2, then 1.21, then 1.3. In addition,