[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: The pkgsrc-2008Q3 Branch
>> I know I'm really annoying but problem with packages downgrades is
>> still not resolved.
>> 2008Q2 vs 2008Q3
>> > converters/p5-Convert-UUlib p5-Convert-UUlib 1.080 1.11
>> > time/p5-Data-ICal-DateTime p5-Data-ICal-DateTime 0.65 0.7
>> > time/p5-DateTime-Locale p5-DateTime-Locale 0.4001nb1 0.41
>> > www/p5-HTML-LinkExtractor p5-HTML-LinkExtractor 0.121nb2 0.13
> These are all perl packages. I suspect I may be at least partly
> to blame.
Until this problem is solved, uploading perl module binaries to
ftp:// seems useless to me.
> However... This is a result of a culture clash between some
> parts of the perl community's conventions for numbering perl
> packages, and the pkgsrc version numbering conventions.
> I've been told (this may not be accurate?) that a perl $VERSION
> with x.y.z format will be incorrectly interpreted (by perl?).
> This is what gives rise to sequences similar to 1.1 -> 1.1001 ->
> 1.2 which can sometimes be found in certain perl packages. If
> we're to strictly adhere to the pkgsrc numbering conventions, 1.2
> should probably be 1.2000, or 1.1001 should have been 1.1.1 in
> However, if we decide that we strictly must adhere to our own
> conventions for package version numbering, doing direct and
> accurate comparisons between perl/CPAN module version number
> strings and pkgsrc package version strings will become
> essentially impossible in those cases where we provide the
> required "padding" when creating the pkgsrc version number.
> So... what's the correct thing to do?
How others resolve this problem?
Compare these numbers with those from pkgsrc.
I don't use perl but maybe 1.1001 -> 1.10.01?
Anyway checks for downgrades should be made/automated between pkgsrc releases.
My wip/pkg_summary-utils provides everything needed for this.
Best regards, Aleksey Cheusov.
Main Index |
Thread Index |