Bugzilla Bug 191989

I tweaked USE flags a bit, did all world updates (with --newuse) then depclean,
and sys-apps/attr was removed. Then gedit stopped working:

gedit: error while loading shared libraries: libattr.so.1: cannot open shared
object file: No such file or directory

From gedit's configure.ac:
AC_CHECK_LIB(attr, attr_copy_fd)

I suggest this is either made an unconditional dependency (based on which
functionality it provides) or is conditional via a USE flag.

same problem that bug #191426

No it's not. gedit correctly looks for the dynamic libattr which was on my
system.  It's not any more, libattr is *completely* gone.

The issue is with the ebuild dependency graph not being consistent with the
dependencies of gedit itself when installed on a system with libattr present.

I turned attr into unconditional dependency because upstream doesn't provide a
switch for this. It's probably not the best thing to do but I'll look for a
cleaner solution and bug upstream when I get enough time for that.

fix is in CVS, thanks for reporting and sorry for the initial answer's
confusion.

Unnecessary depend... and I hate unnecessary depends on my system.

The problem is dsd had sys-apps/attr on his system when he emerged attr. Now he
got rid of it and gedit is upset.

The exact "functionality" this depend provides is minimal at best. When you
open file "test.file" and save your changes as "zomg.new.file", it will copy
the attributes from the old file to the new file.

The established USE flag for this is called "acl" and should be used. Look at
sys-apps/coreutils for an example.

Attaching a patch for gedit, please kick it upstream as well.

Created an attachment (id=130833) [details]
gedit-libattr-shadow-depend-remove

applied, thanks.

<solar> FYI.. stable gedit with USE="-xattr" if libattr.so is installed will
still link with it.

Paste showing the problem:

miranda:hardened  ~ # emerge -pvq gedit
[ebuild   R   ] app-editors/gedit-2.20.3  USE="spell -debug -doc -python
-xattr" 
miranda:hardened  ~ # qlist -oe gedit | scanelf -f - -n -q | grep libattr.so|
wc -l
11
miranda:hardened  ~ # emerge -Cq attr ; emerge gedit -q

Created an attachment (id=137326) [details]
app-editors:gedit-2.20.3:20071129-170920.log

The gedit-2.20.3.ebuild reintroduced the problem, probably because the patch
isn't applied in that ebuild and upstream hasn't done anything yet either.

The same patch does apply to 2.20.3 so maybe the ebuild needs a simple update.

(In reply to comment #9)
> The same patch does apply to 2.20.3 so maybe the ebuild needs a simple update.
> 

Fixed in CVS.

(In reply to comment #10)
> (In reply to comment #9)
> > The same patch does apply to 2.20.3 so maybe the ebuild needs a simple update.
> > 
> 
> Fixed in CVS.

Damn, it's not fixed at all. Reverting.

This seems to do it:

--- configure.ac.       2007-10-18 11:12:44.000000000 +0200
+++ configure.ac        2007-11-29 19:41:10.000000000 +0100
@@ -139,8 +139,6 @@
 dnl libattr checks
 dnl ================================================================

-AC_CHECK_LIB(attr, attr_copy_fd)
-
 AC_MSG_CHECKING([whether libattr support is requested])
 AC_ARG_ENABLE([attr],
        AS_HELP_STRING([--enable-attr],[Enable libattr support]),

Fixed in CVS.

http://svn.gnome.org/viewvc/gedit/branches/gnome-2-20/configure.ac?r1=5919&r2=5929

It seems the fix was never correctly applied in the first place: the original
library check at line 142 was never replaced.

(In reply to comment #14)
> http://svn.gnome.org/viewvc/gedit/branches/gnome-2-20/configure.ac?r1=5919&r2=5929
> 
> It seems the fix was never correctly applied in the first place: the original
> library check at line 142 was never replaced.

It still not fixed (as of 2.23.1). Is there an upstream bug for this?

(In reply to comment #15)
> It still not fixed (as of 2.23.1). Is there an upstream bug for this?

Just to clarify, I mean this hasn't been fixed upstream.

This seems to have magically been fixed in 2.22.3. and trunk
(http://svn.gnome.org/viewvc/gedit/trunk/configure.ac?view=markup).

Good to close.

indeed, it is in 2.22.3, closing.