On Fri, Mar 09, 2001 at 12:32:57PM +1100, Simon Burge wrote:
> Masao Uebayashi wrote:
> 
> > > if it's not included into pkg_install because it has a much wider focus, I
> > > wonder why it was placed in pkgsrc/pkgtools.
> > 
> > IMHO, if 'digest' is needed by the pkgsrc system itself, 'digest'
> > should be included in the base source distribution like /bin/sh and
> > /usr/bin/make. It should be also distributed as a binary tar ball (NOT
> > package!) for users using releases.
> 
> Coming in a bit late here, but one option as to add the new algorithm(s)
> to "cksum", or even one of the "pkg_*" programs (say pkg_admin).  The
> later would stop any external dependancies on non-standard tools...

Sorry to all the other people on this list for repeating myself, but Simon
is coming in a bit late.

The decsision was taken not to add the functionality to cksum(1) because:

+ up until now, cksum has been one of the basic building blocks for
pkgsrc.  Zoularis has to do some horrible hacking to get it to work,
which is distinctly non-portable

+ cksum is not statically linked

+ md5 was not added to cksum in a particularly scalable way

+ no rmd160 or sha1 algorithms are available in cksum

+ the existing args to cksum don't allow for scalability

+ using argv[0] to determine the algorithm to use is not the best way

+ there's no version string available from cksum

+ the code in bsd.pkg.mk to determine the path of md5 should be
completely unnecessary.  I get nasty feelings when pkgsrc depends on
system components in NetBSD, because it makes it more difficult for
other systems.  (To illustrate this, say that I add md5, sha1 and
rmd160 functionality to cksum.  On NetBSD, where does the new binary
go?  in /usr/bin, as it is now?  If it happens like that, how do you
work out easily whether cksum has sha1 functionality?  Run-time check? 
RCS Id check?  Or a bug is found in our implementation of one of the
newer algorithms.  I then have to check libc versions?  It starts to
get hairy. We haven't even started talking about multiple versions
on Solaris or Linux).

I really wanted to distribute source with pkgsrc (it's small enough),
keep it lean and mean, and build it as and when we need it.

Some of these are more difficult to solve than others, but I did look
into the possibility.  In fact, I still have my modified cksum sources
around here, if anyone has a strong-enough stomach to wonder why I
implemented digest.

Now, as to why I didn't put it in the pkg_install tools:

+ I don't consider it related to the pkg_install tools (the 
pkg_create checksumming is still done with md5 from libc).

+ why not put a "pkg_" prefix on it?  Because it's a utility for
checking hash values.  If we followed the same logic, we'd have
ffs_cp, timesheet_vi, or www.netbsd.org_mozilla.

+ I wanted to distribute the source with pkgsrc, and build it when
needed (it's small enough, after all)

+ I've been criticised in the past for making the pkg_install package
not register itself (so that you can't delete it in error), but it
means that a binary package for it can't be made.  I didn't want to do
the same here.

+ I wanted to keep it lean, mean and scalable.

+ there are new algorithms that I want to add to digest RSN, once I've
confirmed their results.

+ there are areas of use for this outside pkgsrc, but I don't want to
go into that here

It's interesting - this is one of the smallest packages I've ever added
to pkgsrc, and yet it's the one that has encouraged the most dissent.
I'm obviously losing my touch.

Regards,
Alistair