On 7/25/16, 11:27 PM, Mark Geisert wrote:
>Bill Zissimopoulos writes: >> - Rename the package to winfsp-fuse, but have it somehow “satisfy” >> packages that require “fuse” (e.g. SSHFS, FUSEPY). This would allow >> multiple *-fuse packages to exist in the setup database and the user >> chooses which one they want. My understanding based on Marco’s answer is >> that this is not currently supported by Cygwin’s dependency system. > >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. BTW, here is another alternative that I have been mulling around. I can take the current Cygwin package source, place it under a liberal license like the BSD and create a separate project out of it. The intent of the new project would be to support different FUSE solutions for Windows using a *single* package. Currently it only supports WinFsp, but it could be modified to support Dokany or other solutions. There are many benefits to such an approach IMO: - A single FUSE package and a single cygfuse.dll. - Works out of the box with all supported Windows user mode file system solutions. - No changes in Cygwin’s dependency system or setup.exe required. - No user confusion. The current FUSE package is actually very simple. It looks in the registry to see if/where WinFsp is installed and then loads the WinFsp DLL using dlopen and the WinFsp-FUSE symbols using dlsym. Presumably the same technique could work with Dokany or other solution. https://github.com/billziss-gh/winfsp/tree/master/opt/cygfuse To clarify I do not volunteer to maintain such a project. Only to kickstart it by contributing the existing package code. I would hope that another maintainer emerges, one who is both unaffiliated to the existing projects (Dokany, WinFsp, etc.) to ensure fairness and one that has Cygwin’s interests in mind. Let me know. Bill
