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 attachment 130833 [details, diff] 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 attachment 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.
