> 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
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.