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