Hello, could someone help me understand the rules about file conflicts and debuginfo packages?
I thought there was a rule that if the 32-bit and 64-bit versions of a package provide the same file, then the file's contents must be identical in both packages, with an exception for binary executable files in standard locations like /usr/bin. Now I've noticed that lots of debuginfo packages seem to be violating this rule. The debuginfo packages put files in /usr/lib/debug/usr/bin and similar directories, and the exception doesn't seem to apply to these directories, because RPM complains about conflicts when I try to install both architecture versions of a debuginfo package.
I don't see that I as a packager can do anything to prevent these conflicts. Shall I conclude that I don't need to care about conflicts between architecture versions of debuginfo packages? Or shall I try to avoid conflicts in debuginfo packages for libraries, but not for programs? I think I can avoid debuginfo conflicts in packages that provide only libraries, but maybe I shouldn't bother?
Björn Persson
On Tue, 2009-11-10 at 00:01 +0100, Björn Persson wrote:
I don't see that I as a packager can do anything to prevent these conflicts. Shall I conclude that I don't need to care about conflicts between architecture versions of debuginfo packages? Or shall I try to avoid conflicts in debuginfo packages for libraries, but not for programs? I think I can avoid debuginfo conflicts in packages that provide only libraries, but maybe I shouldn't bother?
debuginfo packages cannot be multilib, that is why we don't offer them multilib.
Jesse Keating wrote:
On Tue, 2009-11-10 at 00:01 +0100, Björn Persson wrote:
I don't see that I as a packager can do anything to prevent these conflicts. Shall I conclude that I don't need to care about conflicts between architecture versions of debuginfo packages? Or shall I try to avoid conflicts in debuginfo packages for libraries, but not for programs? I think I can avoid debuginfo conflicts in packages that provide only libraries, but maybe I shouldn't bother?
debuginfo packages cannot be multilib, that is why we don't offer them multilib.
I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts.
Björn Persson
=?iso-8859-15?q?Bj=F6rn_Persson?= bjorn@xn--rombobjrn-67a.se writes:
debuginfo packages cannot be multilib, that is why we don't offer them multilib.
I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts.
Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel.
- FChE
Frank Ch. Eigler (fche@redhat.com) said:
I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts.
Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel.
Not unless someone changes the layout of debuginfo entirely, as they use common paths:
/usr/src/debug/<source tree name> /usr/lib/debug/usr/bin/...
Bill
On Tue, Nov 10, 2009 at 02:25:16PM -0500, Bill Nottingham wrote:
Frank Ch. Eigler (fche@redhat.com) said:
I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts.
Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel.
Not unless someone changes the layout of debuginfo entirely, as they use common paths:
/usr/src/debug/<source tree name> /usr/lib/debug/usr/bin/...
Currently you can install say on x86_64 either a i686, or x86_64 debuginfo package, but not both.
Jakub
Jakub Jelinek jakub@redhat.com writes:
[...]
Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel.
Not unless someone changes the layout of debuginfo entirely, as they use common paths:
/usr/src/debug/<source tree name>
Right, that's a complication. (It could be handled by suffixing the arch in the source-tree-name part.)
/usr/lib/debug/usr/bin/...
Considering that the same files are also linked into multilib-safe collision-free /usr/lib/debug/.build-id files, where debuggers already know to look for them, the .../usr/bin* ones could be deprecated. Or the conflicting /bin files could be moved to a separate non-library subpackage.
I hope it is obvious that it would be appropriate to be able to debug anything installed from the normal repositories. That the status quo is not quite up to the job (in the case of some multilib libraries) is a bug.
- FChE
Bill Nottingham wrote:
Frank Ch. Eigler (fche@redhat.com) said:
I'm guessing that "we don't offer them multilib" means that 32-bit debuginfo packages aren't meant to be installed on 64-bit systems, so I'll take this to mean that I shouldn't bother doing anything to avoid conflicts.
Well, hold on, debuginfo for multilib'd libraries like glibc should be absolutely installable in parallel.
Not unless someone changes the layout of debuginfo entirely, as they use common paths:
/usr/src/debug/<source tree name>
I think can handle those. For true source code files there is no problem, because they will be identical in both packages. Generated files can be placed in separate subdirectories, for example /usr/src/debug/<source tree name>/%{_arch}. This may of course require more or less complicated patches to makefiles or other build scripts. I'm trying to find out wheter I should do this.
/usr/lib/debug/usr/bin/...
Those are the ones I can't do anything about on my own, but perhaps the same exception could be applied there as in /usr/bin?
Björn Persson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Björn Persson wrote:
I think can handle those. For true source code files there is no problem, because they will be identical in both packages. Generated files can be
placed
in separate subdirectories, for example /usr/src/debug/<source tree name>/%{_arch}. This may of course require more or less complicated patches to makefiles or other build scripts. I'm trying to find out wheter I should do this.
For KDE4 builds (which should also work for any CMake system as well) is (not copy-paste ready):
mkdir %{_target_platform} pushd %{_target_platform} cmake .. popd make -C %{_target_platform}
This ensures all of the generated files are in a separate directory. I'm not sure how this would work with autotools since I don't use them.
- --Ben
On Wed, 11 Nov 2009 04:14:49 +0100, Frank Ch. Eigler wrote:
(It could be handled by suffixing the arch in the source-tree-name part.)
...
Considering that the same files are also linked into multilib-safe collision-free /usr/lib/debug/.build-id files, where debuggers already know to look for them, the .../usr/bin* ones could be deprecated.
/usr/lib/debug/path/name.debug were kept only as backward compatibility symlinks possibly wrong for multi-arch/multi-version installed packages.
Implemented as a postinstall script but it would be more right to resolve it by rpm coloring as is being done for the real /bin/* multilib files.
I hope it is obvious that it would be appropriate to be able to debug anything installed from the normal repositories. That the status quo is not quite up to the job (in the case of some multilib libraries) is a bug.
I sometimes hit it having to uninstall a x86_64 debuginfo and temporarily replace it by its i686 variant.
On Tue, 10 Nov 2009 22:15:47 +0100, Björn Persson wrote:
Generated files can be placed in separate subdirectories, for example /usr/src/debug/<source tree name>/%{_arch}.
My patch uses there: /usr/src/debug/name-version-release.arch
It was here, unaware how it is still applicable now: http://people.redhat.com/jkratoch/multidebug/
But Roland McGrath had some more general debuginfos plans but I think that temporary hack of mine could be worth the two years of Fedoras. Roland, does it make sense to revive + improve this patch?
Thanks, Jan
Jan Kratochvil wrote:
On Tue, 10 Nov 2009 22:15:47 +0100, Björn Persson wrote:
Generated files can be placed in separate subdirectories, for example /usr/src/debug/<source tree name>/%{_arch}.
My patch uses there: /usr/src/debug/name-version-release.arch
Duplicating the entire source tree seems a bit wasteful when it's only generated files that sometimes need to be separated, but I suppose that's the only way if you want to do it without patching makefiles in numerous packages.
Björn Persson
-
Ben Boeckel -
Bill Nottingham -
Björn Persson -
Frank Ch. Eigler -
Jakub Jelinek -
Jan Kratochvil -
Jesse Keating