Re: Embedded library copies - mergerfs

[Ben Finney <bignose@debian.org>]

Ritesh Raj Sarraf <rrs@debian.org> writes:

> To quote upstream:
> It embeds libfuse because:
>
> I support many old platforms which use old and buggy versions of
> libfuse. Embedding it keeps many of my users who don't know and don't
> care to know how to update their systems from having to learn to build
> libfuse themselves.

This is a choice that developer can make, to take extra burden of
maintaining a bundled third-party library.

We can disagree whether it's overall a good thing (it makes security
updates more difficult than they need to be, etc.) but the developer is
clearly meeting a need expressed by the users of the software.

You can try to persuade them otherwise, but such persuasion should bear
in mind the developer is knowingly accepting the *work* of maintaining
that bundled ‘libfuse’ library.

> So far, in Debian, I've pushed version 2.21.0. The last version
> without the embedded library.
>
> Any advise on what should be our take further ?

You have correctly identified that the embedded library should not be
used in Debian, and instead the Debian ‘mergerfs’ package should use
only the first-class Debian ‘libfuse’ package.

By your description, the upstream code doesn't do that. One obvious
workaround is to remove the embedded library in the Debian ‘mergerfs’
package ‘clean’ target, patch the software to instead use Debian's
packaged ‘libfuse’ library, and maintain that patch in the Debian
‘mergerfs’ package, indefinitely.

There may be some upstream changes that you could suggest which would
make that easier. Could a bit of refactoring in ‘mergerfs’ allow for an
easily configurable ‘libfuse’ location? Could those changes be made
acceptable by the upstream developer?

-- 
 \     “The cost of a thing is the amount of what I call life which is |
  `\       required to be exchanged for it, immediately or in the long |
_o__)                                       run.” —Henry David Thoreau |
Ben Finney