From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106983 invoked by alias); 13 Jan 2018 17:22:13 -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 106971 invoked by uid 89); 13 Jan 2018 17:22:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Excellent, mighty, Ok, imminent X-HELO: out1-smtp.messagingengine.com Received: from out1-smtp.messagingengine.com (HELO out1-smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 13 Jan 2018 17:22:11 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 956B620BA8 for ; Sat, 13 Jan 2018 12:22:09 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 13 Jan 2018 12:22:09 -0500 X-ME-Sender: Received: from [192.168.1.102] (host86-179-112-242.range86-179.btcentralplus.com [86.179.112.242]) by mail.messagingengine.com (Postfix) with ESMTPA id 477EB24235 for ; Sat, 13 Jan 2018 12:22:09 -0500 (EST) Subject: Re: Planned setup.ini changes for early 2018 To: cygwin-apps@cygwin.com References: <5e585f56-b4b1-753d-7ca8-0f7894194fa9@dronecode.org.uk> <148c2b29-5eae-9bc9-eef0-8504368fcb43@dronecode.org.uk> From: Jon Turney Message-ID: Date: Sat, 13 Jan 2018 17:22:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-01/txt/msg00038.txt.bz2 On 12/01/2018 18:11, Peter A. Castro wrote: > On Fri, 12 Jan 2018, Jon Turney wrote: >> On 11/01/2018 17:53, Peter A. Castro wrote: >>> On Wed, 10 Jan 2018, Jon Turney wrote: >>>> * Add depends: to version descriptions >>>> >>>> This is a version-specific list of required packages (as opposed to >>>> requires:, which is per-package, and contains the union of the >>>> dependencies for all versions). >>>> >>>> I believe that historical setup versions will either ignore, or can >>>> handle depends: (just containing package names, without version >>>> relations) relatively sanely (see [1] et seq. for details). >>> >>> As long as the behaviour you outline in [1] is consistent, then that >>> means I should be able to use older Setup with newer setup.ini, yes? >>> That will be useful for people who use the Time Machine. :) >> >> Yes, this doesn't break backwards compatibility. > > Excellent! > >> I'm not sure what reasons there are to use older setup on a circa from >> after the date of this change. > > It's not quite as strange as you might think.  Older environments can't > necessary run newer Setup (winXP anyone? :), but, on occasion, need some > package from a later circa that's associated with a newer, but > incompatable, Setup version.  Yes, yes, I know, "don't do that".  Caveat > emptor and all that. Ok. You could also use setup flag --allow-unsupported-windows in that situation. >> I hope this means that the time machine can/will preserve depends: lines. > > It does.  'setup.ini' is preserved as originally distributed from > cygwin.com (and, of course, it's mirrors). Oh. I had assumed for some reason that setup.ini was regenerated for each circa. Can I ask you to consider preserving the setup.ini.sig etc. as well? >>>> * De-duplicate source archives >>>> >>>> Source archives which are identical[2] between x86 and x86_64 will >>>> be moved to paths starting src/ in the release area. >>> >>> I'm not quite visualizing this,  Do you mean there will be a new >>> directory name 'src' that will be on the same level as 'x86' and >>> 'x86_64' or will it be higher up the directory tree?  It matters to me >> >> This means src/ on the same level as x86/ x86_64/ and noarch/. > > Thanks for the confirmation.  I'll need to make some adjustments to the > Time Machine for this, but should be trivial.  Do you have a schedule of > when you will start pushing this change out? No schedule, but not imminent, and certainly after the other items on this list. I'll let you know closer to the time. >>> for the Time Machine as I'll need to be able to re-create the same >>> directory hierarchy for each circa.  It's a selectively automated >>> process currently, but I need to know what symlink to place where.  :) >>> >>>> Doing post-hoc de-duplication is unfortunate, but worthwhile given >>>> the potential size saving in mirrors (see [3] et seq.), until >>>> cygport can be taught how to make suitable source packages (which >>>> has several unresolved issues, also discussed at [3], [4] et seq.). >>> >>> Will this be done en masse upon the next setup.ini build cycle, or >>> over time as each new package is updated?  Having a massive amount of >>> "new" packages show up under a "new" directory named 'src' will be >>> quite a lot for the mirrors to absorb all at once.  For the Time >>> Machine it might effectively be double as I have to maintain the old >>> hierarchy as well as the new one (under the assumption that you'd >>> apply the de-duplication retroactively). >> >> The process will be gradual and retroactive. > > Ok.  Thanks for confirming.  I'll watch for a mighty "gulp" in my pull > logs. :) > >> I'm not quite sure yet how it's going to apply to new uploads.  Often >> x86 and x86_64 packages are uploaded separately, so either it happens >> asynchronously, after the last upload of the pair has been accepted, >> or I defer accepting and deduping the upload until both are uploaded. > > What of cases where the version for x86 and x86_64 uploaded aren't the > same (it happens)?  Will those be skipped or am I misunderstanding how > this dedup process will work? Strictly, I guess this should be disallowed, since there aren't any good reasons for the source packages to be different. However, since there are suggestions that there are some packages where they can't be same due to shortcomings in cygport, I guess this case should be treated the same as currently.