[email protected] wrote:
I'm not sure I understand your point. If a customer uses bart(1) to
build check sums of a system and then uses that on another
"identical" system they will think the systems are different. No
need to involve the pkg system at all. Customer do this and will
then call us if they have systems that are running the same release
but the files are different.
What I'm suggesting, since we own bart(1), is that we have the ability
to teach bart(1) to use a pkg(5) API when looking at files.
That is fine for bart(1) and there are already plans in that area. It
won't help Tripwire or any number of the commercial tools out there that
deliberately don't (or can't) look at the file type and parse its
content. It also won't help those that use the compare output of the
GNU md5sum (and similar cross platform tools).
There is a well established body of work in the industry across many
platforms (not just the Unix like ones) of using programs (many of them
cross platform) based on checking the digest/hash of the whole file to
determine if two installations are the same (where it can be the same
system over time or two or more distinct systems).
The fact that a pkg(5) based install can produce two installations that
are not identical when the whole file is looked at is going to cause a
lot of customer confusion and false alarms. The financial and time
expense of that confusion for some customers could far out weigh any
optimisation they get from the checking of the elfhash rather than the
full file. On the other hand for people following a fast moving
repository that have low bandwidth it may well be a choice that is worth
taking.
Yes the optimisation is a very clever one and it is probably saving a
lot of downloads for some people - is there enough data in the logs of
pkg.opensolaris.org and ipkg.sfbay to calculate if this is actually the
case ? If so it would be a very interesting article.
I don't think pkg(5) should document the internal methods used to
implement the verify subcommand but it does need a very clear statement
about the fact that in some cases a file may pass verify but have a
different whole file checksum to that used by external methods (eg, mdsum).
My current belief is that this optimisation is great for the /dev
repository but won't be suitable for some enterprise deployments of
Solaris Next.
An alternative to doing the deduplication (which is what this is really)
at pkg publish time would be to keep the current method but allow a per
repository setting on the client that determines wither full file hashes
/signatures are always used or if the optimisations can be used.
--
Darren J Moffat
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
