From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-042.btinternet.com (mailomta7-sa.btinternet.com [213.120.69.13]) by sourceware.org (Postfix) with ESMTPS id AD6FD385842D for ; Wed, 6 Oct 2021 16:24:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AD6FD385842D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-004.btmx-prd.synchronoss.net ([10.2.38.7]) by sa-prd-fep-042.btinternet.com with ESMTP id <20211006162409.MPTB14747.sa-prd-fep-042.btinternet.com@sa-prd-rgout-004.btmx-prd.synchronoss.net> for ; Wed, 6 Oct 2021 17:24:09 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613943C6040C96B3 X-Originating-IP: [81.129.146.163] X-OWM-Source-IP: 81.129.146.163 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvtddrudeliedgleejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepleeigeehgefhveefvefhvdeiudfgvdeuhfejheetjefffefhueduteehuefgfffhnecukfhppeekuddruddvledrudegiedrudeifeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtfegnpdhinhgvthepkedurdduvdelrddugeeirdduieefpdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdprhgtphhtthhopegthihgfihinhdqrghpphhssegthihgfihinhdrtghomh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (81.129.146.163) by sa-prd-rgout-004.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613943C6040C96B3 for cygwin-apps@cygwin.com; Wed, 6 Oct 2021 17:24:09 +0100 Subject: Re: Question about 'provides' and emacs packaging To: "cygwin-apps@cygwin.com" References: <871r4zba8j.fsf@Rainer.invalid> <1e97fce0-593a-e8a6-cefe-fa6d8a1c4ed4@cornell.edu> From: Jon Turney Message-ID: <38baa42c-bf6a-52fc-3fd7-9a6bc09d1125@dronecode.org.uk> Date: Wed, 6 Oct 2021 17:23:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <1e97fce0-593a-e8a6-cefe-fa6d8a1c4ed4@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1192.2 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 16:24:13 -0000 On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote: > On 10/5/2021 2:24 PM, Achim Gratz wrote: >> Ken Brown via Cygwin-apps writes: >>> There are currently five emacs packages: emacs-common, emacs, >>> emacs-X11, emacs-w32, and emacs-lucid.  The first includes things that >>> are needed by each of the other four, and those four each include an >>> emacs binary.  The binary in the emacs package is >>> /usr/bin/emacs-nox.exe.  The other packages contain >>> /usr/bin/emacs-X11.exe, and so on. >>> >>> This way of naming the packages doesn't really reflect the contents of >>> the emacs package.  It also means that anyone who installs emacs gets >>> emacs-nox.exe, even if they plan to use one of the other three >>> binaries. >>> >>> I would rather rename the current emacs-common package to emacs and >>> the current emacs package to emacs-nox.  But then the new emacs would >>> have to have a way of requiring the installation of at least one of >>> emacs-nox, emacs-X11, emacs-w32, or emacs-lucid.  Is there any way to >>> do this with our current setup machinery? >> >> I don't think we have the transaction capability that would be necessary >> to specify that the meaning of an already existing package name (two, >> actually) changes in this manner.  You might have to use new package >> names and place the appropriate obsoletions w.r.t. old names instead. >> >>> My idea three years ago was to have the new emacs package require a >>> "feature" called, for instance, emacs-bin, and then have each of >>> emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. >> >> I have no idea if multiple packages can provide the same feature. It's >> worth trying if it does what you want (you must pick at least one of >> those). > > This seems to work, with one caveat.  Suppose package P requires feature > f, and packages Q, R, S,... provide f.  If the user selects P and one or > more of Q, R, S,..., setup is happy.  But if the user simply selects P, > then setup/libsolv will choose among Q, R, S,... the one whose name is > alphabetically first.  In the emacs case, this would be emacs-lucid, > which is a stupid default.  The default ought to be emacs-nox.  So I can > make it work if I call that package emacs-basic instead of emacs-nox. Yeah, I think what's wanted here is for the solver to output a problem with the choices, rather than picking one. I'm not sure how to get it to do that. (Ofc, then we need some UI for picking problem solutions, rather than just always using the default) (and I'm not sure how we'd encode "emacs-basic" should be the default provider of "emacs-bin" as the input into the solver; presumably there'd by some scheme with weights attached to provide names to set the order rather than alphabetic) > I've only tested setup so far, not calm.  Jon, if you're reading this, > does calm allow 'requires' and 'provides' to contain arbitrary names > that are not package names? Yes.