media-libs/libcanberra-0.28-r1 doesn't install libcanberra.la, but other installed .la-files link against it, e.g. libcanberra-alsa.la: # Libraries that this one depends upon. dependency_libs=' -lasound /usr/lib64/libcanberra.la -lvorbisfile -lvorbis -logg /usr/lib64/libltdl.la -ldl -lm' Reproducible: Always Expected Results: Install libcanberra.la
Created attachment 272169 [details] cave info libcanberra
portage runs a cleanup of those files. probably should be treated as paludis bug.
Nope. There's nothing in PMS saying that .la cleanup should be done. So the bug is that Portage introduced a new feature and didn't EAPI control it (and note that not all Portage versions do unholy things to .la files).
Bug is still there in -r2. Could you please just use a proper way to clean those .la files? :)
*push* ;)
Seems fixed in -r3, thanks!
Or not... sorry for the mistake. Please fix it or tell me what needs to be done and I provide the patch :(
The ebuild does not uncessary la files anymore. You must rebuild all packages that have la files containing references against libcanberra.la or just lafilefixer --justfixit which should do the same without rebuilding everything.
(In reply to comment #8) > You must rebuild all packages > that have la files containing references against libcanberra.la The thing is, the .la files referencing libcanberra.la get installed by libcanberra itself, so reinstalling libcanberra doesn't change anything! # # Find broken linkage: # Garten ~ # cave fix-linkage Searching: 15 directories, 63653 files * media-libs/libcanberra-0.28-r3::installed /usr/lib64/libcanberra-0.28/libcanberra-alsa.la (requires /usr/lib64/libcanberra.la) /usr/lib64/libcanberra-0.28/libcanberra-gstreamer.la (requires /usr/lib64/libcanberra.la) /usr/lib64/libcanberra-0.28/libcanberra-multi.la (requires /usr/lib64/libcanberra.la) /usr/lib64/libcanberra-0.28/libcanberra-null.la (requires /usr/lib64/libcanberra.la) /usr/lib64/libcanberra-0.28/libcanberra-pulse.la (requires /usr/lib64/libcanberra.la) Done: 1404 steps These are the actions I will take, in order: r media-libs/libcanberra:0::gentoo 0.28-r3 to ::installed replacing 0.28-r3 alsa gstreamer gtk gtk3 -oss pulseaudio sound -tdb udev build_options: -optional_tests symbols=split -trace -preserve_work Reasons: target (/usr/lib64/libcanberra.la) Total: 1 reinstalls Executing pretend actions: 1 of 1 Writing resume information to /root/.cache/cave_resume... * No unread news items found # # So these are the culprits. Find the owning package: # Garten ~ # cave owner /usr/lib64/libcanberra-0.28/libcanberra-alsa.la media-libs/libcanberra-0.28-r3:0::installed Garten ~ # cave owner /usr/lib64/libcanberra-0.28/libcanberra-gstreamer.la media-libs/libcanberra-0.28-r3:0::installed Garten ~ # cave owner /usr/lib64/libcanberra-0.28/libcanberra-multi.la media-libs/libcanberra-0.28-r3:0::installed Garten ~ # cave owner /usr/lib64/libcanberra-0.28/libcanberra-null.la media-libs/libcanberra-0.28-r3:0::installed Garten ~ # cave owner /usr/lib64/libcanberra-0.28/libcanberra-pulse.la media-libs/libcanberra-0.28-r3:0::installed So: libcanberra installs /usr/lib64/libcanberra-0.28/libcanberra-alsa.la /usr/lib64/libcanberra-0.28/libcanberra-gstreamer.la /usr/lib64/libcanberra-0.28/libcanberra-multi.la /usr/lib64/libcanberra-0.28/libcanberra-null.la /usr/lib64/libcanberra-0.28/libcanberra-pulse.la Which reference the non-existing libcanberra.la, reinstalling libcanberra doesn't solve anything. Even uninstalling libcanberra (which completely deletes the affected .la-files) and then reinstalling it results in the same broken .la files.
Hum maybe its portage not autofixing la files at the end of the install then. I thought this feature was present in stable for something like a year. What happens if you remove libcanberra and rebuild it ?
(In reply to comment #10) > Hum maybe its portage not autofixing la files at the end of the install then. I > thought this feature was present in stable for something like a year. What I don't use portage. As far as I understand comment #2 and comment #3, the whole problem is, that portage does some cleanup on those files without it being part of the standard. So the ebuild is buggy on every standard-conform package manager. > happens if you remove libcanberra and rebuild it ? That doesn't help.
(In reply to comment #11) The whole problem is that 1. Generally speaking, paludis developers believe that following standards documents and certain philosophical principles is more important than delivering a good user experience right now. 2. In particular, paludis developers don't like portage's FEATURES variable, and ignore it as a matter of policy. 3. As a result, when portage introduces an extremely useful, 99.999%-of-users-want-it type of FEATURES-controlled feature and then enables it by default through make.globals, paludis developers insist on seeing the PMS changed before following suit; see comment #3. 4. Very few people - and in particular, very few Gentoo developers - use paludis. 5. Therefore, most ebuilds in the tree are only tested on portage. Issues that don't arise on a default portage setup may go unnoticed for months. 6. And due to the small size of paludis's user base, Gentoo developers usually treat fixing such issues as a low-priority task. Specifically, as far as libcanberra is concerned: 1. The bug will be fixed. Eventually. When some developer who cares about libcanberra has a sizable interval of free time and nothing else to do. 2. Submitting a patch for the libcanberra ebuild will get the bug fixed much faster. The conclusions that can be drawn from this are: 1. Unfortunately, paludis users should, realistically, expect things to occasionally be broken. It's unpleasant, but it's a fact of life. 2. Unfortunately, paludis users should, realistically, expect the broken things to go unfixed for significant lengths of time - which can be significantly reduced only if they (the paludis users) provide patches. It's unpleasant, but it's a fact of life. 3. The situation is unlikely to improve until paludis significantly increases its mindshare, or at least until some paludis-using developer starts an automated tinderbox that reports errors in recently changed ebuilds to bugzilla (similar to what flameeyes is doing with the gold linker).
No, the issue is that in order to avoid fixing a bug properly, Portage added in a broken hack that isn't standardised or documented and that leaves broken files all over a user's system when packages are upgraded or uninstalled, and now some packages won't work properly if that hack is disabled. Unfortunately, until Gentoo moves away from the "I didn't notice any breakage myself so it works" mentality and towards "I understand exactly what is going on and what the implications are", users will continue to get screwed over by all the things that people didn't think of the first time around.
Thanks Alexandre for your well explained comment. I would have added that even before portage included this feature, it was available as a lafilefixer invocation in post_install hook. Paludis probably doesn't have such mechanism :(. Now if Ciaran and our reporter actually cared about this bug from day one, they would probably have tested if libcanberra actually works with all la files removed or not. I've been told on irc this is the case but since I haven't had time to check this myself and I don't like changes based on only one comment like this... Would somebody please do the check now so we can end all this drama soon ?
Paludis has hooks. But running lafilefixer is always wrong, since it updates .la files without modifying VDB CONTENTS, which in turn means those files don't get uninstalled on an upgrade. Chasing individual packages here is the wrong thing to do. Handling of .la files on Gentoo as a whole is utterly broken, and so long as lafilefixer is touted as a solution users of any package manager are going to get randomly screwed over.
(In reply to comment #15) > Paludis has hooks. But running lafilefixer is always wrong, since it updates > .la files without modifying VDB CONTENTS, which in turn means those files don't > get uninstalled on an upgrade. Ciaran, you are confusing two completely different things: A. portage's "FEATURES=fixlafiles", which tells portage to run a certain hook after src_install, and which therefore *does* update VDB CONTENTS; and B. dev-util/lafilefixer, an external tool that is run directly on the filesystem, and that at the moment ignores package management. [Incidentally, if you want dev-util/lafilefixer to update VDB CONTENTS, you probably should file a separate bug about it.]
"fixlafiles" should be in PMS and EAPI controlled if you're relying upon it.
(In reply to comment #14) > [...] > Now if Ciaran and our reporter actually cared about this bug from day one, they > would probably have tested if libcanberra actually works with all la files > removed or not. > [...] I offered help (comment #7) ;) Unfortunately I have little to no experience with developing ebuilds, so this is just the kind of hint I need to get started testing. So: I removed the .la-files installed by libcanberra: Garten ~ # cave contents libcanberra | grep \\.la /usr/lib64/libcanberra-0.28/libcanberra-multi.la /usr/lib64/libcanberra-0.28/libcanberra-alsa.la /usr/lib64/libcanberra-0.28/libcanberra-gstreamer.la /usr/lib64/libcanberra-0.28/libcanberra-null.la /usr/lib64/libcanberra-0.28/libcanberra-pulse.la and reinstalled every part of my system depending on libcanberra, which is: brasero gnome-control-center gnome-panel gnome-settings-daemon libgnome gnome-games gnome-media gnome-power-manager gnome-utils phonon-kde evolution sound-juicer cheese notification-daemon metacity There were no problems with that. I hope this helps :) About dev-util/lafilefixer: I won't even install that thing, because it almost broke an entire Gentoo installation, as it left dozens of orphaned .la-files all over my system. Thus - offtopic! - IMHO dev-util/lafilefixer shouldn't be used by anyone in its current condition. It's a PITA to manually remove everything lafilefixer left behind on a >= 3 years old system and it's exteremely dangerous as well, because you only notice these remainders when they actually break something. BTW, this is one of the reasons I use paludis: I (user, not developer) want my package manager to keep my system clean. Concerning automatic .la-file cleanup by portage: As long as it's not documented anywhere, it might be dropped tomorrow. This obviously is a problem, isn't it?
(In reply to comment #18) > Concerning automatic .la-file cleanup by portage: As long as it's not > documented anywhere, it might be dropped tomorrow. This obviously is a problem, > isn't it? The FEATURES=fixlafiles code is right here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/util/lafilefixer.py;hb=HEAD Most people tend to like the feature, so we certainly won't be dropping it unless there's a good reason and a migration plan. The council had a vague discussion about this stuff a few months ago: http://www.gentoo.org/proj/en/council/meeting-logs/20101026.txt
It's not specified in PMS, and there's a strong argument to be made that it's in direct violation. Any ebuild that doesn't work without it is broken.
(In reply to comment #18) > About dev-util/lafilefixer: I won't even install that thing, because it almost > broke an entire Gentoo installation, as it left dozens of orphaned .la-files > all over my system. Thus - offtopic! - IMHO dev-util/lafilefixer shouldn't be > used by anyone in its current condition. It's a PITA to manually remove > everything lafilefixer left behind on a >= 3 years old system and it's > exteremely dangerous as well, because you only notice these remainders when > they actually break something. Maybe running "qfile -o /usr/lib/*.la" could give you some hints about what .la files could be removed
(In reply to comment #20) > It's not specified in PMS, and there's a strong argument to be made that it's > in direct violation. Any ebuild that doesn't work without it is broken. I am a bit new with all this portage vs paludis arguments but, what is the "paludis" solution for all this .la files problem? Why don't you like portage's approach and what is preventing its implementation in paludis also? (that would also probably allow us to drop lafilefixer direct usage as, if I understand correctly, running it shouldn't be needed on a system completely build with "lafilefix" like FEATURE, no? About the ebuild problem, looks like removing all .la files from libcanberra could solve this, or not? (I don't want to touch it as looks like time ago they were dropped all together but, later, only a few of them, probably due some other problem :-/)
The correct solution here is that if you want a change in how .la files are installed then it needs to be specced and controlled, not thrown in on a whim in such a way that suddenly ebuilds start relying upon a particular undocumented behaviour.
Then, a suggestion like making a new eapi5 that drops most of .la files and makes package managers run a "lafilefix" like solution for the remaining would make most of us happy? (the problem of that approach would be how to properly handle .la files removal for packages from system set as, if I remember correctly, eapi0 is still preferred for them :S)
So long as Portage stopped doing it for earlier EAPIs so that ebuilds relying upon the feature would get caught by developers rather than breaking users' systems, yes.
I searched in bugzilla and looks like it's partially covered in bug #357561, not sure what is delaying it :-S
(In reply to comment #26) > I searched in bugzilla and looks like it's partially covered in bug #357561, > not sure what is delaying it :-S That's a long way away from being a specification.
Can we move that discussion then to the referred bug report? Personally I don't have any idea about what is needed to make it a proper specification and better discuss it there than continue polluting this bug report
+*libcanberra-0.28-r5 (12 Sep 2011) + + 12 Sep 2011; Pacho Ramos <pacho@gentoo.org> -libcanberra-0.28-r4.ebuild, + +libcanberra-0.28-r5.ebuild, +files/libcanberra-0.28-workaround-hang.patch: + Apply fedora patch to workaround hangs when pulseaudio has problems, RDEPEND + on gnome-base/gsettings-desktop-schemas to work ok with + gnome-session-2.32.1-r3, remove all .la files (bug #366071 by Stephan + Friedrichs, thanks a lot to Jonathan Callen for his explanation. Remove old. +
Why was .la files removed, when the package is relying on them while using libltdl for loading plugins? I suppose I'll reopen the bug as it was misresolved...
The solution is to leave all .la files, and empty the dependency_libs in src_install() like imagemagick is doing.
Jonathan Callen explained us (in gnome@g.o) that they weren't needed, I even copy his exactly message explaining that in updated ebuild, that also would explain why fedora has no problem on dropping all .la files
Sorry for noise and closing per (did not try myself): < ABCD> ssuominen: the .la files are only used for libcanberra *if present* -- if they are absent, then it tries using .so instead (on ELF systems; it uses .bundle on Darwin, .dll on PE, etc.)
To be more precise, iirc, it uses a call to libltdl that tries to load the library according to well-known extensions per platform which defacto makes la files useless. Some libraries like libgphoto2 do not use this yet but could be patched, it should be a matter of changing one line in the code.
Thanks for fixing :)
