I recently came across this message which, rather than going to
tech-pkg, went elsewhere. I don't intend to do anything about this
in the near future (though I'll happily comment if someone decides
to take this up), but I'm sending this here for discussion and
archive purposes.

cjs

Curt Sampson    cjs@portal.ca	   Info at http://www.portal.ca/
Internet Portal Services, Inc.	   Through infinite mist, software reverberates
Vancouver, BC  (604) 257-9400	   In code possess'd of invisible folly.

---------- Forwarded message ----------
Date: Mon, 15 Jun 1998 08:45:11 -0700 (PDT)
From: Curt Sampson <cjs@portal.ca>

On Mon, 15 Jun 1998, Charles M. Hannum wrote:

> The pkg system:
> ...
> * needs local (NetBSD-specific) version tags on binary pkgs, so that
>   when we change a pkg it can be distinguished from an older version.
>   (C.f. RedHat.)
> 
> * needs to deal gracefully with having multiple builds of a binary pkg
>   (e.g. for RSAREF and non-RSAREF builds of ssh), possibly even
>   available in the same directory.

Yes, I think we need a proper versioning system, one that the
package tools can understand. I think having package information
broken down into the following would help.

    name (string)
    major rev (int)
    minor rev (int)
    patchlevel (int)
    netbsd package build rev (int)
    vendor version string (string)
    build options (string)

This would allow the package tools to see if a package is already
installed (by comparing names), whether the one someone is proposing
to install is newer (by comparing, from most significant to least
significant, major, minor, patchlevel and build revs), and what
options (RSAREF, NOIDEA, etc.) were used when building the package.
Then pkg_add can replace packages, rather than just installing over
top of an already-installed one, suggest to the user that perhaps
he doesn't want to install an older version of a package, and the
like. We would keep the vender version string for refence, since
we'd have to convert letters and the like into numbers for our
system (e.g., foo-1.3beta2 would probably turn into 'foo', '1',
'2', '0xfffe0002', '0' or something similar, so as to be numerically
less than the non-beta foo-1.3, '1', '3', '0', '0'). (We might
conventionally use 0xfffd0000 for alpha, 0xfffe0000 for beta,
0xffff0000 for gamma.  Or whatever.)

This would also help with things like /etc/security; we could have
a list available of known security-risk package versions and have
it verify that none of those buggy versions are installed on the
system.

I also agree that sysinst should be able to install and remove
packages. Being able to do so would let us turn some of our current,
often-updated-or-replaced programs into packages (such as sendmail
and BIND). That would make my life as an admin much easier, becuase
I can a) update packages *much* more quickly and easily when a
security hole is discovered, and b) don't have to worry about my
version of BIND (I use 8) or sendmail (I intend to use 8.9) being
tromped on when I upgrade a system. I'm not proposing we go the
Red Hat route and turn everything down to the level of /bin/cat
into a package, but just a few things would be a big help.

> * should deal with the Motif/lesstif crap better; i.e. be able to
>   build lesstif and Mozilla (Lesszilla?) without modifying mk.conf.

I just built lesstif and mozilla yesterday without touching mk.conf.

cjs

Curt Sampson    cjs@portal.ca	   Info at http://www.portal.ca/
Internet Portal Services, Inc.	   Through infinite mist, software reverberates
Vancouver, BC  (604) 257-9400	   In code possess'd of invisible folly.