Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/

[Jason Zaman]

On Wed, Feb 10, 2016 at 05:11:20AM +0000, Robin H. Johnson wrote:
> On Wed, Feb 10, 2016 at 01:24:16AM +0000, Robin H. Johnson wrote:
> > I will happily take a pre-receive hook, regardless of it using
> > pkgcore/portage. Note that it should operate WITHOUT having a checkout,
> > needs to be able to take new ebuilds & Manifest on stdin.
> >
> > Trying to checkout the tree for each update I don't think is a good
> > idea, as it's 5+ seconds of overhead; and somebody else could try to
> > push a change in the meantime.
> Slight clarification here:
> I am willing to keep a stateful checkout as a post-receive hook, and the
> pre-receive hook CAN use that checkout to read other contents. It just
> might be more than one commit behind sometimes.
>
> Eg:
> T=1 push P1 comes in, triggers pre-receive, passes, triggers post-receive hook (async)
> T=1..5 working tree in the process of post-receive, state is dirty [1]
> T=2 push P2 comes in, triggers pre-receive. What should happen?
>
> What should the pre-receive do in this case?
> A) fail outright? (terrible choice, included for completeness)
> B) block on the active post-receive completing? (while !done; sleep)
> C) validate against a changing tree? (might fail, not in a way that's
> easy to reproduce)
> D) validate against a previous CLEAN tree? (if this push depends on a
> change in push P1, it will fail when it should have passed)
>
> [1] actually a really good question here, does git prepare changes
> somewhere in .git and atomically rename into place, even so, multiple
> moves cannot be atomic together.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
> E-Mail     : robbat2@g.o
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>

We do not need the whole manifest checking, we just need to have a list
of SRC_URI that is being added in any ebuilds and then grep Manifest if
those filenames exist. The receive hook checking the hashes of the files
is probably asking too much. This would miss any files added by eclasses
but that is rare and changes less often so we should probably be okay.

Is there any sane way to spit out condensed SRC_URI for all use-flags?

-- Jason