+ if SYSPKG_DATES is set in the environment, use the date for the
     version.  For some reason, this is controversial, so the default is
     to use NetBSD kernel versions.  Re-instate the code to calculate the
     date, but only use it if the date cannot be gleaned from the RCS Ids
     of the constituent parts.


i would go so far as to have it complain if it can't determine
the date from RCS id's, or some other mechanism.  i can't think
of _any good reason_ and _many bad reasons_ to add the build date
in here.  you've said that you would be able to say "my package
is fixed, it is newer than X" but it doesn't hold when X has no
fixed relationship to code base.  it seems clear to me that this
will result in both identically named but differently featured
packages, and different named but identically featured packages.

versions in packages are good. dated versions are even better
(you'll notice that my other free software uses dated versions
now.)  however, using the _build_ date? that seems utterly broken
to me.



.mrg.


(ps: i notice the "mplayer" package in CVS uses the "build date"
method and i've already twice been annoyed by it -- it gives me
*no* indication about when i 'cvs update'ed code but when i built..)