Re: Subversion 1.7.1 SRPM building tools and utilities

[Stefan Sperling <st...@elego.de>]

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?

Re: Subversion 1.7.1 SRPM building tools and utilities

[Stefan Sperling <st...@elego.de>]

On Thu, Nov 03, 2011 at 12:06:51PM +0200, Daniel Shahaf wrote:
> On Wednesday, November 02, 2011 9:09 PM, "Nico Kadel-Garcia" <nk...@gmail.com> wrote:
> > 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.
> > 
> 
> If they're broken (and I agree that overwriting dotfiles constitutes a
> bug), and if no one uses them, then yes we could delete them.  (Though
> perhaps someone will apply your patch before then.)

I would prefer to delete them and put a README into the directory
that points at the new home of Nico's package, wherever it will end
up being. I don't think our repository is a good home for it, because
other packages don't live here anymore either.

Re: Subversion 1.7.1 SRPM building tools and utilities

[Daniel Shahaf <d....@daniel.shahaf.name>]

On Wednesday, November 02, 2011 9:09 PM, "Nico Kadel-Garcia" <nk...@gmail.com> wrote:
> On Wed, Nov 2, 2011 at 7:05 AM, Stefan Sperling <st...@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.
> >
...
> > 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.
> 

dev@svn is not a pastebin :P

> 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.
> 

If they're broken (and I agree that overwriting dotfiles constitutes a
bug), and if no one uses them, then yes we could delete them.  (Though
perhaps someone will apply your patch before then.)

Re: Subversion 1.7.1 SRPM building tools and utilities

[Nico Kadel-Garcia <nk...@gmail.com>]

On Wed, Nov 2, 2011 at 7:05 AM, Stefan Sperling <st...@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.