From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9040 invoked by alias); 26 Jul 2016 18:13:15 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 9030 invoked by uid 89); 26 Jul 2016 18:13:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1651 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 26 Jul 2016 18:13:12 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bS6qr-0007Fq-9R for cygwin-apps@cygwin.com; Tue, 26 Jul 2016 20:13:09 +0200 Received: from 76-217-5-154.lightspeed.irvnca.sbcglobal.net ([76.217.5.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Jul 2016 20:13:09 +0200 Received: from mark by 76-217-5-154.lightspeed.irvnca.sbcglobal.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Jul 2016 20:13:09 +0200 To: cygwin-apps@cygwin.com From: Mark Geisert Subject: Re: [ITP] FUSE 2.8 Date: Tue, 26 Jul 2016 18:13:00 -0000 Message-ID: References: <20160723104021.GA18159@calimero.vinschen.de> <20160723174836.GD11373@calimero.vinschen.de> <20160725073538.GF11373@calimero.vinschen.de> <81992397-64d2-bf0d-a7cd-9620a559a7a4@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00084.txt.bz2 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