[parted-devel] Re: Red Hat Parted Package

[David Cantrell]

Otavio Salvador wrote:
> I think would be nice if you could start to use our git repository for
> redhat packaging too. That would make our life easier to share changes
> between packages and fixes too.
> 
> Currently we have debian/master branch and after Etch goes out we'll
> end with debian/stable too. I think would be nice if you could create
> the redhat topic branches at redhat/* and tag the releases as redhat/*
> too.
> 
> Does anybody have any problem with this?

I have no problem sharing changes and making it easier for people to get 
at my changes, but I'm not sure if it would work well for me to use the 
git repository.

For those who are unfamiliar with RPM, the way we manage packages is to 
have a spec file with the build instructions, all of the patches against 
the released source, and a file containing the MD5 digest of the 
original source archive.  Right now, that looks like this for Fedora Core 6:

	Makefile
	branch
	mirrors
	parted-1.7.0-aix.patch
	parted-1.7.0-fat.c.patch
	parted-1.7.0-iseries.patch
	parted-1.7.0-sx8.patch
	parted-1.7.1-O_DIRECT.patch
	parted-1.7.1-apple_boot.patch
	parted-1.7.1-dasd.patch
	parted-1.7.1-dm.patch
	parted-1.7.1-get_exception.patch
	parted-1.7.1-gpt.patch
	parted-1.7.1-ped_geometry_read.patch
	parted-1.7.1-vtoc-errbuf.patch
	parted.spec
	sources

And for the active development tree ("rawhide") which is using parted 1.8.0:

	Makefile
	mirrors
	parted-1.8.0.tar.bz2.sig
	parted.spec
	sources

The mirrors, branch, and sources files are control files used by 
Makefile.  We have targets like "make build" or "make prep" which do 
various things with rpmbuild all the way up to tagging the tree and 
submitting a build to the build system.

Original sources are not stored in CVS.  We store the MD5 digest and 
keep the sources in a lookaside cache.  Original source archives are put 
in the source RPM files.

My understanding of Debian's packaging system is that everything is put 
in a debian/ subdirectory in the project source tree.  A single diff is 
generated which contains the contents of the debian/ subdirectory.  I 
find patches in this directory and other build control files.

So I see two paths I can take:

1) Rework my build of the parted packages so that I can keep them in a 
Debian-style framework in the parted git repository.  This generates 
more work for me with little return for me and possibly others.

2) Use a 'redhat' branch in the git repository (or whatever the 
appropriate vocabulary is) to duplicate the spec file and patch sets I 
have for the RHEL and Fedora RPMs.  I can include a basic Makefile or 
build script that would allow for generation of source and/or binary 
RPMs.  Again, this just makes more work for me but not nearly as much as 
#1 and might make it easier for others to get at the Red Hat parted patches.

Alternatively, I can publish patches for parted on my employee web page. 
  I think the goal is to expose any patches I have on the Red Hat side 
that have not made it in to the parted trunk.

How would people like me to approach this?  Publishing source RPMs 
converted to .tar.gz format is another option (makes it easier for 
people to get things).  The bottom line is I can't abandon the RH build 
system, so it's not a simple matter of moving the package version 
control stuff over to the parted git repository.

I'm open to ideas...

-- 
David Cantrell
Red Hat / Westford, MA