Hello,
How are the multilib conflicts tested? I'd like to verify that there are no conflicts anymore before building.
Also will this be extended to binary files?
And last what to do when the conflict is 'logical'? I have 2 examples in the bes package:
* there is a bes-config file which specifies the directory where dlopened backend modules are, this is a %_libdir subdirectory, so, it is logical to have a difference between arches.
* in the /etc/bes/bes.conf file there is also a conflict because in that file the dlopened modules are specified, and therefore the libdir is different.
Any idea?
-- Pat
Patrice Dumas (pertusus@free.fr) said:
How are the multilib conflicts tested? I'd like to verify that there are no conflicts anymore before building.
Install x86_64 package. Then, in separate transaction, install i386 package.
Also will this be extended to binary files?
Depends. ELF files? No. Other binary files? (data, etc.) - yes.
And last what to do when the conflict is 'logical'? I have 2 examples in the bes package:
- there is a bes-config file which specifies the directory where dlopened backend modules are, this is a %_libdir subdirectory, so, it is logical to have a difference between arches.
The general way to do this is making the *-config script call pkg-config.
- in the /etc/bes/bes.conf file there is also a conflict because in that file the dlopened modules are specified, and therefore the libdir is different.
That's a problem.
Bill
On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
- in the /etc/bes/bes.conf file there is also a conflict because in
that file the dlopened modules are specified, and therefore the
libdir
is different.
That's a problem.
You can use $LIB in the path to dlopen iirc
Jeremy
On Mon, Oct 22, 2007 at 03:32:11PM -0400, Jeremy Katz wrote:
On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
- in the /etc/bes/bes.conf file there is also a conflict because in
that file the dlopened modules are specified, and therefore the
libdir
is different.
That's a problem.
You can use $LIB in the path to dlopen iirc
The idea upstream is to specify the full path such that users may place files to be dlopened anywhere and it seems to me that it makes sense, especially since some may be packaged and other site specific (and in the case of bes, it makes much sense to have site specific software that is not meant to be packaged even if it is free software, for example if there is acquisition of data in real time or the like).
-- Pat
On Mon, 2007-10-22 at 22:33 +0200, Patrice Dumas wrote:
On Mon, Oct 22, 2007 at 03:32:11PM -0400, Jeremy Katz wrote:
On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
- in the /etc/bes/bes.conf file there is also a conflict because in
that file the dlopened modules are specified, and therefore the
libdir
is different.
That's a problem.
You can use $LIB in the path to dlopen iirc
The idea upstream is to specify the full path such that users may place files to be dlopened anywhere and it seems to me that it makes sense, especially since some may be packaged and other site specific (and in the case of bes, it makes much sense to have site specific software that is not meant to be packaged even if it is free software, for example if there is acquisition of data in real time or the like).
If people are adding site-specific bits, then having them add a full path is perfectly reasonable. But in the configuration that we ship, it makes a lot more sense to have paths=/usr/$LIB/libfoo.so /usr/$LIB/libbar.so
and then the right thing will happen depending on whether or not you're running a 32bit or a 64bit binary.
Jeremy
On Mon, Oct 22, 2007 at 04:43:49PM -0400, Jeremy Katz wrote:
If people are adding site-specific bits, then having them add a full path is perfectly reasonable. But in the configuration that we ship, it makes a lot more sense to have paths=/usr/$LIB/libfoo.so /usr/$LIB/libbar.so
and then the right thing will happen depending on whether or not you're running a 32bit or a 64bit binary.
Right, I didn't understood how it works. I'll propose that upstream. Thanks.
-- Pat
Patrice Dumas wrote:
On Mon, Oct 22, 2007 at 03:32:11PM -0400, Jeremy Katz wrote:
On Mon, 2007-10-22 at 14:39 -0400, Bill Nottingham wrote:
- in the /etc/bes/bes.conf file there is also a conflict because in
that file the dlopened modules are specified, and therefore the
libdir
is different.
That's a problem.
You can use $LIB in the path to dlopen iirc
The idea upstream is to specify the full path such that users may place files to be dlopened anywhere and it seems to me that it makes sense, especially since some may be packaged and other site specific (and in the case of bes, it makes much sense to have site specific software that is not meant to be packaged even if it is free software, for example if there is acquisition of data in real time or the like).
Another possibility is to copy what pango does: /etc/pango/i686-redhat-linux-gnu/pango.modules /etc/pango/x86_64-redhat-linux-gnu/pango.modules
-Toshio
On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
Patrice Dumas (pertusus@free.fr) said:
How are the multilib conflicts tested? I'd like to verify that there are no conflicts anymore before building.
Install x86_64 package. Then, in separate transaction, install i386 package.
I can't do that in my system since I have an i386. Were the bugreports done that way?
Also will this be extended to binary files?
Depends. ELF files? No. Other binary files? (data, etc.) - yes.
Ok. My personal opinion is that it would be better to extend to ELF files too, but there is considerable controversy on that subject, and on how to fix the multiarch issue.
And last what to do when the conflict is 'logical'? I have 2 examples in the bes package:
- there is a bes-config file which specifies the directory where dlopened backend modules are, this is a %_libdir subdirectory, so, it is logical to have a difference between arches.
The general way to do this is making the *-config script call pkg-config.
Ok. This requires collaboration with upstream, but it is worth pursuing.
-- Pat
Patrice Dumas (pertusus@free.fr) said:
On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
Patrice Dumas (pertusus@free.fr) said:
How are the multilib conflicts tested? I'd like to verify that there are no conflicts anymore before building.
Install x86_64 package. Then, in separate transaction, install i386 package.
I can't do that in my system since I have an i386. Were the bugreports done that way?
Yes. Alternatively, unpack both the i386 and x86_64 packages with rpm2cpio and diff them.
Bill
On Mon, 2007-10-22 at 16:38 -0400, Bill Nottingham wrote:
Patrice Dumas (pertusus@free.fr) said:
On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
Patrice Dumas (pertusus@free.fr) said:
How are the multilib conflicts tested? I'd like to verify that there are no conflicts anymore before building.
Install x86_64 package. Then, in separate transaction, install i386 package.
I can't do that in my system since I have an i386. Were the bugreports done that way?
Yes. Alternatively, unpack both the i386 and x86_64 packages with rpm2cpio and diff them.
Or even easier is to use a script like http://katzj.fedorapeople.org/multilib-cmp.py
Jeremy
On Mon, Oct 22, 2007 at 04:38:03PM -0400, Bill Nottingham wrote:
Patrice Dumas (pertusus@free.fr) said:
On Mon, Oct 22, 2007 at 02:39:34PM -0400, Bill Nottingham wrote:
Patrice Dumas (pertusus@free.fr) said:
How are the multilib conflicts tested? I'd like to verify that there are no conflicts anymore before building.
Install x86_64 package. Then, in separate transaction, install i386 package.
I can't do that in my system since I have an i386. Were the bugreports done that way?
Yes. Alternatively, unpack both the i386 and x86_64 packages with rpm2cpio and diff them.
That's what I do currently, but manually. I'll try to see what I can do with a scratch build, automatic download and rpm2cpio followed by a diff...
-- Pat
-
Bill Nottingham -
Jeremy Katz -
Patrice Dumas -
Toshio Kuratomi