From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2593 invoked by alias); 15 Jan 2018 19:02:17 -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 2095 invoked by uid 89); 15 Jan 2018 19:01:42 -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=appeal, acting, Hx-spam-relays-external:ESMTPA 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; Mon, 15 Jan 2018 19:01:40 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2BB1520C6B for ; Mon, 15 Jan 2018 14:01:39 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 15 Jan 2018 14:01:39 -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 BAE5524599 for ; Mon, 15 Jan 2018 14:01:37 -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> <871sit7gji.fsf@Rainer.invalid> From: Jon Turney Message-ID: <92b5ec62-0c4a-ad37-1c10-164db0119879@dronecode.org.uk> Date: Mon, 15 Jan 2018 19:02: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: <871sit7gji.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00051.txt.bz2 On 13/01/2018 18:35, Achim Gratz wrote: > Jon Turney writes: >> * 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. > > You keep acting like using a new src/ hierarchy was already decided > upon, yet I don't remember it even getting discussed. So, can we have > that discussion before decision, please? The purpose of my original email is to start that discussion. > To repeat, I think a separate src/ hierarchy would be a mistake, given > where we are today, although it has a certain appeal from a greenfield > perspective. But more to the point, there is nothing special about > source archives (except that they're not architecture specific) that > warrants putting them into their own hierarchy, IMHO. If they are going > to get moved on deduplication (there are good reasons to move them and > these likely outweight the benefits of just deleting them in one side of > the hierarchy), we already have a place for that and that place is > noarch/. That keeps everything in working order for folks who for > whatever reason mirror the repository, even if the only mirror one > architecture. If I've understood correctly, your objection is that this will break installing source packages from mirrors which choose to mirror selected subdirectories (e.g. x86_64/ and noarch/). I guess I consider that counterbalanced by the ability to selectively not mirror src/.