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: package conffiles (was: man 1.5k-2 is broken)

>-----Original Message-----
>From: [] On Behalf Of Alejandro Lopez-Valencia
>Sent: Monday, January 19, 2004 11:08 AM
>To: Cygwin List
>Subject: Re: man 1.5k-2 is broken
>On Sunday, January 18, 2004 8:44 PM [GMT-5],
>Larry Hall wrote:
>> At 11:03 AM 1/18/2004, Alejandro Lopez-Valencia you wrote:
>>> The file /usr/share/misc/man.conf specifies less flags as "-is".
>>> This must be set to "-isrR" to work with groff's default tty
>>> using SGR codes.
>> If you had a /usr/share/misc/man.conf file before the install, you
>> won't get an updated version from the install.  Either make the
>> change manually or remove usr/share/misc/man.conf and reinstall.
>> There is nothing wrong with the man tarball.
>Hmmm... You are obliquely correct, of course, but your answer
>presumes too much. I am reporting a package configuration bug, not
>weeping for help on a "small little thing anybody should know how to
>do"(tm).[1] Are you the packager maintainer? (No I am *not*
>volunteering, thank you).
>IMAO, the maintainer should have fixed the obvious bug (and
>documented blunder!) of not using "-isrR" in man-1.5m2-1 by
>modifying the postinstall script to backup the old man.conf file if
>present and installing a new one with the bug fix.
>[1] A registered trademark of the BOFH, or it should be.

There's no policy for conffiles, or a way to handle them like in
debian. Not that debian handles them perfectly either. Hence there's
absolutely nothing wrong with the package, but you nonetheless bring
up a good point. Some of these problems aren't easily solvable, but
the situation could certainly be improved. Don't know if this
discussion should be here on cygwin-apps, if so feel free to LART me :)

This is approximately what debian does: 

Here's my proposal for what Cygwin could start doing, based on that idea.

To handle a situation like this, suppose we have a Cygwin user ("Jane") who
hasn't updated her Cygwin installation in a few weeks, and the "boffo"
package is a few versions behind, at boffo-1.1-1. After an update from
setup.exe, package boffo-1.2-3 is getting installed. One of the principal
changes in the new package fixes a bug by modifying the configuration file

When the old package, boffo-1.1-1 was being installed, the conf file was
installed as /etc/ Then, when /etc/postinstall/ was
being run, it invoked something like install_conffile /etc/boffo.conf.

install_conffile sees that /etc/boffo.conf does not exist, therefore it
copies /etc/ to /etc/boffo.conf.dist and to /etc/boffo.conf.

Jane, in the use of "boffo", changed a line in /etc/boffo.conf
from: foo="" to foo="bar".

Now the new package, boffo-1.2-3 is getting installed. It installs the new
version of the conffile again as /etc/

Now /etc/postinstall/ runs again and calls install_conffile /etc/boffo.conf

There are now three boffo files in /etc,

/etc/	version 1.2-3 standard conffile
/etc/boffo.conf.dist	version 1.1-1 standard conffile
/etc/boffo.conf		version 1.1-1 user modified conffile

install_conffile does a "diff -u boffo.conf.dist > boffo.conf.patch"
to create the changes in standard conffiles between versions 1.1-1 and 1.2-3.

Let's assume that the line foo="" didn't change between those versions, but in 1.1-1
there was a line like DEFAULT_OPTIONS="-a -b" that became DEFAULT_OPTIONS="-a -b -c",
and this change fixes a catastrophic failure of the "boffo" package to prevent nuclear

So the patch looks like:


install_conffile then patches the boffo.conf file, and overwrites boffo.conf.dist with, and everything is fine and dandy. Jane gets to keep her custom
conffile changes, and the important changes got propagated as well.

Of course, patch is not a very intelligent program, and until we have a heuristics based
patch that can recognize various things that are obvious to us, this procedure will
often fail.

Suppose Jane changed DEFAULT_OPTIONS to "-a -b -d", the conffile patch would no longer
apply, even if the -d option may have no bearing on the situation. install_conffile would
then need to notice this, it could leave the .rej files in /etc/, or it could put a more
user-friendly notice in /etc/setup.log like "could not change FOO to BAR in /etc/boffo.conf"
or whatever.

Some false-negatives could be further reduced by ignoring whitespace, changing fuzz offsets,

What do you guys think?


Unsubscribe info:
Problem reports:

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