[dm-devel] [PATCH v2 03/48] libmultipath: add optional wakeup functionality to lock.c

[Martin Wilck]

On Tue, 2021-11-30 at 21:28 +0100, Martin Wilck wrote:
> On Tue, 2021-11-30 at 10:52 -0600, Benjamin Marzinski wrote:
> > On Mon, Nov 29, 2021 at 09:52:49PM +0100, Martin Wilck wrote:
> > > I agree. Also, I realize that we've bumped the library version
> > > too
> > > often in the past. If we add a function, we don't need to bump.
> > > Because
> > > a program that needs the added function will require e.g.
> > > foo at LIBMULTIPATH_10.0.0, and this will fail for a library that
> > > doesn't
> > > export foo (which is what we want). Likewise for function
> > > deletion
> > > - a
> > > program that calls the deleted function will fail to link with
> > > the
> > > updated library. OTOH, programs that use this version of the ABI
> > > *without* using the functions which are added or removed are
> > > unaffected
> > > by the addition / removal.
> > > 
> > > The only case in which the ABI version must be bumped is when we
> > > have
> > > changed functions or data structures.
> > > 
> > > Furthermore, I believe now that the habit (which I introduced) to
> > > list
> > > added functions at the end of the .version files, with comments
> > > indicating when they were added, is useless. We should rather
> > > keep
> > > the
> > > .version file ordered alphabetically.
> > 
> > So we not use the minor version anymore? 
> 
> Perhaps we'll encounter another use case for it, or we find a flaw in
> my reasoning above. I wouldn't remove the digit.

And here's the flaw: While my argument above is valid for ld.so, it's
not for package management tools like rpm. Here on openSUSE, we got rpm
Requires like "libmultipath.so.0(LIBMULTIPATH_13.0.0)(64bit)". As
distributors, we prefer incompatibilities to be detected at
installation time rather than at runtime. So, we do need the minor
version bumps.

Martin