aot-compile-rpm problem

[Anthony Green]

Hi,

 On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my
x86-64 system I get both the x86-64 and x86 packages.  I suppose the x86
version is written last, because aot-compile-rpm's LIBDIR is set
to /usr/lib/gcj instead of /usr/lib64/gcj.  This pretty much breaks rpm
building.

 The fix is to make sure I just "yum install
java-1.4.2-gcj-compat-devel.x86_64".

 Is this expected behaviour?  I don't remember this being a problem for
my in the past.

Thanks,

AG

[Gary Benson]

Anthony Green wrote:
>  On rawhide, when I do a "yum install
> java-1.4.2-gcj-compat-devel" on
>  my x86-64 system I get both the x86-64 and x86 packages.  I suppose
>  the x86 version is written last, because aot-compile-rpm's LIBDIR is
>  set to /usr/lib/gcj instead of /usr/lib64/gcj.  This pretty much
>  breaks rpm building.
>  
>  The fix is to make sure I just "yum install
>  java-1.4.2-gcj-compat-devel.x86_64".
>  
>  Is this expected behaviour?  I don't remember this being a problem
>  for my in the past. 
Hmmm, a couple of months ago there was a big fuss about making sure
multilib -devel packages could be installed simultaneously.  I wonder
if they changed yum to do something special with -devel packages.
Do you have both i386 and x86_64 versions of java-1.4.2-gcj-compat
installed?  If so, maybe yum sees this and installs both -devel
packages too?

Cheers,
Gary

[Anthony Green]

On Mon, 2006-07-31 at 08:49 +0100, Gary Benson wrote:
>  Do you have both i386 and x86_64 versions of java-1.4.2-gcj-compat
>  installed?   
No, just the x86_64 version.

>  If so, maybe yum sees this and installs both -devel
>  packages too? 
AG

[Andrew Haley]

Anthony Green writes:
>  Hi,
>  
>   On rawhide, when I do a "yum install java-1.4.2-gcj-compat-devel" on my
>  x86-64 system I get both the x86-64 and x86 packages.  I suppose the x86
>  version is written last, because aot-compile-rpm's LIBDIR is set
>  to /usr/lib/gcj instead of /usr/lib64/gcj.  This pretty much breaks rpm
>  building.
>  
>   The fix is to make sure I just "yum install
>  java-1.4.2-gcj-compat-devel.x86_64".
>  
>   Is this expected behaviour?  I don't remember this being a problem for
>  my in the past. 
AFAIK it's the default yum behaviour: multilibbed libraries install
all arches.  That seems a litttle weird, but there it is.

Andrew.

[Anthony Green]

On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
>  AFAIK it's the default yum behaviour: multilibbed libraries
> install
>  all arches.  That seems a litttle weird, but there it is. 
Gary - do you think aot-compile-rpm could set LIBDIR based in part on
the output of "gcj-dbtool -p" ?  I think that would let us have
identical scripts in both the 32- and 64-bit packages.

AG

[Gary Benson]

Anthony Green wrote:
>  On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
>  > AFAIK it's the default yum behaviour: multilibbed libraries
>  > install all arches.  That seems a litttle weird, but there it
>  > is.
>  
>  Gary - do you think aot-compile-rpm could set LIBDIR based in part
>  on the output of "gcj-dbtool -p" ?  I think that would let us have
>  identical scripts in both the 32- and 64-bit packages. 
I don't see why not.  Though I seem to recall we _used_ to set LIBDIR
that way but changed to the present setup to solve a specific problem.

gcj-dbtool is in the libgcj rpm: can you have multiple copies of this
installed simultaneously?  If so, and we do switch, which gcj-dbtool
do you get?

Cheers,
Gary

[Andrew Haley]

Gary Benson writes:
>  Anthony Green wrote:
>  > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
>  > > AFAIK it's the default yum behaviour: multilibbed libraries
>  > > install all arches.  That seems a litttle weird, but there it
>  > > is.
>  > 
>  > Gary - do you think aot-compile-rpm could set LIBDIR based in part
>  > on the output of "gcj-dbtool -p" ?  I think that would let us have
>  > identical scripts in both the 32- and 64-bit packages.
>  
>  I don't see why not.  Though I seem to recall we _used_ to set LIBDIR
>  that way but changed to the present setup to solve a specific problem.
>  
>  gcj-dbtool is in the libgcj rpm: can you have multiple copies of this
>  installed simultaneously?  
No.  It's in /usr/bin.

Andrew.

[Gary Benson]

Andrew Haley wrote:
>  Gary Benson writes:
>  > Anthony Green wrote:
>  > > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
>  > > > AFAIK it's the default yum behaviour: multilibbed libraries
>  > > > install all arches.  That seems a litttle weird, but there it
>  > > > is.
>  > > 
>  > > Gary - do you think aot-compile-rpm could set LIBDIR based in
>  > > part on the output of "gcj-dbtool -p" ?  I think that would let
>  > > us have identical scripts in both the 32- and 64-bit packages.
>  > 
>  > I don't see why not.  Though I seem to recall we _used_ to set
>  > LIBDIR that way but changed to the present setup to solve a
>  > specific problem.
>  > 
>  > gcj-dbtool is in the libgcj rpm: can you have multiple copies of
>  > this installed simultaneously?
>  
>  No.  It's in /usr/bin. 
Really?  So no simultaneous libgcj.i386 and libgcj.x86_64 installs?

Cheers,
Gary

[Andrew Haley]

Gary Benson writes:
>  Andrew Haley wrote:
>  > Gary Benson writes:
>  > > Anthony Green wrote:
>  > > > On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
>  > > > > AFAIK it's the default yum behaviour: multilibbed libraries
>  > > > > install all arches.  That seems a litttle weird, but there it
>  > > > > is.
>  > > > 
>  > > > Gary - do you think aot-compile-rpm could set LIBDIR based in
>  > > > part on the output of "gcj-dbtool -p" ?  I think that would let
>  > > > us have identical scripts in both the 32- and 64-bit packages.
>  > > 
>  > > I don't see why not.  Though I seem to recall we _used_ to set
>  > > LIBDIR that way but changed to the present setup to solve a
>  > > specific problem.
>  > > 
>  > > gcj-dbtool is in the libgcj rpm: can you have multiple copies of
>  > > this installed simultaneously?
>  > 
>  > No.  It's in /usr/bin.
>  
>  Really?  So no simultaneous libgcj.i386 and libgcj.x86_64 installs? 
No, because libgcj.x86_64 contains both /usr/lib64/* and /usr/lib/*

Andrew.

[Anthony Green]

On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote:
>  > > gcj-dbtool is in the libgcj rpm: can you have multiple
> copies of
>  > > this installed simultaneously?
>  > 
>  > No.  It's in /usr/bin.
>  
>  Really?  So no simultaneous libgcj.i386 and libgcj.x86_64 installs? 
It looks like the jar files and man pages conflict so you can't install
both at the same time (I tried to force it with "yum install
libgcj.i386").

AG

[Benjamin Konrath]

On Mon, 2006-07-31 at 08:14 -0700, Anthony Green wrote:
>  On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote:
>  > > > gcj-dbtool is in the libgcj rpm: can you have multiple copies of
>  > > > this installed simultaneously?
>  > > 
>  > > No.  It's in /usr/bin.
>  > 
>  > Really?  So no simultaneous libgcj.i386 and libgcj.x86_64 installs?
>  
>  It looks like the jar files and man pages conflict so you can't install
>  both at the same time (I tried to force it with "yum install
>  libgcj.i386"). 
Interesting. I have a brp script that will be installed in the post
install section of the rpm build to repack the jars with a consistent
time stamp. This should correct the problem with the jar files. 

The man page conflict is new to me - there's probably a time stamp or
arch listing somewhere in them. A bug should be filed about this
problem. Let me know if you would like me to file it.

Thanks, Ben

[Gary Benson]

Ben Konrath wrote:
>  On Mon, 2006-07-31 at 08:14 -0700, Anthony Green wrote:
>  > On Mon, 2006-07-31 at 16:03 +0100, Gary Benson wrote:
>  > > > > gcj-dbtool is in the libgcj rpm: can you have multiple
>  > > > > copies of this installed simultaneously?
>  > > > 
>  > > > No.  It's in /usr/bin.
>  > > 
>  > > Really?  So no simultaneous libgcj.i386 and libgcj.x86_64
>  > > installs?
>  > 
>  > It looks like the jar files and man pages conflict so you can't
>  > install both at the same time (I tried to force it with "yum
>  > install libgcj.i386").
>  
>  Interesting. I have a brp script that will be installed in the
>  post install section of the rpm build to repack the jars with a
>  consistent time stamp. This should correct the problem with the
>  jar files.
>  
>  The man page conflict is new to me - there's probably a time stamp
>  or arch listing somewhere in them. A bug should be filed about this
>  problem. Let me know if you would like me to file it. 
There's still all the stuff in /usr/bin anyway.  That's going to be
different no matter what you do to it.

Cheers,
Gary

[Gary Benson]

Anthony Green wrote:
>  On Mon, 2006-07-31 at 09:58 +0100, Andrew Haley wrote:
>  > AFAIK it's the default yum behaviour: multilibbed libraries
>  > install all arches.  That seems a litttle weird, but there it
>  > is.
>  
>  Gary - do you think aot-compile-rpm could set LIBDIR based in part
>  on the output of "gcj-dbtool -p" ?  I think that would let us have
>  identical scripts in both the 32- and 64-bit packages. 
Ok, ftp://sources.redhat.com/pub/rhug/java-gcj-compat-1.0.62.tar.gz
does this.  Sorry for the wait...

Cheers,
Gary