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
* 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.
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
>
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
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,