+++ This bug was initially created as a clone of Bug #562645 +++ Please consider by the next openoffice update to compile against more actual versions of redland /raptor /rasqal - a number of other programs need newer versions of these librarys for full functionality. Is it possible to change the openoffice dependency to equal or greater than, rather fixing one version only? A positive response would be welcome, Simon +++ --------------------------- +++ Multimedia applications such as qtractor are tripping over librdf... The error message comes from when starting the application: Warning: Unable to create "trees" RDF storage. Performance can be improved by upgrading librdf. This message appears to come from redland sources... --- Additional comment from oget.fedora on 2010-02-13 23:25:26 EST --- This is not as easy as it sounds. openoffice.org depends on these packages and a rebuild of these libraries will require a rebuild of openoffice.org (among with other packages). Certain fellows with slow connections get mad when there are such minor updates in huge packages. If you can convince the openoffice.org maintainers for a rebuild then we might consider the update. Otherwise, these updates will be part of F-13 and above
If the new packages are not abi-compatible with the old one, then its really not a good idea to force a rebuild of the entire stack of consumers of those packages in an already released Fedora. Seeing as this issue was opened against OOo, I have to assume that they must be abi-incompatible if it needs a rebuild of OOo (among others) in F-12. That doesn't sound like it could fly at all. F-12 should be "done" modulo bugfixes and security errata not a free for all "work in progress".
Don't we have a deltarpm facility just for such purposes? An openoffice.org update should not take a big download anymore.
It's not really about the size. It's about stability and changing the ABI of libraries and forcing a rebuild of otherwise perfectly stable packages doesn't make sense for an already released stable "product". Where would it stop, rebases of random libraries to their most recent release whenever they are available, constant rebuild and churn. That's what our development branch is for. Why have "releases" of fedora at all otherwise. I've no problems with the concept of a distro where everything is in flux all the time, but that's not the model we're currently following.
Although I respect your philosophy, I do not agree with it. For example, the KDE team is doing a terrific job in maintaining the most recent versions in stable releases. Their ABIs change constantly. So what... they just rebuild. Clearly the current stack is not stable for some users (hence this bug report). Telling them to wait 1 to 6 months does not fit my logic. Anyway, that's just my opinion.
Soname bumps are definitely allowed in Fedora if it's not the whole world depending on it. That's what buildroot overrides and grouped updates are for. In our case, only rasqal bumped its soname (from librasqal.so.0 to librasqal.so.2, it looks like we get to skip one soname bump) and the only packages depending on librasqal.so.0 are: openoffice.org-core-1:3.1.1-19.14.fc12.i686 slv2-0:0.6.6-2.fc12.i686 sonic-visualiser-0:1.7.1-1.fc12.i686 rasqal-0:0.9.15-6.fc12.i686 rasqal-devel-0:0.9.15-6.fc12.i686 redland-0:1.0.7-10.fc12.1.i686 This is very much manageable by a grouped update, in fact it'd be a group of just 5 packages (at SRPM level) to update, one of which is rasqal itself. As one of the comaintainers of rasqal, I really want to do this update at least for F12. But I'd also like to avoid pushing an OO.o update with only the librasqal rebuild and no other fixes. If we can bundle it with some OO.o bugfixes, that'll be nicer to our users.
(Well, technically, I'm not officially a comaintainer of rasqal because the primary maintainer never bothered approving my ACL requests, but the agreement is that we comaintain the whole Redland stack, and the primary maintainer hasn't touched it at all in recent times.)
> Their ABIs change constantly. So what... they just rebuild. Not all our ABIs change, just some (like the kipi stack in kdegraphics), but right, we do rebuild a handful packages for those updates. We had to rebuild 11 packages (one of which was kdebindings for which we did this update) for our SIP 4.10 update required for KDE 4.4 (and we did other SIP updates in the past). Sure, none of these was as large as OO.o. But I think the OO.o rebuild would be worth it here, F12 still has a long time to live (approx. 10 months), our versions of the Redland stack are known to be suboptimal (there are also bugs which are fixed in the current version) and we'd be stuck with old versions for those whole 10 months, whereas accepting that one soname bump might allow us to resume regular Redland updates.
If the abi changes, I'd have to rebuild of course. But for the record I think its the totally wrong thing to do to change abis in released fedoras.
I am trying to backport redland's 'trees' storage to 1.0.7. That appears to be easy enough up to svn r14575. But in the meantime it seems sqlite API has changed and now the 'sqlite' store doesn't build cleanly anymore: http://bugs.librdf.org/mantis/view.php?id=315 The patch offered there can be applied well to 1.0.7, but compilation still fails. If someone can and wants to help please drop me a line.
I have finished the backport. lv2_inspect goes like a breeze now :-D. I have launched ooo and fooled around a bit with no ill effects, but I guess some test suite should be applied to be more sure. I just plugged the 'trees' stuff into the source tree and sedded s/SQLITE_API/REDLAND_SQLITE_API/g as per http://svn.librdf.org/view?view=rev&revision=15404 Since I made changes to the autotools config files I had to rebuild all the autotools stuff (autogen.sh), so a patch would be too bloated. If someone wants the SRPM just howl.
We could just run autoreconf in the RPM. But please do attach or upload your SRPM somewhere, or just e-mail it to me.
Created attachment 399969 [details] Redland 1.0.7 with 'trees' storage backport and SQLITE_API fix
If you want to keep the old autoconf stuff, autoreconf in the spec and make a patch the files I had to modify are, IIRC: configure.ac librdf/Makefile.am librdf/rdf_storage_internal.h librdf/rdf_storage_sqlite.c librdf/win32_rdf_config.h And I added: librdf/rdf_avltree.c librdf/rdf_avltree_internal.h librdf/rdf_storage_trees.c
Created attachment 400024 [details] Patch against sources included in redland-1.0.7-6.fc11.src.rpm. Requires autoreconf.
*** Bug 579439 has been marked as a duplicate of this bug. ***
*** Bug 591841 has been marked as a duplicate of this bug. ***
caolan, we've got a kde update in the works, anything ooo-related landing soon that we can consider coordinating a redland update to go with it?
oh heck, maybe we can also try out the patched redland from comment #14 (and earlier), which may be good enough.