[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN install on Fedora Core?

From: Robert P. J. Day <rpjday_at_mindspring.com>
Date: 2004-03-23 12:42:19 CET

On Tue, 23 Mar 2004, Max Bowsher wrote:

> I have a few comments.
>
> Ranting at someone who volunteers their time and bandwidth to provide RPMs
> isn't very nice.

technically, i wasn't ranting at "someone", i was ranting at the technical
state of a previously-referenced repository, but i won't split hairs here.
 
> The confusion relating to APR versions is because the APR team have been
> intending to but never quite getting around to releasing a new APR for
> months. Leaving subversion in the unhappy state of requiring a version of
> APR never released indepenently from apache.
>
> The 0.9.5 RPMs are not 'junk' or 'bogus' or 'technically broken' simply for
> being 0.9.5, they are simply a best effort to handle a situation beyond the
> control of subversion.

that's not relevant. the most recent apr rpms that are considered
acceptable and for which you can expect support from the fedora core
folks are 0.9.4. anything beyond that is simply not recognized by
the FC people.

the fact that even the apache site itself lists 0.9.4 as the most recent
version of those rpms suggests *very* *strongly* that you shouldn't be
building *any* packages that require 0.9.5.

simply put, you can't claim to be putting out an FC1-compatible package if
it breaks official FC1 software. there's no way around that.
 
> I think it is a bit of a stretch to be calling rawhide "FC1-approved", given
> that the stated upgrade policy between RedHat/Fedora releases and rawhide is
> "there is no guarantee that there will *be* an upgrade pathway".

you are badly mistaken on a couple of counts. first, red hat's rawhide
repository *is*, in fact, FC1-approved since it corresponds precisely to
packages that should technically install/upgrade on an FC1 system and,
more to the point, the rawhide repository represents a preview of what
will be in future releases.

also, theoretically, FC will support upgrades from any official release to
any other release (official or beta). they most certainly *do* recognize
upgrades -- there's been considerable traffic on the FC lists on exactly
this topic.
 
> Then there are the db42 RPMs, which are an intelligent attempt to prevent
> people accidentally upgrading away their FC1-standard db4.1. Once again,
> rawhide does not mean "proper for FC1".

yes, it does. by definition, that's *exactly* what it means.
 
> And by the way, you are aware that the alternative repository you deem
> acceptable is intended for FC2 *not* FC1?

are you referring to the mirror.hiwaay.net repo i mentioned? as far as
i can tell, that mirror is perfectly acceptable for FC1 systems. you seem
to be confused by the purpose of rawhide-status rpms. those rpms
allegedly represent a preview of what's coming in FC2, but are also
acceptable for upgrading an FC1 system as well. i should know -- i've
been upgrading my FC1 system against rawhide on a regular basis with no
ill effects. upgrading FC1 systems against rawhide is not only
acceptable, it's encouraged if you want to help with the testing process
and get the latest/greatest releases.

by the way, your statement is transparently incorrect for another very
simple reason -- there *is* no FC2 release yet. at the moment, there is
only FC2-test1, for which these rpms should also be perfectly acceptable.

i apologize if folks took umbrage with the tone of my posting. but,
really, if you can't follow the rules for creating a repo that won't break
others' systems, you shouldn't be doing it.

rday

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 12:45:46 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.