Gentoo Archives: gentoo-portage-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-portage-dev@l.g.o, Alec Warner <antarus@g.o>
Subject: Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification
Date: Wed, 17 Jan 2018 21:09:57
Message-Id: 1516223384.22898.1.camel@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH v2] misc: Distribute a repo.postsync.d hook to run gemato verification by Zac Medico
1 W dniu śro, 17.01.2018 o godzinie 12∶50 -0800, użytkownik Zac Medico
2 napisał:
3 > On 01/17/2018 07:42 AM, Alec Warner wrote:
4 > > On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny <mgorny@g.o
5 > > <mailto:mgorny@g.o>> wrote:
6 > >
7 > > W dniu wto, 16.01.2018 o godzinie 11∶32 -0800, użytkownik Zac Medico
8 > > napisał:
9 > > > On 01/16/2018 10:39 AM, Michał Górny wrote:
10 > > > > W dniu wto, 16.01.2018 o godzinie 12∶44 -0500, użytkownik Alec
11 > > Warner
12 > > > > napisał:
13 > > > > > On Tue, Jan 16, 2018 at 11:43 AM, Michał Górny
14 > > <mgorny@g.o <mailto:mgorny@g.o>> wrote:
15 > > > > >
16 > > > > > > Include a repo.postsync.d hook to verify the rsync checkout
17 > > using
18 > > > > > > gemato. Given that not all people will want to have it enabled
19 > > > > > > unconditionally, no setup.py rules are included -- instead,
20 > > the file
21 > > > > > > would be installed conditionally by the ebuild.
22 > > > > > >
23 > > > > > > [v2: included link to the wiki page]
24 > > > > > > ---
25 > > > > > > MANIFEST.in | 2 +-
26 > > > > > > misc/repo.postsync.d/00gemato | 18 ++++++++++++++++++
27 > > > > > > 2 files changed, 19 insertions(+), 1 deletion(-)
28 > > > > > > create mode 100644 misc/repo.postsync.d/00gemato
29 > > > > > >
30 > > > > > > diff --git a/MANIFEST.in b/MANIFEST.in
31 > > > > > > index 4f6cac162..edc6704e7 100644
32 > > > > > > --- a/MANIFEST.in
33 > > > > > > +++ b/MANIFEST.in
34 > > > > > > @@ -14,4 +14,4 @@ include cnf/make.conf.example.*
35 > > > > > > include .portage_not_installed
36 > > > > > >
37 > > > > > > # extra scripts
38 > > > > > > -include misc/*
39 > > > > > > +graft misc
40 > > > > > > diff --git a/misc/repo.postsync.d/00gemato
41 > > b/misc/repo.postsync.d/00gemato
42 > > > > > > new file mode 100644
43 > > > > > > index 000000000..f2af50925
44 > > > > > > --- /dev/null
45 > > > > > > +++ b/misc/repo.postsync.d/00gemato
46 > > > > > > @@ -0,0 +1,18 @@
47 > > > > > > +#!/bin/bash
48 > > > > > > +# repo.postsync.d hook to verify ::gentoo checkout using gemato
49 > > > > > > +
50 > > > > > > +name=${1}
51 > > > > > > +url=${2}
52 > > > > > > +path=${3}
53 > > > > > > +
54 > > > > > > +# keyring installed by gentoo-keys
55 > > > > > >
56 > > +openpgp_key=/var/lib/gentoo/gkeys/keyrings/gentoo/release/pubring.gpg
57 > > > > > >
58 > > > > >
59 > > > > > This seems a bit leaky to me.
60 > > > > >
61 > > > > > Possible to get gentoo-keys to print it?
62 > > > > >
63 > > > > > e.g:
64 > > > > >
65 > > > > > openpgp_key=$(gentoo-keys --print-key-path)
66 > > > >
67 > > > > But app-crypt/gentoo-keys doesn't include that executable, and
68 > > it has
69 > > > > no dependency on app-crypt/gkeys. I'd rather not introduce an
70 > > artificial
71 > > > > dependency here.
72 > > >
73 > > > I suppose we could using a separate ebuild to install this hook,
74 > > so that
75 > > > we can update it separately from portage if necessary. The hook can
76 > > > still live in the portage repository (like emerge-delta-webrsync which
77 > > > is also installed by a separate ebuild).
78 > >
79 > > I don't see a strong reason to add yet another rebuild for a single file
80 > > that is going to be updated really rarely. However, if we're going to do
81 > > it that way, then there's no point in putting it in Portage repository.
82 > >
83 > > However, this 'update it separately from portage' reminds me of repoman
84 > > that frequently gets seriously outdated and/or incompatible with Portage
85 > > because of independent release cycle...
86 > >
87 > >
88 > > I'll rephrase my objection.
89 > >
90 > > I don't care what you do as long as Zac (the person releasing portage)
91 > > agrees with whatever
92 > > requirements you need. If we need 3 releases in a row because the hook
93 > > is buggy, as long as
94 > > Zac is happy with that I'm happy with that.
95 > >
96 > > What I don't want to see is surprise when the hook is cut and suddenly
97 > > its buggy and we need new
98 > > cuts and Zac is not around, or HEAD is broken, or some other problem.
99 > >
100 > > Looking at the release history, multiple cuts in O(few) days is fairly
101 > > common (11/20, 11/21, 12/10, 12/15)
102 > > so this seems low risk to me; but AFAIK Zac is usually driving these
103 > > changes himself so its a bit more obvious
104 > > what is going on. Or just allow Michał to cut his own portage releases
105 > > when he needs hook updates.
106 > >
107 > > -A
108 >
109 > The thing is, this pubring.gpg path tightly couples the hook to gentoo-keys.
110 > I'd feel much more comfortable about including it with portage if we
111 > used something like this command to query the pubring.gpg location:
112 >
113 > $ gkeys list-key -C gentoo -n snapshot
114 >
115
116 I suppose I can live with that. However, gkeys are quite a heavy
117 dependency compared to the keyring, with the latter being the only real
118 requirement for gemato. That is, if that gkeys function works out
119 of the box for non-root users because I recall gkeys having that
120 problem.
121
122 --
123 Best regards,
124 Michał Górny

Replies