This is the mail archive of the cygwin-apps 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: cygport: patches welcome?

On 13 July 2007 12:11, Corinna Vinschen wrote:

> On Jul 13 11:30, Dave Korn wrote:
>> On 13 July 2007 09:01, Corinna Vinschen wrote:
>>> I'm still not sure how to handle situations where the default config
>>> file in /etc/defaults/etc has changed between releases, but the user has
>>> also changed the copied config file in /etc.  We have no mechanism and
>>> no standarized way to handle this so far.
>> diff -u /etc/defaults/etc/prev-config /etc/config | patch --dry-run -p0 \
>> /etc/defaults/etc/new-config -o /etc/defaults/etc/config.mrg \
>> && ( echo "Use the new one!" ; \
>>      mv /etc/defaults/etc/config.mrg /etc/config ) \
>>>> ( echo "You must manually update merge your config files! ; \
>>      cp /etc/defaults/etc/new-config /etc/ )
>>> Does that sound ok?  Any other ideas?
>>   I think it might be worth attempting an auto-merge like the above and use
>> the mechanism you describe in the fallback case.  The automerge procedure
>> needs more thinking out than the outline I've sketched above; we need to
>> look through the manifest, grep out the etc/defaults files, run 'file' on
>> them to verify that we only attempt to merge plain ascii text files, back
>> up the old default config files before unpacking the package tarball, etc.
>> etc.... 
> I'm a bit reluctant to present a generic auto-merge.  Consider the
> situation where a new version of a package adds a new configuration
> setting.  An auto-merge would pull in the default setting for this
> one, without the user knowing about this 

  You mean like, for instance, sshd introduces a new vital security-related
config option such as PrivSep and if the user doesn't know to turn it off
manually it gets enabled by default?  Sounds like a good thing to me ....!
(Plus it's not any different from the situation where the user installs the
package for the first time and doesn't bother to customize the config).

  I know the idea of automerge is scary.  I guess we should make sure there's
a very very easy roll-back mechanism that we can point users at if something
goes wrong and that would just restore their prior config exactly as it was
before the merge.

Can't think of a witty .sigline today....

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