>So, is it now open season for thousands of developments invent thousands
>of different features which are required to verify the integrity of their
>packages, and then insist that a single package maintenance tool satisfy
>all of them?
>
>That is downright silly.
Yes... but a distribution package is a means to an end, not an end in it's
own right. I would hope a good distribution package would accomodate the
millions of non-mainstream packages out there - after all, that's how many
of the bests ones started life; as small blips on the software radar.
>> There's no sense in modifying the Redhat binary verification system to
>> understand the magic necessary to verify qmail binaries. However, adding
>> a generic per-package verification hook would make a great deal of sense;
>> rather than (or in addition to) the checksum verification, each package
>> can provide a /bin/sh script that knows how the details of verifying
>> files under its aegis that may resist checksum verification, for whatever
>> reason. In the qmail package, this script would copy the qmail binaries
>> from the CD-ROM, insert the uids, and then compare the on-disk binaries
>
>Uh, huh... And would you care to volunteer to write the code which will
Certainly the energy expended *not* discussing a solution on this list would
probably be more than sufficient to do the job.
>know the location of the CD-ROM device on every UNIX system out there,
>in addition to knowing the location of the original binaries that are
>shipped with every UNIX distribution out there?
I'd hope the verification hook would provide a much more pleasant
interface - perhaps by have special fds set, environment variables,
current working directories, etc, etc.
Are you saying you cannot think of ways in which a package installation
program might do this in an easy-to-use manner?
qmail-command is a good example of a friendly hook/interface that
accomodates all manner of customizable requirements thru judicious use of
pipes and environment variables.
Regards.
