This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Updated: cygwin-1.7.3-1

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.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]