libdevmapper1.02.1 depends on dmsetup since version 2.02.66-2. The
dependency was added to fix #585786. There, the issue was that the
libdevmapper1.02.1 version did not match the dmsetup version. As a
result, this dependency was added.

However, shared libraries should not depend on tools. The higher level
users of libraries should have these dependencies. In this case,
libdevmapper1.02.1 does not actually need a matching dmsetup to be
useable. It should prevent installing a dmsetup of a different version
though. The correct relationship for achieving that is Breaks.

The changelog argues that libdevmapper1.02.1 needs udev rules. That is a
red herring as neither libdevmapper1.02.1 nor dmsetup depends on udev.
The presence of the rules is only relevant if udev happens to be
installed.

As such I propose to change libdevmapper1.02.1's "Depends: dmsetup (>=
${devmapper:Version}~)" to "Breaks: dmsetup (<< ${devmapper:Version}~)".

This has practical relevance. systemd depends on libcryptsetup12, which
depends on libdevmapper1.02.1, which depends on dmsetup. Therefore
systemd always pulls dmsetup. This is undesirable for embedded systems
and container images.

Helmut

There is already a bug report about this, merging.

libdevmapper1.02.1 needs the udev rules, the udev rules need dmsetup,
dmsetup needs libdevmapper1.02.1.

There is no way around this.

Container images don't contain systemd, so no problem.  Embedded systems
contain udev, so require the udev rules.

Bastian

Hi Bastian,

I think there is a subtle difference between these. The old bug is about
a dependency cycle, which presents issues to a package manager. The new
bug is about an excessive dependency which results in issues for
container and embedded images. I do agree that solving the new bug
implicitly solves the old one, but I could imagine solutions to the old
bug that do not solve the new bug. Hence I figured that filing these
separately would make sense. Your preference seems to handle them as
one, which effectively is a scope increase of the old one.

This is technically incorrect on two levels. First, libdevmapper1.02.1
may need udev rules in order for the functions it provides to work.
Applications may link libdevmapper1.02.1 as to provide an optional
feature however. For them, the shared library is sufficient to run the
application unless they also want to use the optional feature. In the
latter case, they'd have to depend on dmsetup (and udev).

Then, while dmsetup provides the udev rules, it does not depend on udev.
As such, the rules are mere text files without anything to act upon. The
udev rules rightly provide optional integration with udev. Therefore, we
can rule that the present dependency on dmsetup does not provide the
guarantee it is supposed to provide. Even with dmsetup installed (but
udev missing) libdevmapper1.02.1 may not work as the udev rules are not
applied by anything.

As presented, the matter is more nuanced than you think it is.

This also is technically incorrect. nspawn containers require installing
systemd-container in the container image. While embedded systems usually
contain udev, they do not necessarily need dmsetup.

Helmut

Hi Helmut

Exactly, it requires working udev and udev rules for it's primary
function.  To change that, it either needs
- to be split into two libraries, one with the stuff that needs udev
  rules, one for the stuff without or
- runtime detection if udev can work.

Maybe.  Please provide a patch to fix this problem, without touching
every piece of software that, directly or indirectly, links against
libdevmapper.

Because the dependency on libdevmapper1.02.1 can only go after systemd
(or maybe libcryptsetup) got it.

Bastian

Hi Bastian,

I fear that you still get "primary function" wrong. In many cases, the
primary function of a shared library is being able to load it and then
not calling any of its functions. It may be unfortunate, but that's how
we integrate optional features from shared libraries.

Or maybe it can quite simply fail to work if the udev rules are not
invoked. Demoting the dependency is not a regression in this aspect as
libdevmapper1.02.1 already does not depend on udev, so there already is
no requirement on invoking the udev rules. I'm just asking for also
skipping dmsetup.

I'm attaching the obvious patch. I think that we don't actually need to
touch other pieces of software, because it is quite difficult to get a
system without dmsetup. This bug is not about making many systems lack
dmsetup, but about making it possible at all.
 * dmsetup is still recommended by libdevmapper1.02.1, so you need to
   turn off Recommends.
 * dmsetup is pulled by lvm2 and cryptsetup.
 * Given that systemd is important and transitively depends on dmsetup
   at present, we can elevante dmsetup's priority without regressing
   anything. That way it remains part of a default debootstrap.
 * The actual bug that introduced the dmsetup dependency was about a
   mismatched version of dmsetup and libdevmapper1.02.1. Such a
   situation is prevented by suitable Breaks.

Neither actually need it unconditionally. We really want to be able to
install systemd without dmsetup. That's the highlevel goal of this bug
here.

Helmut

Hi Helmut

The primary function is to introspect and modify the kernel device
mapper.  It does that by asking udev to do the magic, hence it needs
udev rules.

It is able to distinguish between udev missing and udev available, but
not between working udev and broken udev.  So the availability of both
the rules and dmsetup is not optional.  I don't pretend what
libdevmapper does in udev context is nice, but I assume upstream checked
other solutions as well.

Please provide a patch and get it applied upstream.  Hint, the kernel
interface and udev is asynchron, so you have no obvious "fail to work".
is installed but broken (not running, not providing the necessary
feedback).

I can off course merge dmsetup and the whole udev rule stuff into
libdevmapper, make it an integral part, and kill co-instabillity of
different libdevmapper versions alltogether.

No, this is wrong as it breaks various parts of libdevmapper.  The
library will just block in a lot of functions if the udev stuff is
missing and may even leave the user with a non-booting system.  Sorry,
I'm not going to risk breaking all of that for a marginal size
reduction.

Bastian