Bug 204464 - Include ppc64 versions of java-gnome packages
Include ppc64 versions of java-gnome packages
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
ppc64 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2006-08-29 07:15 EDT by Stepan Kasal
Modified: 2014-03-16 23:01 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-31 10:39:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stepan Kasal 2006-08-29 07:15:57 EDT
Could you please include the following rpms to the ppc iso?
They are needed to build 64bit version of frysk.

glib-java-*.ppc64.rpm glib-java-debuginfo-*.ppc64.rpm glib-java-devel-*.ppc64.rpm
cairo-java-*.ppc64.rpm cairo-java-debuginfo-*.ppc64.rpm cairo-java-devel-*.ppc64.rpm
libgtk-java-*.ppc64.rpm libgtk-java-debuginfo-*.ppc64.rpm
libgnome-java-*.ppc64.rpm libgnome-java-debuginfo-*.ppc64.rpm
libgconf-java-*.ppc64.rpm libgconf-java-debuginfo-*.ppc64.rpm
libvte-java-*.ppc64.rpm libvte-java-debuginfo-*.ppc64.rpm
libglade-java-*.ppc64.rpm libglade-java-debuginfo-*.ppc64.rpm
Comment 1 Jesse Keating 2006-08-29 08:26:02 EDT
All of these -devel packages have a ppc64 version in the ppc tree.  However the
arch specific base package isn't required by the -devel package so it isn't
brought in.  I think this is because most other -devel packages have symlinks in
them that point to the arch specific library, and so the autodep generation sees
that it needs the arch specific package.  I suppose there is nothing like that
in the java packages...? *sigh*

(and really, do you need the debuginfo packages to BUILD?)
Comment 2 Stepan Kasal 2006-08-29 13:48:05 EDT
(In reply to comment #1)
> All of these -devel packages have a ppc64 version in the ppc tree.

Oh, I see it now.  I thought that each -devel package requires the corresponding
base one.  How do I define that in spec file?

> (and really, do you need the debuginfo packages to BUILD?)

No, of course, this was a mistake on my side.  Sorry.
Comment 3 Jesse Keating 2006-08-29 13:57:17 EDT
Well, in non-java packages that have shared libraries, the -devel package
usually has an unversoined symlink that points to the versioned library, and
that library is arch specific, thus the -devel package for i386 will require the
base package for i386, likewise the -devel x86_64 will require the base x86_64
package.  Usually these base packages are pretty much the same, the x86_64
binaries "win" since it is the preferred arch.

With java packages, things are different.  You don't have any symlinks that
point to an arch specific library, so that arch specific requires isn't being
automagically created.

In this case, we may have to explicitly list all the java base packages that you
want to be multilib.  This is pretty ugly though, likely to break and fall out
of sync with the java package list, and would have to be replicated across all
the distributions we compose for.

I'm CC'ing Jeremy to this bug as he created the rpm stuff that uses -devel
packages for multilib discovery.  Maybe he has some input on how to do this with
java packages, but the java packaging may just be too broken to automatically do
it :/
Comment 4 Jeremy Katz 2006-08-29 14:04:43 EDT
From a quick look, it seems that (eg) %{_libdir}/libgtkjava.so should be in the
-devel package and not the main package.  Non-devel needs are for
%{_libdir}/libgtkjava-2.8.so and then libgtkjava.so is only used for linking
Comment 5 Stepan Kasal 2006-08-29 16:06:28 EDT
(In reply to comment #4)
> From a quick look, it seems that (eg) %{_libdir}/libgtkjava.so should be in the
> -devel package and not the main package.

I think you are right, thanks.
I'll correct that and rebuild all the java-gnome packages.
Comment 6 Stepan Kasal 2006-08-31 10:39:41 EDT
I changed the packaging according to comment #4.
I verified that the mechanism really works: the nightly build of the ISO really
contains the base packages.

Thanks, Jeremy!

Note You need to log in before you can comment on or make changes to this bug.