[ITP] FUSE 2.8
Tue Jul 26 18:13:00 GMT 2016
Adrien JUND writes:
> >You could define a package "fuse" with no contents and a dependency
> >package "winfsp-fuse". Then later when/if another FUSE
> >becomes available, "somebody" could replace the "fuse" package with
> >whatever is required to get alternatives support for the variants.
> I have not officially open request now but right after we found a
> solution to handle fuse wrapper packages,
> I will apply for dokan as well as winfsp.
> Also, I think that packages binary dependent to a fuse wrapper would
> if it is another wrapper that is installed.
> So shall we not just let the package dependent to fuse, explicit the
> wrapper that he will use ?
Erm, I'm belatedly comprehending it's two independent FUSE
implementations and not two versions with some common history. OK. If
there's a documented binary API at some level of the FUSE definition
that both implementations provide then that's what the proposed "fuse"
package could export. Both implementations would then independently
supply code that meets the API. I'm not sure how much extra work this
means for both projects.
If a common API-level interface is unworkable for whatever reason, then
we'll just have to live with two independent fuse implementations.
Tools like sshfs will have to be supplied by both projects and will only
work with the correct underlying FUSE implementation.
Something alternatives-like would be nice for an end user to switch
between implementations, but I don't know if that's workable. Should it
be possible to have both implementations installed at the same time?
More information about the Cygwin-apps