Best way to sign packages before adding to the repos?

[Chris Weyl]

Ok, so after a brief pause to gather my thoughts....  ;)

On 11/18/05, Dan Williams <dcbw at redhat.com> wrote:
> On Fri, 2005-11-18 at 10:08 -0500, Chris Weyl wrote:
> > On 11/16/05, Dan Williams <dcbw at redhat.com> wrote:
> Hmm, it actually runs the scripts _after_ packages have been copied to
> the repository.  So maybe it's not exactly what you want.

Ahhh...  gotcha.  I thought they were being run exactly once after
each time a builder finished a given package...  My suggestions may be
slightly out of whack then :)

[...snip...]

> The problem here is that if packages are held until manually finished,
> then they are not available to builders.  So if I want to build package
> B that depends on a new package A, I have to wait for you to sign
> package A and add it to the repo before I can build package B.  That's
> the main reason to add packages to the repo ASAP, and also to run the
> repo scripts _after_ copying packages to the repodir and running
> createrepo.  It's also probably why Fedora Extras doesn't use the build
> server's repository but requires manual runs of a push-script to sign &
> copy to the "official" mirrored repo.
>
> It's a balance of package maintainer's needs (quick building of deps)
> versus administrator needs (making sure repos are up to date and
> signed).  Suggestions on how to better balance these two issues would be
> welcomed.
>
> In the longer term (plague 0.5) I'd like to put automatic depsolving
> into the build server, so that the server will wait like 8 hours for
> dependencies of a particular SRPM to be solved before failing the
> package.  If during those 8 or 12 hours, the deps get solved, then the
> build server will allow the package to be built.  This way, we let
> package maintainers queue up however many packages they want, and then
> walk away and not have to worry about stuff until they get mails about
> failures or successes.  That's the end goal here.  And it should solve
> your problem too, since it fixes the dependency issue that forces repo
> scripts to be run last.

Ok, so here's some revised thoughts :)  (And I like depsolving in the
buildserver...  would make life easier.)

I think my initial attempt to have one repo to serve both the
buildservers and the Masses is probably a bit optimistic.  Creating a
repo, with the cache option in createrepo, is a fairly low-impact
activity, so having 2 would help both manage what is released publicly
without compromising the buildservers' access to newly built rpms as
soon as possible.

So assuming I use 2 repos, one for the buildsys' own purposes and one
"public" one (with packages signed, blessed, etc, etc), is there a way
to leverage the needsign/finished push to
signal/initiate/queue/whatever that the package being finished needs
to be pushed into the public repo?  (Along with whatever attendant
steps need to happen concomitant with that push.)

Two ideas came to me on this:

1.  Create a "pushtopublic" stage, where the buildsys essentially
redoes "addtorepo" but with the public repos.  Hooks could be put in
place (a la #2) to permit signing, etc.
2.  Allow a script (along the lines of repo_script) to be specified
and executed against a particular package whenever it was "finish"ed. 
This script could take care of the copying, signing, and redoing the
public repo's metadata.  Or queuing the package for those steps to be
done by an external process.  Or...

I can see advantages and disadvantages to both.  If a new "pushtorepo"
stage is created, then we have the advantage of having everything
handled under the buildsys by default; and simply adding a trigger
script would allow for people to handle this differently, according to
their tastes/desires.

Anyways, just off the top of my head :)

                               -Chris