This is the mail archive of the
mailing list for the Cygwin project.
Re: Avoid collisions between parallel installations of Cygwin
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Sun, 18 Oct 2009 17:47:25 +0100
- Subject: Re: Avoid collisions between parallel installations of Cygwin
- References: <4ADB2110.email@example.com>
Charles Wilson wrote:
> Corinna wrote:
>> You can avoid this problem by defining the resource section in a dynamic
>> fashion from the start. Each entry consists of the name of the value,
>> a descriptive text, and the value itself. So, each entry could be a
>> statically sized structure of 256 bytes like this:
>> For instance, if the name is "blurb", cygcheck could be advised to
>> understand an option `--blurb' to set the value.
> That will help, but won't completely eliminate the problem. It's still
> conceivable that you might need to change even the definition of struct
> resource_value in version N+1. For instance:
> And even if you start off with THAT, you might discover that you need so
> other change to the struct definition in version N+2. I don't know if
> this is a realistic concern. Your original approach is probably
> sufficient -- my concerns are probably over-engineering.
I don't think we should worry. Ok, so older cygchecks won't be able to
parse newer DLLs. As long as it does a version number check and issues a nice
error message and fails safe, no problem. And remember, we will control the
horizontal *and* the vertical. Since the Cygwin DLL and the cygcheck utility
are both part of the same CVS tree and are always built and distributed
together in synchronised versions, how exactly will a problem arise, unless
someone deliberately manually installs just the DLL from a new release
package, or just the cygcheck exe from an old one?