Web lists-archives.com

Re: Embedded library copies - mergerfs




On Mon, 2017-08-07 at 16:43 +1000, Ben Finney wrote:
> > 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?

Upstream said that there were many bugs in libfuse, which ultimately
led to fixing them and carrying the library embedded.

https://github.com/trapexit/mergerfs/issues/431#issuecomment-320512694

From their statement, they may not be interested in root causing issues
in mergerfs with external libfuse. Which effectively may leave Debian
with a buggy version; something I'd not be interested to maintain.


My plan is to let 2.21.0 remain in testing/sid and try newer versions,
only in Experimental. And then see how things progress, both upstream
and downstream.


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

Attachment: signature.asc
Description: This is a digitally signed message part