Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 265427 - dev-util/anjuta-2.24.2 has a avahi memory effect
Summary: dev-util/anjuta-2.24.2 has a avahi memory effect
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: gnome2.24
  Show dependency tree
 
Reported: 2009-04-08 10:56 UTC by Sven Müller
Modified: 2010-03-07 09:41 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Müller 2009-04-08 10:56:15 UTC
Long time ago a kdelibs-update installed mdnsresponder as a depency. For some reason I didn't like mdnsresponder and substituted mdnsresponder by the avahi-daemon. Some time afterwards I decided to get completely rid of the zeroconf stuff. So on that system there's nothing installed which referes to zeroconf, avahi or mdnsresponder. 

Today I reinstalled anjuta and checked the system depencies with revdev-rebuild. I got a lot of those errors: 

 libavahi-common.so.3
libavahi-glib.so.1)
*   broken /usr/lib/anjuta/libanjuta-sourceview.la (requires /usr/lib/libavahi-glib.la)
*   broken /usr/lib/anjuta/libanjuta-sourceview.la (requires /usr/lib/libavahi-client.la)
*   broken /usr/lib/anjuta/libanjuta-sourceview.la (requires /usr/lib/libavahi-common.la)
*   broken /usr/lib/anjuta/libanjuta-sourceview.so (requires libavahi-client.so.3
libavahi-common.so.3
libavahi-glib.so.1)
*   broken /usr/lib/anjuta/libanjuta-subversion.la (requires /usr/lib/libavahi-glib.la)
*   broken /usr/lib/anjuta/libanjuta-subversion.la (requires /usr/lib/libavahi-client.la)
*   broken /usr/lib/anjuta/libanjuta-subversion.la (requires /usr/lib/libavahi-common.la)
*   broken /usr/lib/anjuta/libanjuta-subversion.la (requires /usr/lib/libsocks.la)
*   broken /usr/lib/anjuta/libanjuta-subversion.so (requires libavahi-client.so.3
libavahi-common.so.3
libavahi-glib.so.1
libsocks.so.0)
*   broken /usr/lib/anjuta/libanjuta-symbol-browser.la (requires /usr/lib/libavahi-glib.la)
*   broken /usr/lib/anjuta/libanjuta-symbol-browser.la (requires /usr/lib/libavahi-client.la)
*   broken /usr/lib/anjuta/libanjuta-symbol-browser.la (requires /usr/lib/libavahi-common.la)
*   broken /usr/lib/anjuta/libanjuta-symbol-browser.so (requires libavahi-client.so.3
libavahi-common.so.3
libavahi-glib.so.1)
*   broken /usr/lib/anjuta/libanjuta-terminal.la (requires /usr/lib/libavahi-glib.la)
*   broken /usr/lib/anjuta/libanjuta-terminal.la (requires /usr/lib/libavahi-client.la)
*   broken /usr/lib/anjuta/libanjuta-terminal.la (requires /usr/lib/libavahi-common.la)
*   broken /usr/lib/anjuta/libanjuta-terminal.so (requires libavahi-client.so.3

I don't know where anjuta invents that Avahi depencies, because at another computer - a complete fresh install that Avahi depency doesn't exist. Also I don't know from where Anjuta could know that there was the Avahi-Daemon installed long time ago. I the meantime since deinstalling the "Avahi-Virus" there were several gcc-, glibc-, binutils- and a lot of other updates. 

Reproducible: Always

Steps to Reproduce:
1. Install Avahi (and do a whole system update)
2. Deinstall Avahi (and do a whole system update again)
3. Install Anjuta
4. Do a revdep-rebuild.

Actual Results:  
revdep-rebuild gives me a lot broken avahi-depencies in anjuta. Reinstalling Anjuta doesn't help. 

Expected Results:  
No Avahi-depency where no avahi is installed. 

locate avahi gives me only the ebuilds with "avahi" in there name. So if there's not something of avahi hardcoded in some libs, there's really nothing avahi-related installed on my system.
Comment 1 Rafał Mużyło 2009-04-08 11:24:30 UTC
What you are facing is a problem very similar (in a way)
to bug 158476. See if for a solution.

Comment 2 Sven Müller 2009-04-08 21:12:59 UTC
Ok, I solved the problem. The solucion is to deinstall Anjuta completely and reinstall it. 

Only to update the package doesn't touch the files in /usr/lib/anjuta. Therefore it seems to be necessary to deinstall Anjuta first. Only that removes the /usr/lib/anjuta-directory.

What to do now?
Comment 3 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2009-04-09 22:55:39 UTC
(In reply to comment #2)
> What to do now?

I'd say we wait for input from the anjuta maintainer
Comment 4 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-05-04 20:01:56 UTC
(In reply to comment #2)
> Ok, I solved the problem. The solucion is to deinstall Anjuta completely and
> reinstall it. 
> 
> Only to update the package doesn't touch the files in /usr/lib/anjuta.
> Therefore it seems to be necessary to deinstall Anjuta first. Only that removes
> the /usr/lib/anjuta-directory.

this sounds wrong, I don't see why reinstalling anjuta wouldn't erase existing files unless anjuta somehow relinks against installed anjuta libs all the way. It wouldn't be the first time though.
Comment 5 Rémi Cardona (RETIRED) gentoo-dev 2009-05-04 22:04:44 UTC
anjuta 2.24.x was still generated with libtool 1.5 last time I checked and since it was one of the biggest users of "libs linking against other libs within the same project", I would definitely bet a buck that libtool is to blame.

Maybe 2.26 is generated with libtool 2.2? In any case, it'd be worth checking.
Comment 6 Gilles Dartiguelongue (RETIRED) gentoo-dev 2009-06-01 21:10:26 UTC
avahi is picked up somehow by the build system and creeps in every libs installed by anjuta while there is no reason for it being the case. We really need to review their autofoo since we concluded with remi that it was doing way too many suspicious stuff already.
Comment 7 Pacho Ramos gentoo-dev 2010-03-05 19:21:00 UTC
(In reply to comment #5)
> anjuta 2.24.x was still generated with libtool 1.5 last time I checked and
> since it was one of the biggest users of "libs linking against other libs
> within the same project", I would definitely bet a buck that libtool is to
> blame.
> 
> Maybe 2.26 is generated with libtool 2.2? In any case, it'd be worth checking.
> 

Still valid with anjuta-2.26* ?
Comment 8 Pacho Ramos gentoo-dev 2010-03-05 19:21:52 UTC
or even better with anjuta-2.28 ;-)
Comment 9 Rémi Cardona (RETIRED) gentoo-dev 2010-03-07 09:41:48 UTC
Please get back to us.

Thanks