On Fri, 9 Mar 2001, Alistair Crooks wrote:
> + 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

So if Zoularis is the problem, fix it. 


> + cksum is not statically linked

Why is that important?


> + md5 was not added to cksum in a particularly scalable way
> + no rmd160 or sha1 algorithms are available in cksum

Well, why not replace the current cksum implementation with digest
then? As far as I understand, digest does most things cksum does now, and
if digest is coded in a scalable way, the missing things should be easy to
add. But see below if we really want that...


> + 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 don't see why this shouldn't work as in pkg_install now. 
Replace pkgtools/digest with security/cksum that has
NO_PKG_REGISTER(?) set, and be done. 

Plus there's always the way to put things into pkg_admin, if you want
REALLY tight integration. See below. 


> 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.

This again makes me wonder why we don't put pkg_* sources into pkgsrc then
by that reasoning.


> 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.

But why put it into pkgsrc/pkgtools then?


> + 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

Wouldn't one use openssl then? 
Sorry, but the B-word comes to mind...


> 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.

Maybe. At least the integration of this seems questionable.

One question that remains unanswered is why the checksumming inside
installed/binary packages was not changed at the same time, and was
obviously left out in the design of this whole new checksum framework. 
If someone ever wants to fix that, he'll have to go through big troubles
to do this, due to the implementation method chosen for this.

One way for a solution that fits all parts of pkg_*/pkgsrc would be to put
the checksumming code into pkg_install/lib, then make pkg_admin a frontend
-- which would allow you to do the interfacing that cksum(1) lacks and
that yet another program was chosen -- and modify pkg_create, pkg_delete
and whatnot to use the checksumming code from pkg_install/lib.


 - Hubert

-- 
Hubert Feyrer <hubert.feyrer@informatik.fh-regensburg.de>