Re: [fuse-devel] Do I need to support both - libfuse2 and libfuse3 in my application in order to work on more Linux distros, in case I deploy libfuse with my application

[Cyril C. <cyr...@gm...>]

That was really helpful, thank you!

On Tue, Oct 1, 2019 at 4:25 PM Antonio SJ Musumeci <tra...@sp...> wrote:
>
> https://github.com/libfuse/libfuse/blob/master/include/fuse_common.h#L128
>
> On 10/1/2019 9:17 AM, Cyril Cyrov wrote:
> >> All new features are optional and established at the FUSE_INIT phase
> > Which are those "all new features"? I mean, what features could be
> > unsupported by the kernel?
> >
> > On Tue, Oct 1, 2019 at 3:58 PM Cyril Cyrov <cyr...@gm...> wrote:
> >> Yes, I think I totally get your point.
> >>
> >> My point of view is - building libfuse3 on older systems is possible
> >> and it cost me like 2-3 hours to build the necessary tools. Packing
> >> fusermount3 in the installer also doesn't sound so hard - we already
> >> do deploy libfuse.so, that's just one ore file. And finally, patching
> >> in order to find the fusermount3 binary - this seems like a trivial
> >> patch.
> >> Also given the fact, that we rarely update fuse versions, this effort
> >> seems to worth it.
> >>
> >> My two concerns, that I still have, are:
> >> 1) is there any security risk in deploying fusermount3 and should I do
> >> anything special, except just copy the binary into the installer?
> >> 2) how will I understand that the kernel is too old for some feature,
> >> that I need (I get it, that it's during the FUSE_INIT phase, I'll have
> >> to read more about this).
> >>
> >> On Tue, Oct 1, 2019 at 3:19 PM Antonio SJ Musumeci <tra...@sp...> wrote:
> >>> You can optionally deploy it or patch the build to install to a
> >>> different location / filename.
> >>>
> >>> This is what I was getting at prior. The library is not designed to be
> >>> used this way so without upstreaming some changing that make it easier
> >>> to do so you'll have to maintain some part of the setup.
> >>>
> >>> My biggest problem with embedding libfuse3 was the build system simply
> >>> not working on older platforms and getting that replaced or officially
> >>> supporting multiple systems doesn't seem a reasonable ask.
> >>>
> >>> On 10/1/2019 7:31 AM, Cyril Cyrov wrote:
> >>>> Actually, deploying `libfuse3.so` won't be enough, deploying
> >>>> `fusermount3` is also necessary (+ building libfuse with `-D
> >>>> FUSERMOUNT_DIR=.....`)? Isn't this some kind of a security issue
> >>>> (deploying fusermount3)?
> >>>>
> >>>> On Tue, Oct 1, 2019 at 1:53 PM Cyril Cyrov <cyr...@gm...> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Here's an introduction for this thread:
> >>>>> https://github.com/libfuse/libfuse/issues/460
> >>>>>
> >>>>> Long story short:
> >>>>> Q: How can I support both libfuse2 and libfuse3 in order to make my
> >>>>> app work on more Linux distos?
> >>>>> A: You don't need to do that.
> >>>>>
> >>>>> So, continuing the discussion here.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> My misunderstanding comes from the fact, that I though there are two
> >>>>> different kernel modules for the two versions and that libfuse3 can
> >>>>> only work on Linux distros, which do have `fuse3` package installed
> >>>>> (and these distros are just a few). This misunderstanding was also
> >>>>> supported by the fact, that libfuse3 needs fusermount3 in order to
> >>>>> create a mountpoint.
> >>>>>
> >>>>> Another miscommunication occurred by the different interpretation of
> >>>>> "patching the fuse implementation" and "embedding" fuse.
> >>>>>
> >>>>> We do deploy a libfuse shared object with our application. So, this is
> >>>>> not an issue at all.
> >>>>>
> >>>>> My concern was - can I use and deploy libfuse3 on older Linux distros,
> >>>>> like CentOS 6, for example?
> >>>>>
> >>>>> What confuses me further is that I cannot find any matching between
> >>>>> libfuse versions and kernel versions, explaining which libfuse version
> >>>>> is compatible with which kernel versions.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> @trapexit
> >>>>>> Then you'll have to deal with the distro's support
> >>>>> By "avoid patching the fuse implementation" I didn't mean I don't want
> >>>>> to deploy fuse build, I just misunderstood you and thought that you
> >>>>> suggest actually making some source patch in order to "merge" them
> >>>>> somehow. Sorry for the misleading.
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> @Nikratio:
> >>>>>> "Why don't you ship two binaries (one for libfuse2 and one for libfuse3) together with a small wrapper that picks with version to use?"
> >>>>> This will be necessary only if we don't deploy a build for libfuse, correct?
> >>>>>
> >>>>> ---
> >>>>>
> >>>>> So, I'll try to wrap things up, please correct me if I'm wrong - appreciated!
> >>>>>
> >>>>> We can actually use only libfuse3 and if we deploy it (or statically
> >>>>> link it in our application) this should work fine all Linux distros,
> >>>>> which otherwise would work fine with libfuse2. Is that correct?
> >>>>> Also, is there a way to find out which libfuse3 features depend on
> >>>>> which Linux kernel, in order to work fine?
> >>>>>
> >>>>> Thanks,
> >>>>> Kiril
> >>>
> >>> --
> >>> fuse-devel mailing list
> >>> To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel