X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Message-ID: <4BBB4D14.7030708@bopp.net> Date: Tue, 06 Apr 2010 10:02:44 -0500 From: Jeremy Bopp User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: [ANNOUNCEMENT] Updated: cygwin-1.7.3-1 References: <20100404212837 DOT GA13198 AT onderneming10 DOT xs4all DOT nl> <4BB9944D DOT 5000005 AT gmail DOT com> <20100405142008 DOT GA10449 AT ednor DOT casa DOT cgf DOT cx> <20100406141326 DOT GC16409 AT ednor DOT casa DOT cgf DOT cx> In-Reply-To: <20100406141326.GC16409@ednor.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 4/6/2010 9:13 AM, Christopher Faylor wrote: > On Tue, Apr 06, 2010 at 03:57:24PM +0300, Matthias Andree wrote: >> There's the LSB, Linux Standards Base, and it supports a "lsb_release" >> command, try "lsb_release -a" for a start, here a few samplers: > > So, did anyone actually read my response here about how this wouldn't > work for Cygwin? If so, you'd have to think that these responses were > pretty off-topic. I'm not sure how helpful it would ultimately be, but couldn't the Cygwin release be set to the most recent setup-timestamp value from the set of setup.ini files last used to update the installation? For most people this would likely be sufficient to identify whether or not their Cygwin installation meets or exceeds a given "release" benchmark. There are, however, at least 3 corner cases for which this won't account: 1) A user holds back a subset of packages ready to be updated. 2) A user installs experimental packages. 3) A user uses additional repositories such as Cygwin Ports. People doing one or more of the above should hopefully be technical enough to understand the dangers and devise workarounds though. To be honest, I'm not sure what can be gained from such gross identification of operating environments as would be provided by a potential /etc/cygwin-release file. The most accurate way to check for functionality is to specifically test for it, a la autoconf. Failing that, checking for specific package versions is pretty good depending on your needs. I think you're asking for trouble if you try to get more general than that. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple