Hello, On Mon, 23 Jan 2012, David C. Rankin wrote:
On 01/21/2012 08:24 AM, David Haller wrote:
Nope, the deps are ok as they are. Why? Yes, libgcj needs little:
$ ldd /usr/lib64/libgcj.so.11.0.0 linux-vdso.so.1 => (0x00007fff3d9ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbb4e5f0000) librt.so.1 => /lib64/librt.so.1 (0x00007fbb4e3e6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbb4e1e2000) libz.so.1 => /lib64/libz.so.1 (0x00007fbb4dfca000) libc.so.6 => /lib64/libc.so.6 (0x00007fbb4dc5c000) /lib64/ld-linux-x86-64.so.2 (0x00007fbb519f7000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbb4da46000)
Buuuuut, that package also includes /usr/lib64/gcj-4.5-11/libjawt.so for the java-AWT-GUI, and_THAT_ lib depends on the gtk/x11 stuff.
So, I'd say it's a packaging problem, the GUI stuff should be packaged seperately as e.g. libgcj-gui45 or something. [..] You have hit on a very longstanding complaint and are correct pdftk has no gui at all. What should be a tiny build and tiny app has always been hindered by the garbage collector dependency.
GCJ is not a garbage collector. ==== info gcj ==== This manual describes how to use `gcj', the GNU compiler for the Java programming language. ==== It's the GCC Java Compiler.
Not only is the gui requirement from gcj nuts, [..] pdftk is an incredibly useful tool. Perhaps the developer could find a way to eliminate the GUI requirement so that I could be packaged/installed on systems that have no GUI desktop installed.
You misunderstand. Not pdftk requires the GUI. Java does. Java includes a GUI, i.e. AWT. There's nothing the pdftk-upstream can do about the opensuse libgcj-package including the libjawt. WE, that is the opensuse gcj packagers need to split out the awt lib into a seperate package, so that non-gui java programs do not pull in gtk/glib/gnome/X stuff. So, file a bug: https://bugzilla.novell.com/enter_bug.cgi?classification=7340&product=openSUSE.org&component=3rd%20party%20software&assigned_to=rguenther@suse.com&short_desc=devel:gcc/libgcj45:%20Bug That's the devel-project packaging GCC/libgcj. The fix should be straightforward, as libgcj already consists of quite a few subpackages. Ask, that at least libjawt.so and libgtkpeer.so (also depends on the GTK+ stack) should be packaged seperately from the rest. That'd leave above mentioned for libgcj itself plus libgmp for libjavamath.so (it's ok, I think, to keep that lib, i.e. require that for the libgcj package). Oh, actually, you could do it yourself, too. But maybe a little steep if you've not read specfiles before. But to go to the project and look at the specfile: https://build.opensuse.org/package/view_file?file=libgcj45.spec&package=libgcj45&project=devel%3Agcc&rev=8f158fa5198b24244e5468924ac4c488 concentrate on %package, %description and %files sections and think about what would need to be changed. -dnh -- A monk. A punk. A chick. In a kick-ass flick. -- Bulletproof Monk -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org