Ritesh Raj Sarraf <r...@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
