Re: 2008Q1 -> current: downgrade

[Aleksey Cheusov <cheusov%tut.by@localhost>]

> On Thu, May 22, 2008 at 11:51:12AM +0300, Aleksey Cheusov wrote:
 >> [downgrades]
 >>
 >> pkgsrc versions fetched by 'cvs up -D<DATE>'

> The overwhelming majority of what you've found are actually upgrades
> documented perfectly well in CHANGES-*.
Not exactly. CHANGES-* says "updated". "updated" means either upgraded
(version is increased) or downgraded (version is decreased).
Thus, there is no information about downgrades in CHANGES-* files.
No automatic collecting an information about downgrades - no control
over them. This is what pkg/39080 is about.

> They show up as downgrades to
> you and/or pkgsrc-dewey because of disagreements about the semantics
> of version numbering, most commonly:

>  o  Dated snapshots normally come before numbered releases, but you're
> describing the transition as a "downgrade".
This is not MY problem. This is how dewey actually works.  Versions in
X.Y.Z format are always lower than that in YYYYMMDD format.  This is
how dewey is documented in pkg_info(8)

>  o  Disagreement over whether 1.19 > 1.2 (the "dewey" approach) or 
> 1.2 > 1.19 (the "decimal number" approach).
Of course I use dewey approach ;-)

>  o  Disagreement over whether an alpha/beta version like 1.1b3 comes
> before the release version 1.1; it should and I think pkgsrc-dewey
> recognizes this if it's presented correctly, but either some old
> revisions don't present it correctly or your script did the wrong
> thing.
According to pkg_info(8) 1.1a3/1.1b3 is not alpha/beta versions
of the package.
These versions are equal to to 1.1.1.3 and 1.1.2.3 respectively.

   1.1.1.3 > 1.1 and 1.1.2.3 > 1.1

So, my script works correctly. "alpha" and "beta" versions should be marked
as 1.1alpha3 and 1.1beta3.

>  o  In one case, the use of hex digits in version numbers.
??? There is nothing about hex numbers in pkg_info(8).
All alphabetic characters are valid in dewey version
in any position. 1z1 is equal to 1.26.1 and 9abc9 is equal
to 9.1.2.3.9. This is how it is documented in pkg_info(8).
alpha/beta/rc and some other letter sequences are treated especially.

> There are also a couple of cases where mistakes transcribing version
> numbers into pkgsrc resulted in apparent downgrades, either
> immediately or downstream.
???

> There were a couple of cases where upgrades of one of the above forms
> failed to make it into CHANGES, which is undesirable but irrelevant to
> discussion of downgrades.
??? See above.

> There was also one intentional downgrade that was documented in
> CHANGES.

> Of the eight (yes, only 8) cases remaining from those you posted:
Much more than 8 ;-)
Anyway CHANGES-* file in its current form doesn't provide
an information about upgrades and downgrades.
"changes-entry" make's target needs to be fixed ( pkg/39080 ).

> It is not entirely clear to me what other points you may be trying to
> make with this list (or by filing it in a PR). Could you please
> explain?

First, your numbers (two, three and eight) are totally wrong. Second,
I have already showed (in my previous emails) real life examples
why PKG_EPOCH is helpful and
in which cases.

Fourth, do not forget we are discussing two different things:
1) CHANGES-* doesn't provide an information about downgrades.
2) PKG_EPOCH.
They are close but different. 1) is about why unseen downgrades happen,
2) and is one of the way how these downgrades can be fixed.

YET ANOTHER case/example why PKG_EPOCH may be useful.
For about six years I maintain DICT project, http://sf.net/projects/dict,
www.dict.org. It provides dictionary protocol (RFC-2229) server and client,
dictionary formatting utilities and... general purpose library MAA.
For years both dictionary tools and libmaa are distributed as a single tarball.
Current dictd/dict version is 1.10.11. Libmaa's version is 1.0.0.

Recently I've found that a few months ago FreeBSD guys created a
devel/libmaa package and numbered it 1.10.11 just like dictd/dict, while
correct libmaa version is 1.0.0.  This type of package maintainer's mistakes
can easily be fixed using EPOCH in FreeBSD ports but not in
pkgsrc. Renaming this package/PKGBASE to something like libmaa-foobar
is bad idea.

-- 
Best regards, Aleksey Cheusov.