On Wed, Jan 17, 2018 at 10:25 AM, Michał Górny <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>
> 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
>
> --
> Best regards,
> Michał Górny
>
>
>
