------------------------------
Message: 2
Date: Tue, 12 May 2009 13:40:56 +0200
From: Christoph Maser <c...@financial.com>
Subject: Re: [suggest] Re: suggest Digest, Vol 47, Issue 9
To: "suggest@lists.rpmforge.net" <suggest@lists.rpmforge.net>
Message-ID: <1242128456.4033.39.ca...@hub8071nc4.financial.com>
Content-Type: text/plain; charset="utf-8"
Am Dienstag, den 12.05.2009, 13:12 +0200 schrieb Nico Kadel-Garcia:
Fedora users might have excellent reasons to stay away from Fedora 11
until after it's released, and since Fedora 7 through 10 are still
active, they might appreciate an updated subversion in the RPMforge
repository. This is especailly because the new subversion 1.6.x has a
better security model (it does not store passwords in clear text
unless you explicitly give it permission, and that's a *MASSIVE* old
Subversion security issue).
Well you could backport the security fix to 1.4 for EL4. Anyway people
have been living with this one for ages i don't see any reason to cut of
my arm now to get 1.6. to compile on all platforms. Also you could file
a bug agains fedora 7-10 to have this one included. I don't see to many
fedora builds in rpmforge anyway.
It's usually easier to switch people over to using git (which I now
strongly prefer), or upgrade them to a more recent RHEL or Fedora, than
to do that extent of backporting. I've been there with Subversion,
writing the SCO OpenServer 5.0.6 port for Subversion. Backporting it is
pretty painful, due to the up to date toolchain needed to build it. I
still prefer git's well-managed SSH key integration, its speed, its
compactness, its support ofr actually deleting material, its superior
merging capability, and its handling of every checked out copy as its
own repository that you can merge or switch to as your central
repository. Subversion still wins in its familiarity, especially to
antique CVS users, its broader availability and its superior TortoiseSVN
client. (Tracking and decoding parallel branches in git is.... pretty
awkward for a long time until you wrap your brain around its displays.)
The fixes are a bit more sophisticated than that: they also provide
hooks into Gnome and KDE wallet applications to hold Subversion keys for
users, much like TortoiseSVN does in the Windows world. But in fact, I'm
someone who's been screaming about Subversion security for roughly 5
years: I'm glad they finally switched that model.
And 1.6.2 apparently allows 'svn:external'
to store individual files, which allows making tags with individual
tags that come from elsewhere for software releases. That makes it
much more usable for managing SRPM patch lists and source files, for
example.
Well sounds like a feature.
If you really want this to work well we certainly need python24 and a
newer neon packaged in a way not conflicting with base installations.
Also if you don't want to overload the spec with conditionals we would
need different spec files for different target OSes. Something rpmforge
does not do now.
I saw that yesterday building Subversion 1.6.2 under mock, darn it. I'll
try leaving out the 'autogen.sh' today: Rebuilding your autoconf related
toolchain every time you build a packages is theoretically a good idea,
but very dangerous to stable compilation trees on older platforms.
My personal focus is on el4 and el5 and my personal opinion is that
people needing this bleeding edge software should use fedora11 (in 14
days)
Chris
In general, yes. I thoroughly agree. RPMforge has been a wonderful
repository for just those little modern utilities being backported to
where I can use them in my production environments.
RHEL 4 has about reached the end of its usefulness to me, though. All
the backporting is getting painful.
_______________________________________________
suggest mailing list
suggest@lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/suggest
