On 21/02/11 12:45, Petr Pisar wrote:
> On Mon, Feb 21, 2011 at 11:10:50AM +0000, Paul Howarth wrote:
>> On 21/02/11 10:46, Petr Pisar wrote:
>>> commit 1285f98b06408386236a3dbb1b261c9e4af55290
>>> Author: Petr PÃsaÅ<ppisar@xxxxxxxxxx>
>>> Date: Mon Feb 21 11:45:56 2011 +0100
>>>
>>> 5.37 bump
>>
>>> +# Version unversioned Provides
>>> +%filter_from_provides s/^\(perl(Coro\>[^=]*\)$/\1 = %{version}/
>>
>> I think if you're going to add a version number to the provides, it
>> might be better to use 0 rather than %{version}; many module authors
>> version sub-modules differently to the main module included in a
>> package, so you may be creating versioned provides that are "newer" than
>> ones that upstream may introduce in the future.
>>
>
> These one is subsequent Perl module in the same file extending non-Coro module,
> so IMO it should have the same version as main module.
That's upstream's decision though. They might have completely different
version numbers in the general case (probably not in Coro's case, as all
existing modules have the same version number), such as for example:
http://search.cpan.org/dist/Mail-Mbox-MessageParser/
> Injecting 0 is pointless. Better no version than useless 0.
On the contrary, no version is equivalent to "any version" as far as rpm
is concerned, which is a problem waiting to happen and why rpmlint will
complain about it if you explicitly add an unversioned provide. Adding a
version of 0 means that any sane versioning scheme introduced by
upstream in the future will be "newer" than what you've already used.
At this time there shouldn't be any versioned requires on these provides
since upstream doesn't version them, so having a version 0 provide
shouldn't break anything.
Paul.
--
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
