From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16516 invoked by alias); 26 Oct 2017 17:49:40 -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 16504 invoked by uid 89); 26 Oct 2017 17:49:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:ESMTPA X-HELO: out4-smtp.messagingengine.com Received: from out4-smtp.messagingengine.com (HELO out4-smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Oct 2017 17:49:38 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 04B3D20B8E for ; Thu, 26 Oct 2017 13:49:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 26 Oct 2017 13:49:37 -0400 X-ME-Sender: Received: from [192.168.1.102] (host86-179-113-201.range86-179.btcentralplus.com [86.179.113.201]) by mail.messagingengine.com (Postfix) with ESMTPA id 99BFC7E3DF for ; Thu, 26 Oct 2017 13:49:36 -0400 (EDT) Subject: Re: setup and colons in filenames To: cygwin-apps@cygwin.com References: <03e94ec4-db88-8997-40a0-1c63b1a010bd@dronecode.org.uk> <87vaj1u7pl.fsf@Rainer.invalid> From: Jon Turney Message-ID: <5c5b6e17-5268-4a72-7ec0-5a0d399b705b@dronecode.org.uk> Date: Thu, 26 Oct 2017 17:49:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <87vaj1u7pl.fsf@Rainer.invalid> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00139.txt.bz2 On 26/10/2017 18:42, Achim Gratz wrote: > Jon Turney writes: >> This seems a really odd thing to do, as we've no idea about the >> dependencies of these packages, so installing them is unlikely work >> well. > > This particular code path was vetoed from getting thrown out last time I > worked in that area since it would break long-standing expectations > w.r.t. local package archoves that have no setup.ini or even *.hint. Can we have a link to that discussion, please? >> I'm kind of tempted to remove this mis-feature. > > In a properly maintained mirror or local archive it is a mis-feature. I > was told not everyone wants to have to do the extra steps of doing that > maintenance. At least if we detect what should be a proper package repo > we don't additionally look at all the files anymore.