Subject: Re: Why commands in the source tree don't have version?
To: Masao Uebayashi <uebayasi@soum.co.jp>
From: Alistair Crooks <agc@pkgsrc.org>
List: current-users
Date: 02/15/2001 12:09:12
On Thu, Feb 15, 2001 at 12:24:30PM +0900, Masao Uebayashi wrote:
> > The reason pkgsrc uses an "nb" suffix is so that we can distinguish the
> > changes that we have made to the base package (i.e. if we patch version
> > 1.4 of a package, we make it 1.4nb1, so that any 1.4.1 version from the
> > package's authors doesn't clash with our fixes).
> 
> Then how should we deal with, say, /usr/bin/ssh which is imported from
> OpenSSH? The original version (2.3.x) is needed to leave? Or use only
> our version like 1.5.0.x? IMHO, original versions have less meaning in
> terms of making system consistent. (This is applied to pkgsrc, too.)

I believe that ssh should keep the version number from the author,
as this is used by the protocol when attempting to connect. Be it
openssh, fressh or whatever. Itojun also mentioned telnet being in
the same boat.

As a datapoint, we include build version information in every binary
package that is built - every file which has a NetBSD RCS Id and is
used to control the building of the package has its Id stored in the
build info file.  This helps us work out exactly what version of a
package you are working with.  For more information, see "pkg_info -b
<pkgname>" output. It's not inconceivable that this file could then
be checksummed itself, and that checksum used as a key into a table
to work out our own versioning [1].

As far as packages go, we go with the original version name to identify
the packages. This is consistent with the names in the big bad world -
you get informed of security vulnerabilities in ssh 1.2.26, for
example, not NetBSD RCS Id 1.45. That's what we use in audit-packages
to work out whether a machine is vulnerable, too.

So I think I disagree with your assertion about pkgsrc above.
 
Regards,
Alistair

[1] package-orientated example follows:  "pkg_info -qb <pkgname>"
produces output like:

<category>/<pkgname>/Makefile:# $NetBSD: Makefile,v 1.1.1.1 2000/12/05 02:04:49 wiz Exp $
<category>/<pkgname>/files/md5:$NetBSD: md5,v 1.1.1.1 2000/12/05 02:04:49 wiz Exp $
<category>/<pkgname>/files/patch-sum:$NetBSD: patch-sum,v 1.1.1.1 2000/12/05 02:04:49 wiz Exp $
<category>/<pkgname>/pkg/PLIST:@comment $NetBSD: PLIST,v 1.1.1.1 2000/12/05 02:04:49 wiz Exp $

which could be piped into md5 to get:

9f0f6556266495addbf4314458c3a90d

You can then have a versions file which says
9f0f6556266495addbf4314458c3a90d nbv1.1
<next checksum.................> nbv1.2
<next checksum.................> nbv1.3

so you then have an easy way of conversing with people using a sane
"version numbering scheme".  What I mean by that is:  "<pkgname> has a
problem in versions nbv1.1 and nbv1.2 - nbv1.3 is OK", rather than "if
your package was built with a Makefile dated ....", or, worse still,
"<pkgname> source from before June 1999".  This is because, in pkgsrc,
it's unlikely that we'll have NetBSD RCS Ids embedded in an individual
package's source.

[I think if anyone wants to continue talking about this, then tech-pkg
would be a better place.]