W dniu śro, 17.01.2018 o godzinie 12∶50 -0800, użytkownik Zac Medico napisał: > On 01/17/2018 07:42 AM, Alec Warner wrote: > > On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny <mgo...@gentoo.org > > <mailto:mgo...@gentoo.org>> wrote: > > > > W dniu wto, 16.01.2018 o godzinie 11∶32 -0800, użytkownik Zac Medico > > napisał: > > > On 01/16/2018 10:39 AM, Michał Górny wrote: > > > > W dniu wto, 16.01.2018 o godzinie 12∶44 -0500, użytkownik Alec > > Warner > > > > napisał: > > > > > On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny > > <mgo...@gentoo.org <mailto:mgo...@gentoo.org>> wrote: > > > > > > > > > > > Include a repo.postsync.d hook to verify the rsync checkout > > using > > > > > > gemato. Given that not all people will want to have it enabled > > > > > > unconditionally, no setup.py rules are included -- instead, > > the file > > > > > > would be installed conditionally by the ebuild. > > > > > > > > > > > > [v2: included link to the wiki page] > > > > > > --- > > > > > > MANIFEST.in | 2 +- > > > > > > misc/repo.postsync.d/00gemato | 18 ++++++++++++++++++ > > > > > > 2 files changed, 19 insertions(+), 1 deletion(-) > > > > > > create mode 100644 misc/repo.postsync.d/00gemato > > > > > > > > > > > > diff --git a/MANIFEST.in b/MANIFEST.in > > > > > > index 4f6cac162..edc6704e7 100644 > > > > > > --- a/MANIFEST.in > > > > > > +++ b/MANIFEST.in > > > > > > @@ -14,4 +14,4 @@ include cnf/make.conf.example.* > > > > > > include .portage_not_installed > > > > > > > > > > > > # extra scripts > > > > > > -include misc/* > > > > > > +graft misc > > > > > > diff --git a/misc/repo.postsync.d/00gemato > > b/misc/repo.postsync.d/00gemato > > > > > > new file mode 100644 > > > > > > index 000000000..f2af50925 > > > > > > --- /dev/null > > > > > > +++ b/misc/repo.postsync.d/00gemato > > > > > > @@ -0,0 +1,18 @@ > > > > > > +#!/bin/bash > > > > > > +# repo.postsync.d hook to verify ::gentoo checkout using gemato > > > > > > + > > > > > > +name=${1} > > > > > > +url=${2} > > > > > > +path=${3} > > > > > > + > > > > > > +# keyring installed by gentoo-keys > > > > > > > > +openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg > > > > > > > > > > > > > > > > This seems a bit leaky to me. > > > > > > > > > > Possible to get gentoo-keys to print it? > > > > > > > > > > e.g: > > > > > > > > > > openpgp_key=$(gentoo-keys --print-key-path) > > > > > > > > But app-crypt/gentoo-keys doesn't include that executable, and > > it has > > > > no dependency on app-crypt/gkeys. I'd rather not introduce an > > artificial > > > > dependency here. > > > > > > I suppose we could using a separate ebuild to install this hook, > > so that > > > we can update it separately from portage if necessary. The hook can > > > still live in the portage repository (like emerge-delta-webrsync which > > > is also installed by a separate ebuild). > > > > I don't see a strong reason to add yet another rebuild for a single file > > that is going to be updated really rarely. However, if we're going to do > > it that way, then there's no point in putting it in Portage repository. > > > > However, this 'update it separately from portage' reminds me of repoman > > that frequently gets seriously outdated and/or incompatible with Portage > > because of independent release cycle... > > > > > > I'll rephrase my objection. > > > > I don't care what you do as long as Zac (the person releasing portage) > > agrees with whatever > > requirements you need. If we need 3 releases in a row because the hook > > is buggy, as long as > > Zac is happy with that I'm happy with that. > > > > What I don't want to see is surprise when the hook is cut and suddenly > > its buggy and we need new > > cuts and Zac is not around, or HEAD is broken, or some other problem. > > > > Looking at the release history, multiple cuts in O(few) days is fairly > > common (11/20, 11/21, 12/10, 12/15) > > so this seems low risk to me; but AFAIK Zac is usually driving these > > changes himself so its a bit more obvious > > what is going on. Or just allow Michał to cut his own portage releases > > when he needs hook updates. > > > > -A > > The thing is, this pubring.gpg path tightly couples the hook to gentoo-keys. > I'd feel much more comfortable about including it with portage if we > used something like this command to query the pubring.gpg location: > > $ gkeys list-key -C gentoo -n snapshot >
I suppose I can live with that. However, gkeys are quite a heavy dependency compared to the keyring, with the latter being the only real requirement for gemato. That is, if that gkeys function works out of the box for non-root users because I recall gkeys having that problem. -- Best regards, Michał Górny
