Robert P. J. Day wrote:
> 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.
Yes, *preview*, or *in development*, or "if it breaks, you get to keep the
pieces". Not "approved".
> 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.
...and are willing to accept you are using beta software.
> 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.
That's just semantics. I know there is no FC2 release yet, but there is a
FC2-in-development, which is what the development directory of fedora
mirrors is matched to.
> 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.
I agree: The summersoft repo has a few problems.
I disagree: that it is so dangerous to people's systems that it should be
withdrawn until fixed.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 13:39:45 2004