On Sat, Jun 14, 2003 at 07:58:54AM +1000, Daniel Carosone wrote:
> On Thu, Jun 12, 2003 at 10:24:38PM -0400, Jim Wise wrote:
> > As far as I can tell, with regpkg as currently committed, if I compile
> > _identical_ code on two different dates, I get different version
> > numbers.  Plus which, is a pkg versioned 20030614 built from the branch
> > `newer' or older than one with the same version number built from
> > - -current?
> > 
> > More damningly, if i compile newer code and then compile older code, the
> > older code gets a newer version number.  This, obviously, makes it
> > infeasible to include `affected' syspkg versions in SAs.
> > 
> > In contrast, the system which was discussed on the mailing lists,
> > documented, implemented, and committed previously, provides a constant
> > version number for constant code, provides correct ordering for newer
> > and older code, and gives us control over the granularity we want for
> > syspkg version numbers.
> 
> I don't want to wade into the argument over commit-now-or-later.
> I don't want to wade into the argument over version number format.
> I don't want to wade into the argument over implementation details.
> I don't know where this discussion has gone since it moved to
> tech-install, since I don't read that list.
> 
> I hope you guys can talk this out amicably and come to a reasonable
> conclusion.
> 
> That being said, I strongly hope that the conclusion has versioning
> behaviour similar to what Jim describes above.  It really is
> important.  My interest is obviously the SA case, and this is a
> clear example of a need for the above behaviour, but there
> are others.

So there are a number of things to take into consideration.

Jim's naming scheme, in conjunction with the way that pkg_info(1) does
its version numbering, mean that 1.6A is the same as 1.6.1.  This is
not a good thing.

Whatever does the kernel version have to do with a given userland
package?

The fact that people have to add the nb version number to another
file doesn't fill me with awe and wonder. Developers are human, except
for a few corner cases, and forget to update this file.

Date-based comparison has been used in pkgsrc for the dependency
checking for around 4 years, and works very well.

Now let's move onto the assertion:

"documented, implemented, and committed previously, provides a constant
version number for constant code, provides correct ordering for newer
and older code, and gives us control over the granularity we want for
syspkg version numbers."

"provides correct ordering"? No, it doesn't.

"control over the granularity"?  So 1.6T is good enough for everyone
running -current?  When 1.6T has been the kernel version for 2 months?

Jim hasn't explained why he doesn't like the date number, which is
logical, simple, and requires no manual futzing.

> I think there's probably good reason for the version numbers to
> bump "automatically" too, such as when dependencies bump, and other
> events.  We don't want to force all version bumps to require manual
> developer effort - or some will be missed.
> 
> In other words, for the SA case, I don't care how many other version
> bumps happen between one SA for the ssh package and the next.  I
> just need to be able to say in an SA: "if you have a version <X,
> you are vulnerable to this issue, please upgrade to at least version
> X".
> 
> The simpler it is for users to determine this, the better.

I completely agree.  "If you're running a package from before
20030606, you're vulnerable" seems quite logical and simple to me. 
OTOH, "if you're running a package from 1.6Tnb2 on the -current
branch, or 1.6.1nb5 on the -release branch" is a bit tenuous to me.

Regards,
Alistair