Plague & CVS...

[Dan Williams]

On Wed, 2005-10-12 at 10:38 -0400, Chris Weyl wrote:
> However, while I have the buildsystem itself (mostly ;)) setup
> (server, builder, clients), I'm having trouble implementing the CVS
> integration.  It looks as if that half of the buildsystem hasn't been
> released yet?

The current CVS code is quite tailored for the Fedora Core/Extras CVS
repository setup.  Here you have a layout like this:

/cvsroot/plague/FC-3/
/cvsroot/plague/FC-4/
/cvsroot/plague/devel/

in other words, you have /<blah>/<package>/<target>/.  The CVS code is
set up to expect that right now.

Furthermore, once the path to the package is determined, there is a set
of commands to take the files in that directory above and make an SRPM
for them.  Mainly, we run the command 'make srpm' in the above directory
and hopefully we get an SRPM out the other end, which is fed to the
build slaves.

>   * what tags are generated when

They are generated by packagers, who must tag the files in CVS before
submitting a build.  The build always uses the CVS tag given by the
packager in the enqueue request.  The packager runs 'make tag' which
constructs a tag based on the RPM's NVR (name, version, release), then
runs 'make plague' which executes plague-client to enqueue the package.
If you forget to 'make tag' then the build will fail and you'll get a
nasty email.

>  * how the tags are generated and used

There's some magic in the 'common' directory's Makefile that extracts
the tag from the specfile based on NVR of the RPM.

>   * where the lookaside / cvs maintenance code all is

The lookaside cache of sources is essentially an HTTP server.  wget is
used to grab the files based on the 'sources' file in the packages
directory.  Most of the "real" code is in the common module for each
package.

>   * what license the lookaside / cvs / "common" module code is under,
> and if I can use it w/o impacting my project's packages licenses

I believe you can do so, though I'm not a lawyer.  The license of the
code in the Makefiles and such should not impact the license of your
source and/or product, since you do not link any of the
buildsystem/infrastructure code into your sources (hopefully).  If the
license of the infrastructure is under the GPL (which plague is) then
your obligation is simply to make changes to the infrastructure and
plague code available if you modify them.

> I'd like to be able to use the CVS integration; it would be a great
> boon to the reliability and usability of plague for my project.  Even
> if I just had a clearer understanding of how plague interacts with CVS
> & lookaside I could hopefully rig something...  But ideally the
> complementary code could just be used. Hopefully, I'm just pulling a
> "Monday" and all this is out there somewhere.

In all fairness, the general idea is to make more "pluggable" backends
for the RCS stuff, so that you could potentially add
subversion/git/arch/your-favorite-RCS-system-here support.  All that
plague _really_ needs out of the RCS backend is the path to an SRPM on
the local file system, and it doesn't care where it gets that SRPM path
from.

At a minimum, the inputs to the RCS backend would generally be target
specification (distro, repo, target) as well as the user-determined
'source' field.  This 'source' field can be anything; current Fedora
Extras uses it for CVS tags.  It's specified by the user when the
enqueue the package.  What the backend does with this information isn't
really a concern of plague as long as the path to the SRPM comes out the
other end.

So, if you've currently got a certain layout for CVS, I'd like to know
more to figure out how to generalize the current CVS code in plague.  In
the end you'll have to do a bit of tweaking to get your own CVS stuff to
work, if you choose not to adopt the infrastructure that Fedora CVS
uses.  But it shouldn't be very hard at all.  I just need a bit more
information first.

> Finally, but certainly not lastly, a major thank you to all who have
> worked on this and contributed time and code...  Plauge is excellent,
> and I can't wait to begin using it in "production".  :)

Glad it works, hope you're using 0.4/HEAD too :)

Dan