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
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
