Hi, * Martin Wilck <mwilck@xxxxxxxx> [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) > > 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. So - I'm not sure if, for a Debian library package, it is okay to do essentially drop symbols without a new soname. > 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? > 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. > > 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? Chris -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
