Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 321391 - gnustep-base/gnustep-gui: automagic dependency on media-libs/libicns
Summary: gnustep-base/gnustep-gui: automagic dependency on media-libs/libicns
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Gentoo Gnustep project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: bundled-libs
  Show dependency tree
 
Reported: 2010-05-25 03:42 UTC by James Browning
Modified: 2019-04-25 12:15 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 James Browning 2010-05-25 03:42:03 UTC
Many GNUstep apps now seem to require libicns to run however it is not listed in either gnustep.eclass nor any of the GNUstep ebuilds.

Reproducible: Always

Steps to Reproduce:
1. Install a GNUstep app (say AClock)
2. Try to execute app (say by 'openapp AClock')

Actual Results:  
application fails to run citing missing libicns.

Expected Results:  
GNUstep Application should run.
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2010-05-26 16:07:41 UTC
Uh, libicns is a library for opening MacOSX .icns icons.  Can you post output of such failure?
Comment 2 James Browning 2010-05-27 23:49:06 UTC
the output is rather bluntly.
/usr/GNUstep/System/Applications/AClock.app/AClock: error while loading shared libraries: libicns.so.1: cannot open shared object file: No such file or directory
Comment 3 Fabian Groffen gentoo-dev 2010-05-28 06:37:39 UTC
seems reasonable to me, can you suggest a patch?
Comment 4 Bernard Cafarelli gentoo-dev 2010-05-28 08:13:45 UTC
That is probably an automagic dependency, I never had libicns installed and no gnustep app/lib links to it

What are the versions of gnustep base packages you use? you can get them with `qlist -Iv gnustep-base`
Comment 5 Bernard Cafarelli gentoo-dev 2010-05-28 12:17:20 UTC
Ok found it, in gnustep-gui configure.ac:
AC_CHECK_LIB(icns, icns_read_family_from_file)

If libicns is not installed, a partial bundled replacement is used, in Source/NSBitmapImageRep+ICNS.m:
/*
  The following code is a drop in replacement for libicns. It may be used
  when the library is not available or unsuited due to its licence (Currently
  GPL 2). This code was mostly build based on the documentation found at 
  http://icns.sourceforge.net/apidocs.html. It also includes icns decoding 
  ideas based on code in mySTEP.
  Only limited formats are implemented and some errors still exist.
 */

I'd suggest unconditionnal depend on libicns in gnustep-gui, but this requires some keywording in the lib first (gnustep-gui 0.18 is ~alpha ~amd64 ~ppc ~sparc ~x86 ~x86-fbsd ~amd64-linux ~x86-linux ~x86-solaris)
Comment 6 James Browning 2010-05-28 13:12:03 UTC
I had from sabayon repos.
gnustep-base-1.18.0-r4
gnustep-gui-0.16.0-r1
gnustep-make-2.2.0

I would suggest that if explicit libicns support is desired, it should come from a useflag somewhere that stuff it in depend and passes something not too unlike '--with-libicns' or if not desired passes '--without-lib-icns' to configure.
It looks like I'm an idiot in this case and the culprit is sabayons binpkgs exercising normally dormant DEPEND issues in ebuilds.
Comment 7 Harald van Dijk (RETIRED) gentoo-dev 2010-05-28 16:16:45 UTC
(In reply to comment #5)
> I'd suggest unconditionnal depend on libicns in gnustep-gui,

I'd suggest disabling linking against libicns altogether, if it effectively makes a LGPL-licensed library GPL-ed, unless it has clear benefits.
Comment 8 Bernard Cafarelli gentoo-dev 2010-06-01 20:16:01 UTC
Thanks Harald, I had not checked the licenses. So the easier solution (replacement code) is the better one license-wise then :)
Comment 9 Paul Wise (Debian) 2010-12-24 14:12:45 UTC
libicns is LGPL. The GPL part of it is the icns2png program that isn't compiled into the library, it just uses it.
Comment 10 Paul Wise (Debian) 2011-11-01 08:29:33 UTC
Embedded code copies are always a bad idea and the license is not an issue (it is LGPL).
Comment 11 Samuli Suominen (RETIRED) gentoo-dev 2012-02-21 06:21:10 UTC
(In reply to comment #10)
> Embedded code copies are always a bad idea and the license is not an issue (it
> is LGPL).

+1.    
The library bits from libicns are "LGPL-2 or later" or "LGPL-2.1 or later" so it should be fine.   
There is now cleaned version of libicns ebuild in tree, 0.8.0. This would be excellent time to switch from the bundled code to the external library.