[ITP] FUSE 2.8

Mark Geisert mark@maxrnd.com
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 
not work
> 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?


captcha: homely

More information about the Cygwin-apps mailing list