From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79338 invoked by alias); 21 Jun 2016 13:49:53 -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 79327 invoked by uid 89); 21 Jun 2016 13:49:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=transition, H*MI:sk:2016062 X-HELO: mail-lf0-f50.google.com Received: from mail-lf0-f50.google.com (HELO mail-lf0-f50.google.com) (209.85.215.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 21 Jun 2016 13:49:51 +0000 Received: by mail-lf0-f50.google.com with SMTP id h129so24949317lfh.1 for ; Tue, 21 Jun 2016 06:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=U/RTQ0UHhSnYINaieSgfbWytQyZzt/Au7VkpbXaC5uE=; b=mEWbG08KRFU2gZz/+RlhdL9Ajr/gnPVkaxR51cfczHhX92P3Or6/TYWu0YV9D7hqZ7 m6nxkRXRQgME46iTjmX5hb3tuP6Pk4sfsUFIrjW/M5j5Goh/yJOCkQwWaSvB/q9YIMkP igVD3oH8189RDFImA26b6cP4g76tW5kbz4BYNPK/+YvGTJXbZQyLmJ0425GMeu1/1ucj cxy7x7Rgxd8jDKeuVym+KMLtKGScBcd9OsND6o37gvSx2CiPCMCQsNpB/QwwcOKX3Htq 39pSnhd3gOJkw0VK5yhGtnyBHr0Vgo023a/vsS5PJ9mfItSpyNutmkRmJcXwSnGeyZe3 8Nsg== X-Gm-Message-State: ALyK8tKHiBUqDxk9X3xXOWDxkXxCr87le7K9XBONrw6R4zTHzgjRIKL3sJzufn0J+v5spg== X-Received: by 10.28.55.79 with SMTP id e76mr3408085wma.41.1466516987642; Tue, 21 Jun 2016 06:49:47 -0700 (PDT) Received: from [172.21.188.226] ([149.6.156.42]) by smtp.googlemail.com with ESMTPSA id ue1sm48116936wjc.44.2016.06.21.06.49.46 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 06:49:46 -0700 (PDT) Subject: Re: per-version hints proposal To: cygwin-apps@cygwin.com References: <8b4723b2-1bd5-3604-1deb-cfd0a1c7b9d9@dronecode.org.uk> <20160621120321.GL3667@calimero.vinschen.de> From: Marco Atzeri Message-ID: <2bfdb839-05a8-4d07-7ae1-a8794615a5bc@gmail.com> Date: Tue, 21 Jun 2016 13:49:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160621120321.GL3667@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00074.txt.bz2 On 21/06/2016 14:03, Corinna Vinschen wrote: > On Jun 20 16:28, Jon Turney wrote: >> >> Currently, the setup.hint file is shared between all versions. >> >> This means that manual intervention (by the package maintainer, or on >> sourceware) is needed when versions have different dependencies. >> >> To automate this problem out of existence, I suggest replacing the >> setup.hint file in an upload with a package-version-release.hint file. >> >> This will be basically identical to the existing setup.hint, with the >> advantage that it can't be trampled on by a future version, with the >> following changes: >> fine for me. > Ideally we wouldn't need something like "prev" at all since the version > number itself is sufficient to specify what's curr and what's old. > > As for test, IMHO it would make sense to specify "this is a test > release" right in the cygport file. This in turn could create a > per-version hint with a test marker which is evaluated by calm > accordingly. For instance, the name of the file could take over this > role. Or even better, the package version number itself. > > This would have an additional benefit: We couldn't just move a package > from test to curr, it would have to be explicitely rebuilt as non-test > release. not a huge fan of this. The last time we made the perl transition we put a lot of package in test as temporary solution. Rebuild all just to change a label seems a waste of time. >> >> No setup changes are required. >> >> >> Immediately, this avoids the need for manual intervention when versions have >> different dependencies, and going forward, this is lays some groundwork for >> supporting per-version dependencies. > > Sounds good to me. +1 > Corinna Marco