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: How does setup.exe cope with upgrading of already installed packages if there exist modification in installed files?

19.10.2011 16:27, Andrew Schulman ÐÐÑÐÑ:
Also I worry about modification in other config files in /etc
(like /etc/apache2/httpd.conf). Are they overwritten on package update?

This is up to each package maintainer. Current best practice - at least, as of a year or two ago when I asked about it on cygwin-apps I think - is to include:

(1) a default config file in /etc/defaults/etc;
(2) a preremove script that removes the existing config file iff it hasn't
change from the default; and
(3) a postinstall script that installs the default config into /etc if no
other config file is already there.

If all three of those are present, then a package upgrade will replace the
existing config files if and only if they haven't changed since they were
installed.  If they have changed, then it's up to the user to merge the old
and new configs.

cygport provides automatic support for (1) and (3) above if you call e.g.

make_etc_defaults /etc/lftp.conf

To complete the set, package maintainers have to separately include a
simple preremove script, e.g.

   if cmp -s /etc/defaults/etc/lftp.conf /etc/lftp.conf
     /bin/rm /etc/lftp.conf

The lftp package, for example, includes all three of the above pieces.  For
other packages, you'll just have to check each one.  If a piece seems to be
missing, you can ask the maintainer if they're willing to add it.

How can I be notified about upgrade conflicts?

Unfortunately, setup doesn't include any way of prompting the user for action due to conflicts. The postinstall script will either overwrite the existing config, or it won't. I think it's considered bad practice to overwrite a config without checking first whether it's been modified; if you find that a package does that, you should ask the maintainer to fix it.

Your safest bet is probably to back up all of the configuration before you

What for '/etc/defaults' hierarchy was used?

See above.

Thanks for replay!

Seems that /etc/default practice is good.

How about templates?

For example if package like Mercurial provide
WEB templates which I like to customize (fix time format to ISO-8601).
Templates lies in /lib/python2.6/site-packages/mercurial/templates/*.

If I prepare some fixes to package which list appropriate to write report to?

Contact to mail from


or separate list used for this purpose?

-- Problem reports: FAQ: Documentation: Unsubscribe info:

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