RFC: Exploded source repo layouts

[Doug Ledford]

I've been working on getting this set up and functional.  The first
thing that pops up as an issue is the fact that when dealing with
exploded source repos, you really want the topdir to be the same as
upstream.  That means that given a normal upstream source layout, the
topdir is the same as the traditional RPM_BUILD_DIR.

This promotes the most seamless integration with upstream, and the
greatest ability to share things with upstream.  It does, however,
present problems for our custom make targets.  So, what I've been
working with is a sort of home grown standard.  Obviously, no one to
date has really been trying to handle things the way I'm doing now, or
at least no one has attempted to even try and standardize it.  We have
had our dist-cvs setup, and other distros have had their internal
setups, and the pkg-vcs people have been talking about other similar
systems to our dist system.  What people haven't been talking about is
exploded source repos where the primary look and feel of the repo is
just like a bare upstream repo, and where our distro specific stuff is
an add-on to that upstream repo.  That's what I'm aiming for.

Here's how I've been doing it so far.

First, we have to do away with a bunch of our make targets because they
are too commonly named and might conflict with legitimate upstream make
targets (well, more like some of them might conflict, some of them
*definitely* conflict).  This is important because our Makefile.common
is included in upstream's toplevel Makefile.

Second, upstream probably doesn't want to deal with trying to
accommodate Fedora, Unbuntu, Gentoo, etc., so we need a simple way that
upstream can accommodate us without putting a bunch of stress on them.
My method for dealing with that is that everything Fedora specific (and
specific to any other distro) goes into $topdir/distropkg.  That's where
you'll find a simple Makefile that includes our Makefile.common, that's
where our spec file goes, that's where any custom source files go, and
embedded in that simple distropkg/Makefile are any custom install or
make targets that we need for this specific package (there is an example
of this in the mdadm/distropkg/Makefile from the git repo below).

The standard, as far as upstream is concerned, is this: everything
distro specific goes into distropkg and the top level Makefile should
include distropkg/Makefile if it exists (or alternatively, upstream can
provide their own empty distropkg/Makefile and include it
unconditionally in the toplevel Makefile if they want to save the
overhead of testing for the distropkg/Makefile).

As far as we are concerned, we make the majority of our custom changes,
the stuff that we don't expect upstream to ever take because it simply
is our goo that we use when building packages, in the distropkg
directory and Makefile.  Anything that upstream should take, get's done
in the main source code repository and pushed upstream (with a git repo
that's really easy...make the patch, commit, cherry pick to a
for-upstream branch, email upstream about changesets, done).

As far as Ubuntu, debian, others are concerned, they do the same thing.
We each use distropkg to our own ends, and changes in that area are
things we keep local and never send upstream.

If people would like to see some examples of what I'm talking about, you
can clone the following:

git://fedorapeople.org/~dledford/mdadm.git
git://fedorapeople.org/~dledford/common.git

and see what things look like so far.

Note: this is not yet a functional, building setup.  For starters, I
still need to add some custom headers to rpm (and add an rpm repo to the
list above to other people can test with the modified rpm).  Then I need
to make a modified koji so I can build this into a build system.  The
above packages give a decent idea of what the repos would look like, and
some of the make targets actually work (like the make tarball target).
It's mainly there for people to take a look at things like the spec file
and the filesystem layout and to provide feedback based upon what they
see before things are so far along that it's hard to change anything.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080722/ee01d925/attachment.sig>