Re: Add SHA512 digests to package metadata

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On 19 October 2015 at 13:39, Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> On Mon, Oct 19, 2015 at 01:27:58PM -0700, Alistair Crooks wrote:
>> My way of working is to make a number of small changes, and lots of
>> them. This usually prevents big bang scenarios. You obviously prefer
>> to make fewer, but more far-reaching changes.
>>
>> I'm not saying that one approach is better than the other, but I also
>> think that trying to make your approach work for me is going to be
>> counter-productive, much as if I were to try to encourage my way of
>> working onto you.
>
> I don't think that introducing @digest for this purpose is any more
> complicated in nature that hacking in an additional magic comment
> string. It uses more common parser infrastructure and trades it for a
> minor complication of making sure that pkg_install itself does not get
> the SHA512 digest for bootstrap purposes.

This is missing the point - introducing a new @digest "keyword" to the
+CONTENT files will take a while (I, for one have no desire to watch screenfulls
of useless

pkg_admin: Unrecognised PLIST command `@digest
SHA512:b98b9bd31f640a6f71249ea7be36d32396971664854b8aadb8022733ca595a2aff9f78f92a5b7e0f0298f86902de2226bf4b4788294888d6cfb71c7f5742f962'

fly past for every entry in every package where I'm using a downlevel set of
pkg_install tools to install a binary package that someone has built with new
pkg_install tools). There is much more of an emphasis on binary packages these
days, especially with the advent of pkgin and binary package signing.
Now I'm not ruling out a flagday, just saying that what you're painting as
"not much work" entails a whole amount of work, actually, but mostly time.

Strategically, the +CONTENTS files are about state of the art for 1997,
but we'd be better updating that in a rewrite to do the whole thing, and I'd
be surprised if we didn't end up using some form of sqlite database, or
perhaps cdb :), to hold the information for the binary packages - it's not
going to change after all. The pkgng json attempt is not a valid contender
for a number of reasons. I know you were instrumental in the 2006 rewrite,
but this particular part wasn't changed then, maybe it should have been?

> But let's go back to your patch first. The existing @comment handling is
> quite fragile and subtile. Reording of the MD5 and SHA512 line would
> mean that old pkg_install will accept the package, but silently skip the
> content validation. That sounds to me like a good reason for not going
> down this road.

This has always been the case, the MD5 lines currently refer to the "current"
entry in the PLIST/+CONTENTS file, i.e. the one for which you've just had a
file system path. How would it ever get out of order? There are no human
users of pkg_create, only what is called from bsd.pkg.mk when making
the binary package itself. Your example is purely hypothetical, and will not
happen.