[dm-devel] multipath-tools: Debian patches

Tue Jun 6 19:21:25 UTC 2023

On Tue, 2023-06-06 at 18:48 +0200, Chris Hofstaedtler wrote:
> Hi,
> 
> * Martin Wilck <mwilck at suse.com> [230606 17:18]:
> > On Mon, 2023-06-05 at 21:59 +0200, Xose Vazquez Perez wrote:
> > > Hi,
> 
> > I have no Debian salsa account, so I reply here, trying to reach
> > Chris
> > via email.
> 
> (not sure where this mail thread started, I don't see the first mail
> in the dm-devel archives)

It started off-list, but I thought this should rather be a public
discussion. I hope that's ok for everybody.

> 
> > > A complaint about upstream, "Remove library development files and
> > > all
> > > of libdmmp":
> > > https://salsa.debian.org/linux-blocks-team/multipath-tools/-/commit/8c46661697d757763192d8e011c9ad53358d20b7
> 
> FTR, I don't consider this a "complaint".
> 
> This commit mostly exists to rectify a few Debian-specific, historic
> issues:
> 
> 1) we ship(ped) libraries in the daemon package. This would be okay,
> if the libraries are private libs, but given libmpathpersist exists,
> they are clearly not private.
> 
> 2) we install(ed) various files into old non-/usr paths. These were
> mostly the pkg-config, headers and .so files. For Debian reasons, we
> cannot "just move them" (yet) into /usr, however at the same time
> there existence is a (Debian-specific) problem in the future.
> 
> Given there are currently no users in Debian for any of these, it
> was easiest to remove all the development files.
> 
> If and when other packages in Debian want to use the libs, the
> packaging will have to become a lot more complicated.
> 
> > If Chris has followed the upstream discussion, he is probably aware
> > that we do care about the ABI. We don't keep the libmultipath ABI
> > stable, but track it using ABI versioning.
> 
> I was only vaguely aware of the changes in the <lib>.version files,
> and that all .so files are ".so.0".
> From a quick glance it looks like libmultipath.so.0 from 0.9.4
> exports a lot of symbols versioned @LIBMULTIPATH_17.0.0, but f.e.
> none versioned @LIBMULTIPATH_15.0.0, but the soname didn't change.

Maybe Debian enforces additional policies I'm unaware of, but
technically, the soname, or filename based library versioning, doesn't
matter if symbol versioning is used [1]. Symbol versioning can be used
in different ways. For libmultipath, we don't attempt to provide
multiple backward-compatible ABIs. We just want to avoid undefined
behavior which would result from an executable calling a library
routine with a different version of the ABI, and this is what our
library versioning scheme achieves. The idea is similar to the kernel's
symvers mechanism, which avoids loading binary-incompatible modules.

> So - I'm not sure if, for a Debian library package, it is okay to do
> essentially drop symbols without a new soname.

I can't tell for Debian, but other distributions haven't complained so
far. I don't think that multipath-tools is the only project that uses
symbol versioning this way.

> 
> > It is true that most of the
> > libmultipath headers are not used for other projects. Not
> > installing
> > any headers except the public ones makes sense, actually.
> > 
> > The libmpathpersist API (LIBMPATHPERSIST_2.1.0) that's used by qemu
> > is
> > supposed to remain stable. We have moved those parts of the ABI
> > that
> > used to be more volatile into __LIBMPATHPERSIST_INT_1.0.0.
> > 
> > Therefore it makes sense to keep shipping mpath_persist.h and drop
> > the
> > rest. If that works for Debian, it will probably work for other
> > distros, too.
> 
> I haven't tried building anything against libmpathpersist, but
> wouldn't people also need libmultipath.so, and thus transitively
> link in libmultipath.so.0, possibly using its symbols?

The libmultipath data structures that libmpathpersist uses are set up
in libmpathpersist, they are opaque to the calling application.
libmpathpersist will require versioned symbols from libmultipath, and
if these don't match, runtime linking will fail. So if you ship
libmpathpersist with a matching libmultipath, you should be fine.

As Ben noted, the same holds for libmpathvalid and libmpathcmd. We
continuously test our ABI using abigail.

On rpm-based distributions,package management will be able to figure
out this kind of (in)compatibility, albeit in a more coarse-grained way
(e.g. the multipathd package requires
libmpathpersist.so.0(LIBMPATHPERSIST_2.1.0)(64bit), which must match
the provided features of the library package). I suppose something
similar exists in the Debian realm, too.

> > libdmpp comes from Red Hat, perhaps Ben knows whether it is still
> > used
> > by any alive project. It does have a stable API/ABI.
> 
> I couldn't find any users in Debian, so it didn't seem useful to
> keep shipping it.

Sure. It's your decision. Time will tell if anyone complains. IIRC the
purpose of libdmmp was to provide a stable API for 3rd-party
applications to use.

> > > And maybe these are relevant for upstream ( repo:
> > > https://salsa.debian.org/linux-blocks-team/multipath-tools/-/tree/master/debian/patches
> > >  ):
> > > 
> > > https://udd.debian.org/patches.cgi?src=multipath-tools&version=0.9.4-3
> > > 
> > 
> > That's not how we work. We don't pick downstream patches. If
> > something's wrong with the upstream code, we'll happily discuss
> > patches
> > from the Debian project, preferably here on dm-devel.
> 
> I think most of these patches are not useful for upstream. Do you
> care about our historic install paths?
> 

Historic - no. But in general we have the goal that distributions
should be able to customize install paths using make variables, without
having to resort to patching.

Thanks,
Martin

[1] https://akkadia.org/drepper/dsohowto.pdf