Bug 191989 - app-editors/gedit has automagic dependency on libattr (sys-apps/attr)
|
Bug#:
191989
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: gnome@gentoo.org
|
Reported By: dsd@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: app-editors/gedit has automagic dependency on libattr (sys-apps/attr)
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-09-10 15:19 0000
|
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.
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.
<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]),
(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.
indeed, it is in 2.22.3, closing.
