PDR -- Package development repostory to replace SRPM's? (fwd)

[Chris Ricker]

Jeff posted this to rpm-list, but it seems of interest to many on here who 
might not be on the rpm list....

later,
chris

---------- Forwarded message ----------
Date: Wed, 01 Oct 2003 15:59:56 -0400
From: Jeff Johnson <n3npq(a)nc.rr.com&gt;
Reply-To: rpm-list(a)redhat.com
To: rpm-list(a)redhat.com
Subject: PDR -- Package development repostory to replace SRPM's?

In the interest of looking seriously at build dependency
loops involved in bootsrapping a distro, I've set up a
publci CVS repository for exploded severn2 *.src.rpm's at

    :pserver:[e-mail]:/home/cvs

The following commands should get anyone who is interested
in using the public package development repository started:

	$ cd /var/tmp
	$ cvs -d :pserver:[e-mail]:/home/cvs login
	Logging in to :pserver:[e-mail]:2401/home/cvs
	CVS password:
	$ cvs -d :pserver:[e-mail]:/home/cvs get severn2/severn2
	U severn2/severn2

The entire repository was set up with the severn2 script checked out
above in approximately one hour, not hard at all.

Note: The cvs.colug.net repository is ~2GB in size. *Please* make sure
you have the bandwidth and diskspace (and attention span ;-) to
handle that large a checkout before attempting the entire repository.

I expect to have cvsweb set up in the next day or so. See the severn
repository at
     http://cvs.fedora.us
for what will be at cvs.colug.net soonish.

The severn2 script (aka "mkrpm") is a toy, but was quite fun to write.
Invoke the script with no arguments for a usage message. You will need
to edit the script to reflect the location of your local checkout.
Please note that the script is merely a prototyping toy, and
will probably be discarded in favor of better tools soon.

My goal with mkrpm is to try and establish conventions
for file organization, a vendor branch, and tag structure
for a package repository. If the conventions can be
established, then it will become possible to attempt
distro level build systems and to teach rpmbuild some
new tricks.

Another reason for exploding *.src.rpm's into a repository
is that I believe that src.rpm's are not the most effective
means for distributing software.  

Don't misunderstand me, src.rpm's make very good bricks, and src.rpm
bricks usually come with the implicit rpm guarantee that the src.rpm
was produced by taking virgin sources, applying patches, and running
a spec file through rpmbuild from soup to nuts. That is a very sensible
guarantee for a brick.

However, src.rpm bricks, just like *.tar.gz, hide the internals. Say
a package has been rebuilt, and the Release: tag has been incremented
to reflect the change.  There is no way to discover that nothing else
of interest has changed in the src.rpm without downloading the entire
brick. Brick's are bandwidth heavy.

Another problem with src.rpm's is that they do not mirror well with rsync.
Since the file name changes with each new brick produced, rsync usually
lacks the proper end point references to attempt deltafication, so
mirroring src.rpm's with rsync often has no bandwidth savings at all.

Yet another problem with src.rpm's is that it is difficult to
merge patches together from independent lines of development.
Well, it's not difiicult, just more tedious than necessary. ;-)

In order to address the lack of patch coherency from independent
development efforts, I've also set up a cvsup (yes, modula3) mechanism
for mirroring repositories.

There are cvsup packages at http://fedora.us if you are interested.
I've also added cvsup to the severn2 repository so you should
be able to build your own cvsup packages (assuming that your
machine is set up to build packages) by doing:

	$ cd /var/tmp
	$ cvs -d :pserver:[e-mail]:/home/cvs login
	Logging in to :pserver:[e-mail]:2401/home/cvs
	CVS password:
	$ cvs -d :pserver:[e-mail]:/home/cvs get severn2/severn2
	U severn2/severn2
	$ cvs -d :pserver:[e-mail]:/home/cvs get severn2/cvsup
	cvs server: Updating severn2/cvsup
	U severn2/cvsup/cvsup-contrib.patch
	U severn2/cvsup/cvsup-snap-16.1h.tar.gz
	U severn2/cvsup/cvsup.spec
	U severn2/cvsup/cvsupd.conf
	U severn2/cvsup/cvsupd.logrotate
	U severn2/cvsup/cvsupd.rc
	U severn2/cvsup/ezm3-1.1-LINUXLIBC6-boot.tar.bz2
	U severn2/cvsup/ezm3-1.1-src.tar.bz2
	$ cd /var/tmp/severn2/cvsup
	$ ../severn2 topdir=/var/tmp/severn2 build >& x
	$ ls *.rpm
	cvsup-16.1-1.i386.rpm          cvsupd-16.1-1.i386.rpm
	cvsup-16.1-1.src.rpm           cvsup-debuginfo-16.1-1.i386.rpm
	cvsup-contrib-16.1-1.i386.rpm
and then install cvsup from those packages.

To use cvsup to mirror the "testing" collection, put the following in
/var/tmp/testing.sup:
	*default host=cvs.colug.net
	*default base=/var/tmp/ncvs
	*default release=severn2
	testing
and invoke as
	$ mkdir /var/tmp/cvscolog
	$ cvsup -g testing.sup
	Connected to cvs.colug.net
	Updating collection testing/severn2
	 Mkdir time
	 Create time/time-1.7.tar.gz,v
	 Create time/time.spec,v
	 SetAttrs time
	Finished successfully
to get your own "testing" subset of the cvs.colog.net repository.

The cvscolog repository mirror can then be used (including check-in's)
locally just like any local cvs repository, for example,
	cvs -d /var/tmp/cvscolog get severn2/time
etc etc.

At the moment there are only 2 collections:
	testing		as above
	all		everything

I'll be happy to add other reasonable collections and am looking
for suggestions.

Enjoy!

73 de Jeff