Red Hat Bugzilla – Bug 591841
Please, please, please update Redland > 1.0.8
Last modified: 2010-05-13 14:23:52 EDT
Created attachment 413712 [details]
build error for redlandmm - needed for ingen
This is impossible - every actual audio app I want to use needs redland 1.0.8
It is time that KDE and openoffice are updated to 4.4.4 and 3.1.2 respectively on Fedora 12.
It will be 6 months after the launch of Fedora 13 before a stable real-time kernel will be available.
This is a totally, totally unacceptable situation.....
It is out of our hands. I am assigning this to openoffice.org folks, since they are responsible for this regression.
Meanwhile you can always install new redland manually.
How on earth is it a "regression" to not change versions. A new redland requires mass rebuilds in F-12. My stance is that its an incredibly bad idea to mess around with a stable release and bump to an incompatible version. That's hardly an unreasonable stance. Why have releases of Fedora at all if past releases are rolling collections of always the latest packages. There's nothing inherently wrong with that view, but we do have Fedora releases so that's not the model we're following.
*** This bug has been marked as a duplicate of bug 565329 ***
"Not changing versions" prevents us from packaging some important pro audio software in Fedora 12, and because of this we are falling behind many other distributions. It is most certainly a regression. No question about it.
What is sad is, the openoffice.org people don't care about it. Is this the way the collaboration between different SIGs supposed to work in Fedora? :(
And no, these are not very recent bleeding edge software. They have been around for a while but since the redland did not get updated forever, we couldn't package them.
A regression is a change that breaks existing functionality. Its not a regression to be unable to add extra functionality like a new package. I'm against bumping major versions of a library in a released product precisely to avoid any regressions. I'm not forcing anyone to not bump it. If the maintainer wants to do that, they he can, it's his call, but I advise strongly against doing it.
Technically someone could make -compat packages or -new ones or whatever for F-12 and get new and old redlands installed in parallel, though that's not also without its own dangers when something ends up linking indirectly to two different versions of a library.
A regression is "the act of going back to a previous place or state; return or reversion." Since we are staying at the old version, we are lagging behind the other distros.
Yes, it is not the best choice of a word to represent our state, because we never took the step forward. Sorry for misuse.
Anyway, I don't see the point of repeating our arguments. We are simply stuck here. I hope history doesn't repeat itself.
Given the current situation, I think the best course of action is to update Redland on F12 and rebuild all dependencies. There are not many, and OO.o is the only large one. Orcan, if you want to do that, you have my go ahead. But please make sure you really rebuild all dependencies and push a grouped update, otherwise we will have dependency breakage.
In my opinion, with the current planetccrma rt-kernel, fedora 12 is the most robust and stable pro audio distribution, but unless we can have a new redland verions it is also a dead distribution for pro audio work.
I don't want to make an update without their (openoffice.org folks') approval. No need to grow hostility.
There are other redland maintainers. They might think different from me.
Apologies Orcan, I consider you to be one of the good guys and I know you certainly do your best to champion the pro audio apps on Fedora / Planetccrma.
I admit I was venting my frustration at Fedora (by Fedora I mean the complete organisaion not meaning to target individuals), every time I would like to try out a new app on Fedora 12 I hit the redland brickwall...
The real fault is redland of course, they should either have made their api backwards compatible or given the redland product with the new api a new name.
As it is, it is not possible to have have both the 1.0.7 and the 1.0.8 versions on the same installation.
Crazy, but there you are...
I think upgrading is really the best option here, this is preventing even building several apps (at least their current versions) and others are slow.