Hubert,

I think we all get the picture by now that you don't like digest.

So, let's assume for a moment that we ditch digest, and move to a
modified cksum(1) utility.

If we're to move ahead with using the new, sha1 and rmd160-aware
cksum(1) on all platforms, this is what we'd have to do to support it
in pkgsrc:

1.  we need to make a package for cksum(1).  Not a biggy, quite easy
to do.  It needs to go into /usr/bin (that's where it is on NetBSD at
the moment), so it would look something like the pkg_install package
in format.

2.  it needs to grow a version flag, since we want to know whether we
have a cksum binary which supports the sha1 algorithm, at a minimum. 
Again, not a biggy, since -V is not yet taken in cksum, but we need to
support old versions of cksum that don't have a -V flag.  We could
even do the RCS Id date manipulation that we used to do with the
pkg_install tools, but remember that all that processing comes with a
price, and we're trying to get away from that overhead.  We do need to
know the version, since I believe the sha1 code in libc until very
recently was buggy on Alphas.  Oh, and the ident strings don't show
the version of code in libc.so that's dynamically linked in?  Bummer. 
How do we know whether we have the correct sha1 code on Alphas?  Dunno.
Anyway, let's move on.

3.  This package that we create for cksum - it can't have any patches,
can it, since how would we check (a) the distfile, and (b) the patches
if we don't have an existing message digest calculation method.  Use
the existing md5 sums that we have?  Yes, but that means that cksum
has different handling in its checksum and patch-sum targets from
every other package on the system.  So we don't use checksums at all
for the cksum package?  Not too happy about this one, since we'd have
to fetch a distfile without using a checksum to make sure that
no-one's tampered with it. How about bundling the source with pkgsrc?
Yes, good idea, that would work, let's go with that.

4.  We really need a statically-linked utility, if ever we're going to
install a system using packages of any kind.  The trouble is that
space is tight on almost every platform in /bin, and moving cksum
there may cause problems on some platforms.  Again, not that much of a
biggy, but the upheaval that this causes is going to be felt by quite
a few.

5.  On other OSes, such as Solaris, Linux etc, you'll need to make
sure whether you can use the existing cksum binary, or install your
own under ${LOCALBASE}.  Again, not a biggy, just gets kind of
confusing when you're working out which binary your path picks up. 
True, we could always specify the full path in bsd.pkg.mk, like we do
with patch, but I always hate it when I have two executables of the
same name in public dirs, since I know for a fact that I'm going to
get problems with people who say "the packaging system tells me the
checksum is wrong, but my cksum utility doesn't know anything about
sha1." Not insurmountable, just a nagging doubt.

So, let's recap: we need to have a small utility, bundled with pkgsrc,
no patches, supports -V flag, able to be installed without any fuss as
a package. Oh, and preferably statically-linked.

Now where have I seen that kind of package recently?

Regards,
Alistair