Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 366071 - media-libs/libcanberra-0.28-r1 doesn't install libcanberra.la
Summary: media-libs/libcanberra-0.28-r1 doesn't install libcanberra.la
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Thomas Anderson (tanderson) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-05 10:24 UTC by Stephan Friedrichs
Modified: 2011-09-13 08:28 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
cave info libcanberra (info,18.04 KB, text/plain)
2011-05-05 10:25 UTC, Stephan Friedrichs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Friedrichs 2011-05-05 10:24:16 UTC
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
Comment 1 Stephan Friedrichs 2011-05-05 10:25:38 UTC
Created attachment 272169 [details]
cave info libcanberra
Comment 2 Rafał Mużyło 2011-05-05 16:12:48 UTC
portage runs a cleanup of those files.
probably should be treated as paludis bug.
Comment 3 Ciaran McCreesh 2011-05-05 19:43:54 UTC
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).
Comment 4 Stephan Friedrichs 2011-05-09 09:42:40 UTC
Bug is still there in -r2.
Could you please just use a proper way to clean those .la files? :)
Comment 5 Stephan Friedrichs 2011-07-04 08:34:45 UTC
*push* ;)
Comment 6 Stephan Friedrichs 2011-07-22 09:00:05 UTC
Seems fixed in -r3, thanks!
Comment 7 Stephan Friedrichs 2011-07-22 09:03:31 UTC
Or not... sorry for the mistake. Please fix it or tell me what needs to be done and I provide the patch :(
Comment 8 Gilles Dartiguelongue gentoo-dev 2011-07-24 16:07:00 UTC
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.
Comment 9 Stephan Friedrichs 2011-07-25 08:22:02 UTC
(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.
Comment 10 Gilles Dartiguelongue gentoo-dev 2011-07-25 09:10:33 UTC
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 ?
Comment 11 Stephan Friedrichs 2011-07-25 09:24:01 UTC
(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.
Comment 12 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-07-25 12:51:14 UTC
(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).
Comment 13 Ciaran McCreesh 2011-07-25 12:58:20 UTC
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.
Comment 14 Gilles Dartiguelongue gentoo-dev 2011-07-25 13:15:52 UTC
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 ?
Comment 15 Ciaran McCreesh 2011-07-25 13:26:36 UTC
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.
Comment 16 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-07-25 13:47:53 UTC
(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.]
Comment 17 Ciaran McCreesh 2011-07-25 13:57:53 UTC
"fixlafiles" should be in PMS and EAPI controlled if you're relying upon it.
Comment 18 Stephan Friedrichs 2011-07-26 09:19:10 UTC
(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?
Comment 19 Zac Medico gentoo-dev 2011-07-26 10:04:21 UTC
(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
Comment 20 Ciaran McCreesh 2011-07-26 10:12:01 UTC
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.
Comment 21 Pacho Ramos gentoo-dev 2011-07-27 09:36:50 UTC
(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
Comment 22 Pacho Ramos gentoo-dev 2011-07-27 09:42:14 UTC
(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 :-/)
Comment 23 Ciaran McCreesh 2011-07-27 09:50:12 UTC
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.
Comment 24 Pacho Ramos gentoo-dev 2011-07-27 10:05:00 UTC
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)
Comment 25 Ciaran McCreesh 2011-07-27 10:09:41 UTC
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.
Comment 26 Pacho Ramos gentoo-dev 2011-07-27 11:10:25 UTC
I searched in bugzilla and looks like it's partially covered in bug #357561, not sure what is delaying it :-S
Comment 27 Ciaran McCreesh 2011-07-27 11:12:54 UTC
(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.
Comment 28 Pacho Ramos gentoo-dev 2011-07-27 11:17:25 UTC
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
Comment 29 Pacho Ramos gentoo-dev 2011-09-12 10:16:13 UTC
+*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.
+
Comment 30 Samuli Suominen gentoo-dev 2011-09-12 10:23:59 UTC
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...
Comment 31 Samuli Suominen gentoo-dev 2011-09-12 10:27:00 UTC
The solution is to leave all .la files, and empty the dependency_libs in src_install() like imagemagick is doing.
Comment 32 Pacho Ramos gentoo-dev 2011-09-12 10:28:35 UTC
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
Comment 33 Samuli Suominen gentoo-dev 2011-09-12 22:35:24 UTC
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.)
Comment 34 Gilles Dartiguelongue gentoo-dev 2011-09-13 07:15:38 UTC
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.
Comment 35 Stephan Friedrichs 2011-09-13 08:28:49 UTC
Thanks for fixing :)