Re: 2008Q1 -> current: downgrade

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

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

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

> There aren't supposed to be downgrades, in general, and when there are
> they should be noted as such in CHANGES.
Yes. I said exactly this many times :-)

 >> >  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 ;-)

> Right. But not all upstream packages do
I think most (99.9%?) packages do.

> 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?

> Ideally, they always would. Documenting the proper steps to take in
> the pkgsrc guide would be a good start. (I'm pretty sure there's
> nothing at all there right now.)
  0 ~>grep dewey /srv/pkgsrc_current/doc/pkgsrc.txt 
  1 ~>

> Some of the glitches/mistakes you've discovered may have been made
> before dewey was systematized, too.
May be. 'cvs log dewey.c' may help to discover.

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

 >> > 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.
> No, they are not totally wrong.

There are much more than eight downgrades (formally speaking,
pkg_info(8)).  And all they were unseen for years. Why they happen is
another question.

> Yes, there are some cases where it might be helpful. But you haven't
> shown that these cases are common enough to make it worth the trouble
> of developing the infrastructure.
It is much easier to implement PKG_EPOCH than to invent strange and
dirty hacks to emulate it. If nobody of you need it - no problem.

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

> No, we're discussing a third thing, which is what version number
> semantics are observed in the wild and how this relates to the issue
> of "downgrades" (both real downgrades, as in moving to an older
> version, and apparent downgrades, where moving to a new version
> confuses pkgsrc-dewey).
It is interesting to know how many categories of all these downgrades
exist. But this information is useless. All these downgrades lead to
problems with binary upgrades. That is, many tools like 'pkg_chk -ub',
'pkg_add -u pkg' etc. just don't work. Whether any particular
downgrade is *real* or not - doesn't matter. Only pkgsrc-dewey
downgrades matter.

>   (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.

>   (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

>   (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.

>   (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.

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

-- 
Best regards, Aleksey Cheusov.