On Wed, Nov 2, 2011 at 7:05 AM, Stefan Sperling <stsp_at_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.
Received on 2011-11-03 02:09:49 CET