buildsystem stuff

[seth vidal]

> I've got two questions :
> - Have your last tobuild tests worked alright? Is this ready to use?
the last 30 or so packages have built correctly. I've seen a couple of
deadlocks on *something* when doing cvs co of the tag and I think I just
need a simple timer on the popen call to watch for hung things. I
already have a timer on the build calls.


> - How do the resulting packages show up in the Extras tree?

There's another script I run when I sign the packages that moves things
around. The signing script HAS to be done by _someone_ b/c, well, they
have to sign them.


> That second point is the most important, I guess, as we might want to
> review binary packages after they're built "just in case". 

Adding a stage like 'NEEDSQA' wouldn't be very hard. It would just mean
moving a package that successfully built from 'active' into a different
dir and notifying the right places of the event.

> Next, the signing stage should probably stay "manual", eventually when that review
> occurs, and just before the packages go out to the public tree? Last, how
> do the old packages get cleaned out?

Well, I've been using repomanage.py -o /path/to/repo | xargs rm -f, But
I know that Notting wants to use something that keeps around older
versions for about 28 days before deleting them. So, in short, that does
it.


> For this last question, here's the solution I've been using myself for
> years : I have my main tree (it could be a private one in this case) which
> is organized as "<distro version dir>/<package name dir>/" in which I
> remove all files in "<package name dir>" when a new package of "package
> name" is built, then I add all the new files. I then run a mass clean-out,
> followed by hard-linking of all those sub-dirs in the repository-enabled
> tree. This makes me avoid complicated version comparisons and such, and
> takes care of the corner cases such as when the new packages no longer
> include a given sub-package.

Take a look at how 'repomanage' works. The only difficulty is, of
course, that sometimes you don't want the newest package to be the
'released' package.

I thought of adding two flags to createrepo to make this stuff simpler:
  --includefrom and --excludefrom. They would each take a list of rpms.
So you could run repomanage -n /path/to/repo > includefile. Then pass
that to createrepo and it would only index the packages in the
includefile and only include those in the repository. Then you wouldn't
have to remove anything but you'd only be showing the newest versions to
the world.

If you've not seen repomanage go to:
 http://linux.duke.edu/yum/download/misc/

I'm certain that will also be available in the yum-utils package that
Gijs has been working on. Lots of completely cool stuff in yum-utils
now.

-sv