Re: Embedded library copies - mergerfs
On Mon, Aug 7, 2017 at 8:30 AM, Antonio SJ Musumeci wrote: > My users span several generations of Debian (and other) Linux distributions. > Early 2.9.X versions of libfuse had bugs which led to "random" crashes. > These versions are still in wide use (I get 2.8.x users on occasion too). > Over past couple years I've spent countless hours tracking down issues > related to these buggy versions and helping (often inexperienced) users > upgrade their systems. This is the core reason I decided to embed libfuse > 2.9.7 into mergerfs. If faced with this situation myself, personally I think I would have marked those versions of libfuse as explicitly unsupported using both build and run time checks. People building from source would then need to backport libfuse before updating mergefs. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Embedded library copies - mergerfs
On Aug 07 2017, Antonio SJ Musumeci wrote: [libfuse] > There are secondary issues related to v2 being no longer maintained What makes you think so? I'm not adding new features, but it's definitely still being maintained. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Embedded library copies - mergerfs
I'm not sure that Ritesh did a good job of explaining why I've embedded libfuse2 into mergerfs. My users span several generations of Debian (and other) Linux distributions. Early 2.9.X versions of libfuse had bugs which led to "random" crashes. These versions are still in wide use (I get 2.8.x users on occasion too). Over past couple years I've spent countless hours tracking down issues related to these buggy versions and helping (often inexperienced) users upgrade their systems. This is the core reason I decided to embed libfuse 2.9.7 into mergerfs. There are secondary issues related to v2 being no longer maintained and v3 not being available to these same users and me still wanting newer features (which I can backport, or eventually could embed v3) or make changes that aren't upstream (see my recent comments regarding the thread pool management). I understand the situation from the distro / packaging perspective but I just don't see any alternatives which get me all the benefits. I've considered offering to take over 2.9.x maintainership but that doesn't get me backports to old platforms. I suppose I could make the embedded version optional but then the feature(s) I've added will be lost. That said... I have asks to support macOS so such changes would likely need to happen anyway unless I attempted to incorporate OSXFuse like I did with libfuse or created an explicit macOS fork. -Antonio
Re: Embedded library copies - mergerfs
On Mon, 2017-08-07 at 10:32 +0200, Nikolaus Rath wrote: > On Aug 07 2017, Ben Finney wrote: > > 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? > > libfuse upstream here. I am not aware of any open (non documentation- > ) > bugs reported by mergefs people. So by that criterion mergefs should > work just fine with the packaged libfuse. Thanks for mentioning that. I'll mention this to upstream folks for mergerfs. Ritesh -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: This is a digitally signed message part
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 signature.asc Description: This is a digitally signed message part
Re: Embedded library copies - mergerfs
On Aug 07 2017, Ben Finney wrote: > 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? libfuse upstream here. I am not aware of any open (non documentation-) bugs reported by mergefs people. So by that criterion mergefs should work just fine with the packaged libfuse. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Embedded library copies - mergerfs
Ritesh Raj Sarraf 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
Embedded library copies - mergerfs
mergerfs is a fuse based file system, similar in functionality to aufs and overlayfs. Since version 2.22.0, mergerfs is embedding the libfuse2 library in its source repo. Details can be seen in this bug report upstream at Github: https://github.com/trapexit/mergerfs/issues/431 So far upstream has stated that libfuse2 has many bugs, that has caused for the carrying of the library within. 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. libfuse is lacking in certain features I want. Given libfuse v2 is no longer maintained and libfuse3 either didn't or doesn't have the features either and mergerfs hasn't been ported to v3... embedding it was easier than forking it and expecting people to install my version. 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 ? -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: This is a digitally signed message part
