Re: 2008Q1 -> current: downgrade

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Mon, Jul 07, 2008 at 12:35:59AM +0300, Aleksey Cheusov wrote:
 > > know new versions of software frequently don't deliver that. :-)
 > > That's a matter of translation though.
 >
 > Ok. Then 'changes-entry' Makefile's target works incorrectly.

No, it works fine. Take it up with your dictionary. :-p

 >>> Of course I use dewey approach ;-)
 >> Right. But not all upstream packages do
 >
 > I think most (99.9%?) packages do.

Most do. Some don't. Not all of these have had their version numbers
translated for pkgsrc, particularly in the past.

 > > Again, sometimes people who import packages adjust for version
 > > numbering semantics properly and sometimes they don't.
 >
 > The goal is to NOT make such sorts of mistakes. Right?

Sure.

 > > What do you mean by "???"?
 >
 > This means "the above sentence/paragraph is not clear enough for me".

ok, I wrote this:

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

In four cases that I saw, the version number copied into pkgsrc was
not the same as the version number of the original package. E.g. if
one has foo-1.01 and then updates to foo-1.02 and then foo-1.03, only
foo-1.02 is accidentally imported as foo-1.20, the update to foo-1.03
will show up as a downgrade.

Better?

 > > No, they are not totally wrong.
 > 
 > There are much more than eight downgrades (formally speaking,
 > pkg_info(8)).

No, there were three downgrades. There were a lot of cases that
confused pkgsrc-dewey. If you want to insist on calling all the latter
cases "downgrades", even though no package downgrade took place,
that's up to you, but it's creating confusion.

 > And all they were unseen for years. Why they happen is
 > another question.

Yes, but why they happen is important if the goal is to avoid having
them happen. Version changes that confuse pkgsrc-dewey are clearly
bad.

 > It is interesting to know how many categories of all these downgrades
 > exist. But this information is useless.

No, it is not. The information is necessary for figuring out how to
make it stop. Adding support for version number epochs would not fix
the vast majority of the cases you reported. Using version number
epochs for the vast majority of the cases you reported would be flatly
wrong. It would not solve the problem and create a whole new layer of
confusion and entropy.

 > >   (a) putting a lot
 > A lot of? Some of you said that PKG_EPOCH can be impelmented in two
 > hours or so. It's trivial for me to adapt wip/awk-pkgsrc-dewey.
 > 
 > > of effort in to handle real downgrades specially
 > >       is not worthwhile;
 > See above about *real* and pkgsrc-dewey downgrades.

Epochs would not fix the problems you're complaining about, because
the problems you're complaining about are not caused by upstream
package versions going backwards.

 > >   (b) putting a lot of effort in to handle version epoch changes isn't
 > >       worthwhile since there are other ways to cope;
 > What's the recomended way? For my example in FreeBSD ports where
 > libmaa was versioned 1.10.11 while real version is 1.0.0

agc just explained this again.

 > >   (c) it *is* probably worthwhile to run some kind of crosschecking
 > >       script that complains about things that look like downgrades to
 > >       pkgsrc-dewey, since the vast majority of them are errors;
 >
 > updates-entry is ideal place for this IMO.

Maybe. What would you have it do, check for the previous entry in
CHANGES-* and compare the version numbers? That might work.

 > >   (d) it is probably worthwhile to find some way to teach dewey about
 > >       YYYYMMDD version numbers;
 > x.y.z INCOMPARABLE with YYYYMMDD? LT, EQ and GT are enough.

Nah. The problem is how to tell reliably that you're looking at
a YYYYMMDD. Once you can identify that, it's easy: the date stamp is
a dewey field of low precedence akin to alpha or beta numbers.

That is, 1.0-20080601 should sort less than 1.0 and greater than 0.9,
and 20080601 standing alone should be interpreted as 0.0-20080601.

This isn't that difficult (AFAIK) but I'm not convinced that using a
regexp like [12][90][0-9][0-9][01][0-9][0-3][0-9] to find date stamps
is really all that safe.

 > >   (e) the documentation of how to handle version numbers in pkgsrc is
 > >       inadequate.
 >
 > At least dewey should be fully described in pkgsrc guide.

Yes.

-- 
David A. Holland
dholland%netbsd.org@localhost