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...

-- 
Best regards,
Michał Górny


Reply via email to