Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
On Tuesday 18 March 2008, Enrico Weigelt wrote: BTW: if libexpat.so.0 was there before the update and now isn't, there's an major bug in expat (either the ebuild or the source). There's no bug in expat, the OP is doing an *expat*upgrade*, which means that libexpat.so.0 was there before and libexpat.so.1 is there now. Thus any app that links explicitly to libexpat.so.0 is now broken. A source based distro like Gentoo runs this risk with every library upgrade and sometimes it hits a low level lib with deep dependencies like expat. There are only two possible solutions to this: 1. Track the links between every app and every lib, and as soon as one is detected with a lib upgrade then fire an event to trigger a recompile of the linking app. This solution is so ugly, so error-prone that I cannot suffer it to live. 2. Something like revdep-rebuild that scans the system looking for errors and is triggered manually by the user. Getting through these upgrades is a serious PITA. But at least on Gentoo we can fix it. Imagine using a binary distro where the packager didn't pick this up and you are left stranded with no easy way to fix it... -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
* Alan McKinnon [EMAIL PROTECTED] wrote: On Tuesday 18 March 2008, Enrico Weigelt wrote: BTW: if libexpat.so.0 was there before the update and now isn't, there's an major bug in expat (either the ebuild or the source). There's no bug in expat, the OP is doing an *expat*upgrade*, which means that libexpat.so.0 was there before and libexpat.so.1 is there now. Thus any app that links explicitly to libexpat.so.0 is now broken. If an upgrade breaks primary things, it's simply broken. You can now choose, whether the bug is expat or the ebuild/portage. 2. Something like revdep-rebuild that scans the system looking for errors and is triggered manually by the user. This is also ugly and error-prone. After every slightest upgrade you have to fear nothing's running anymore and everything has to be rebuilt first. If downtimes don't matter, fine. But for critical systems, this is very dangerous. Why not modeling/storing the *runtime* dependencies and doing an *clean* MVCC ? Isn't this what slotting was meant for ? ;-P Imagine using a binary distro where the packager didn't pick this up and you are left stranded with no easy way to fix it... Then the package manager's obviously broken ... cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
Ok, you all can stop ranting about ebuilds etc. being broken. :) I found the culprit, it seems something wrong in the kdelibs building. Basically, when kdelibs builds dcopidl, it happily *says* oh, this would need libXft, that in turn has a broken link to libexpat.so.0. But who cares, let's go along with it! instead of stopping and telling me that libXft is broken. I have no more the relevant compilation output snippet, but that's the meaning. So, I just emerged libXft, fixing the expat link, and everything went pretty smooth. Now I have the problem that Thunderbird starts, but no window comes out, but it's a different stuff... m. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
* brullo nulla [EMAIL PROTECTED] wrote: So I equeried dcopidl, and dcopidl belongs to kdelibs itself! What does it mean? Simple: KDE folks still aren't confident with the concept of modularity (even it's an standard pattern since about 50 years) ;-P BTW: if libexpat.so.0 was there before the update and now isn't, there's an major bug in expat (either the ebuild or the source). I don't know if the Gentoo QM policies say that those bugs have to be fixed or relying on the revdep-rebuild workaround is enough. In the first case, you should file a bug. Otherwise could leave it out to save yourself from personal rants ;-o cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
On Mon, 2008-03-17 at 19:29 +0100, brullo nulla wrote: What output do you get from 'revdep-rebuild -p -i' ? Here it is: Evaluating package order... Warning: Failed to resolve package order. Will merge in random order! Possible reasons: - An ebuild is no longer in the portage tree. - An ebuild is masked, use /etc/portage/packages.keyword and/or /etc/portage/package.unmask to unmask it . done. (/root/.revdep-rebuild.5_order) emerge =gentoolkit-0.2.4_rc3 and see what revdep-rebuild gives with that version. Unfortunately, the --package-names in gentoolkit-0.2.3 doesn't work correctly, which causes problems with rebuilding after the expat upgrade. Regards, Paul -- gentoo-user@lists.gentoo.org mailing list
[gentoo-user] expat upgrade, kdelibs: circular problem?
Hi folks, I am finally getting through the expat update. I am currently stuck at kdelibs for what looks like a circular problem (or a linking problem). Forums and google tell me of problems with kdelibs and expat upgrade, but mostly qt3 related -this seems not to be the case. The ebuild stops with: ../dcop/dcopidl/dcopidl ./ksycoca.h ksycoca.kidl || ( rm -f ksycoca.kidl ; false ) ../dcop/dcopidl/dcopidl: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory So I equeried dcopidl, and dcopidl belongs to kdelibs itself! What does it mean? kdelibs needs a working kdelibs itself to be built (very strange)? Or when it compiles dcopidl, fails to link it against the new expat? Or I failed at finding the dcopidl ebuild? Thanks for your help, M. -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
On Monday 17 March 2008, brullo nulla wrote: Hi folks, I am finally getting through the expat update. I am currently stuck at kdelibs for what looks like a circular problem (or a linking problem). Forums and google tell me of problems with kdelibs and expat upgrade, but mostly qt3 related -this seems not to be the case. The ebuild stops with: ../dcop/dcopidl/dcopidl ./ksycoca.h ksycoca.kidl || ( rm -f ksycoca.kidl ; false ) ../dcop/dcopidl/dcopidl: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory So I equeried dcopidl, and dcopidl belongs to kdelibs itself! What output do you get from 'revdep-rebuild -p -i' ? -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] expat upgrade, kdelibs: circular problem?
On Monday 17 March 2008, brullo nulla wrote: What output do you get from 'revdep-rebuild -p -i' ? Here it is: Evaluating package order... Warning: Failed to resolve package order. Will merge in random order! Possible reasons: - An ebuild is no longer in the portage tree. - An ebuild is masked, use /etc/portage/packages.keyword and/or /etc/portage/package.unmask to unmask it . done. (/root/.revdep-rebuild.5_order) snip HUGE package list... Hmmm. I seem to recall the expat upgrade being similar for me too. Unless you receive good advice to the contrary, you could try doing what I eventually did: emerge -avuND world then emerge --skipfirst --resume as many times as needed to get to the end. Mask and unmask stuff manually as required. Eventually it all ends :-) and you are left with a consistent system. The final test is to run: emerge -avuND world emerge -av --depclean revdep-rebuild -p -i and all three should result in nothing to do. -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
