Re: [Elftoolchain-developers] filename conflicts with RedHat/mr511.de libelf

[Joseph K. <jk...@us...>]

> One of the problems I have with packaging libelf for Debian is that the
> installed files would conflict with those in the libelfg0[-dev] and the
> libelf[1|-dev] packages already in Debian.  These are built from libelf
> (from mr511.de) and elfutils (from RedHat) respectively.

> 1. I will have to change the 'source' package names to not conflict with
> these (I choose libbsdelf: http://bugs.debian.org/473188 but that can be
> changed if we wish to, so suggestions are welcome).  If libelf and the
> rest of the ELF toolchain will always be distributed as a single unit, I
> can use elftoolchain as the source package name.

> 2. To handle the conflict of files, we could declare a "Conflict" of
> installation of these packages with those that we build.  However this
> means that software that is linked to these existing packages cannot
> co-exist with our installed libraries.  This includes the following:

> elfutils - collection of utilities to handle ELF objects
> bug-buddy- GNOME Desktop Environment bug reporting tool
> ltrace - Tracks runtime library calls in dynamically linked programs
> prelink - ELF prelinking utility to speed up dynamic linking
> scsh-0.6 - A `scheme' interpreter designed for writing system programs
> mpatrol(c2) - A library for debugging memory allocations
> 
> libelf1 and libelfg0 (the shared library packages) are able to coexist
> right now because they ship /usr/lib/libelf.so.1 and
> /usr/lib/libelf.so.0 but they are certain to conflict when libelfg0 gets
> a SONAME bump.
> 
> libelf-dev and libelfg0-dev already declare a Conflict on each other and
> there is no way out (they install files with conflicting names in the
> same area).
> 
> So this business is messy.  Koshy, is it OK if I continue with this and
> declare "Conflict" between the packages?  How do FreeBSD and NetBSD
> handle this?

One suggestion could be to name the installed library "libbsdelf"
on Linux.  The <libelf.h> and <gelf.h> headers could then be installed
in a non-conflicting location [/usr/include/bsd/ (say) or whereever
other headers of BSD lineage reside].  The synopsis in the elf.3
manual page would also need to be updated to reflect the new
locations.

Our tools could get installed with a "bsd" prefix (e.g., bsdar, bsdnm,
etc.) and all should hopefully be well.

NetBSD pkgsrc would have similar conflicts as Debian/GNU Linux till
the time libelf enters the base system.

On FreeBSD the GNU library installs under $LOCALBASE (i.e.,
/usr/local/), while the native library goes into /usr/lib/.  The
headers end up in $LOCALBASE/include [gnu libelf] and /usr/include/
[native], so there is no conflict.

Koshy