Adrien JUND writes: > >You could define a package "fuse" with no contents and a dependency on > >package "winfsp-fuse". Then later when/if another FUSE implementation > >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? ..mark -- captcha: homely
