From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-046.btinternet.com (mailomta12-re.btinternet.com [213.120.69.105]) by sourceware.org (Postfix) with ESMTPS id 006EB3858D33 for ; Thu, 16 Feb 2023 20:31:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 006EB3858D33 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 re-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.54.5]) by re-prd-fep-046.btinternet.com with ESMTP id <20230216203133.SQCC7994.re-prd-fep-046.btinternet.com@re-prd-rgout-002.btmx-prd.synchronoss.net>; Thu, 16 Feb 2023 20:31:33 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8DE84ECCDF0D X-Originating-IP: [81.153.98.246] X-OWM-Source-IP: 81.153.98.246 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvhedrudeijedgudefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepvddtteffkeevveejgeehgeelhfdtgefgieelgffgudetudefvdeggfeiiefftdevnecukfhppeekuddrudehfedrleekrddvgeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdeingdpihhnvghtpeekuddrudehfedrleekrddvgeeipdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopegthihgfihinhdqrghpphhssegthihgfihinhdrtghomhdprhgtphhtthhopehksghrohifnhestghorhhnvghllhdrvgguuh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.246) by re-prd-rgout-002.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8DE84ECCDF0D; Thu, 16 Feb 2023 20:31:33 +0000 Message-ID: Date: Thu, 16 Feb 2023 20:31:32 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: Possible "stage" token for SCALLYWAG builds Content-Language: en-GB To: Ken Brown , "cygwin-apps@cygwin.com" References: From: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1191.4 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 15/02/2023 21:48, Ken Brown via Cygwin-apps wrote: > Jon, > > When building TeX Live (once a year), I have to build texlive, > asymptote, and all the texlive-collection-* packages.  I currently can't > use SCALLYWAG to do the builds because these packages need to all be > deployed at once.  So I have to build them all locally, upload them to > my staging area, and then upload !ready files, one for x86_64 and one > for noarch. > > It would be convenient for me if SCALLYWAG would accept a "stage" token > that would upload the files to my staging area without deploying them. > Then I could let SCALLYWAG do the builds, and I could upload the !ready > files when everything is staged. > > If I'm the only maintainer who would find this useful, then I can > continue doing it the way I always have.  But maybe others would find it > useful too. I'm not opposed to adding a some feature to support this if needed, but from the way you are describing it, this sounds more like a constraint that the dependency solver should be aware of. (just because texlive-2023 and texlive-collection-foo-2023 are made available to download at the same time, doesn't mean that they always end up installed together, as the user might alter the version of one or the other) If they really must be kept in lockstep to work correctly, then there's at least a couple of ways of doing that: * give texlive an additional provide, such as texlive_2023, and make everything that requires it, require that (something similar is done with perl and perl modules) * make things which require texlive do so with a version constraint like 'requires: texlive (>= 20230000), texlive (<20240000)' (in theory this works, but I have no doubt that a bug will emerge when someone tries to use it, and ofc, it relies on the range of future versions which are compatible being correctly known in advance) Assuming I've understood correctly, you might want to survey how other distros approach this problem.