On Wed, Nov 2, 2011 at 7:05 AM, Stefan Sperling <s...@elego.de> wrote: > On Sun, Oct 30, 2011 at 04:45:51PM -0400, Nico Kadel-Garcia wrote: >> [ Accidentally sent this to old dev address, resending ] >> >> The attached patch is a pretty thorough rewrite of the SRPM building >> utilities, and spec files, for Subversion-1.7.1. It includes a number >> of components: > > Thanks for sending this. > > I asked you to send this patch, but now recall a past conversation > about whether it makes sense to maintain this package in the upstream > Subversion repository. > > Packages used to be maintained in the upstream repository before > distributions started shipping Subversion by default. Nowadays, > most packages are independently version-controlled by maintainers. > For instance, I help out with the SUSE and the OpenBSD packages, > which are maintained at opensuse.org and openbsd.org, respectively. > > To avoid confusion it is best to have one canonical place for people > to get the package sources from. > > Is there a dire need to have this in our repository or are you sending > it as an update to the old, unmaintained, package that is still rotting > in our tree (and should probably be deleted)? > > Would it make more sense to version your package at rpmforge?
I'm trying to get it in at RPMforge, I've submitted packages successfully there before. The problem is that I don't personally have a reliable a public FTP site to post the bulky diffs in, and the complete rewrite of the .spec file is kind of bulky to submit via email, and I'm not hearing a lot back from that repository. I've already submitted it to Fedora. Publishing it to the dev mailing list gave me a good place to submit it so the RPMforge maintainers can get at it. My big concern with what's in the Subversion source tree is that the the existing RPM building structure is dangerous. It overwrites the builder's $HOME/.rpmmacros file. And it leaves multiple, unusable ".spec" files scattered in the repository. The new structure has *one* file, a .spec.in file, that gets tweaked and clean SRPM built locally, without overwriting .rpmmacro. Building from SRPM is left as an exercise for the builder: I personally use "mock" in order to build clean RPM's without having to mess up my development enviornment, and to make sure that I haven't left out dependencies. As it stands, simply deleting the existing rhel-3, rhel-4, and rlel-5 legacy building bundles and leaving a pointer to the archive patch would probably be enough to allow others to use it as necessary.
