2010/11/12 Thomas Backlund :
> Ric skrev 12.11.2010 21:46:
>> On 11/12/2010 01:24 PM, Thomas Backlund wrote:
>>> Per Øyvind Karlsen skrev 11.11.2010 23:03:
>>>> A better question would anyways be, why rpm.org?
>>>> I've yet to see any real answers to the question that anyone has been
>>>> remotely able to backup with anything at all..
>>> This is _way_ too easy :)
>>> How about something that actually works!
>>> Meaning the patched rpm.org we now have works pretty well,
>>> and the quirks it have is well known.
>>> Compare that to the mess that ended up in main/testing and
>>> you see the rpm-4.* is a way safer bet, atleast for now,
>>> and for those that tried the 4.8.1 that was a while in /testing,
>>> if they wanted, they could easily revert to the previous 4.6.1
>>> without trouble...
>> With all due respect ( a lot, :) ) that was a mistake. For whatever
>> reason URPM-4 did not made it into main/testing. BTHOOM why but it was
>> just an oops, a bad one considering the preview broke cooker systems but
>> still just a (forgivable) mistake.
> I'm not that forgiving for a core package :)
> If rpm5 was that dependent of URPM-4, it should have had a strict
> added to it.
It does, but as build system is slow, perl-URPM hadn't hit the mirrors yet
> And another point is it got pushed to the mirrors without even a
> _before_ if we should use rpm5 or not, so Eugeni had to
> start this thrad after the fact.
And how do you know that? Eugeni was actually the first person who
tried submitting the package to me, what started this thread was
people who recklessly updated packages from testing, which again lead
to breakages as things weren't ready, thus resulting in this FUD
thread where people are making up a lot of claims which they have *NO*
insight on beyond assumptions and "what they've heard".
> And main/testing is for packages going to main/release wich there
> is no official decision regarding rpm5, so it does not really
> belong there...
I've made it clear several times that I've planned on going with
rpm5, and given that I'm the maintainer, have the best knowledge of
and this change really should't affect people in a negative way if
you look beyod the reckless updating from testing. As I am the one to
maintain it, and it shouldn't have inconvencies pushed on others, I
find it my own decission to make whether I want to maintain a totally
messed up rpm.org version which is bogged down with patches and pain
to regenerate for every release.
In addition we have the obsolete and unmaintained perl-RPM4 package
that needs to be ported with a lot of hazzle for every new release,
whit nanor's rewrite already
being part of upstream already.
Then in addition I have to keep on porting things to APIs I'm not
familiar with, working on pretty much dead code that never makes their
Whoever maintains rpm and is fit for the job should be the one
maintain rpm, anything else becomes highly subjective and filled with
nonsense people don't really know or undestand.
If you're willing to discuss it on any actual tecnical merrits and
have any arguments beyond "it broke for me, it sucks, SCREW RPM", then
> And last but not least, there should atleast have been a "heads up" / RFT
> warning posted on cooker before submitting it to the mirrors...
I gave several heads up on plans to do so, but I refuse to give
headups about stuff I'm not confident being done with, and that's
something I won't, if you're bent on having testing enabled by
default, fine, that's your prolem. But there' a reason for it being
*explicitly* ignored to prevent such accidents to happen.