At 02:08 PM 1/19/2004, Alejandro Lopez-Valencia you wrote:
>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
>output
>>> 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).
No, I'm not the package maintainer. Just a long time user and listener
on this list. Actually, I was aware that you were reporting a "bug" in
that packaging. That's why I answered you so specifically. I stated
that the tarball was fine and with instructions for manually making the
required change, if 'man' was installed previously. I recognize that the
approach I described puts a burden on the user and potentially adds traffic
to this list (this particular change already has done so quite a bit, even
though 'man' is not to 'blame'). However, these situations are catch-22.
If the user has added customizations to the file before the installation,
they loose them afterward without some manual intervention. Either way,
we loose. So far, the convention adopted for packages in with config files
like this is to only create them but not replace them. This is why I made
the statements I did.
>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.
That's another way to go. Clearly, the 'man' maintainer is free to
decide whether he would prefer to take the approach you describe, stick
with the one he has, or adopt another. But the 'man' package currently
follows the Cygwin packaging convention (as I mentioned above). And the
resolution isn't as 'obvious' as you imply. However, I'm sure if the
'man' maintainer feels there is a need to make a change here as a result
of your report, he will do so. While my previous comments on the subject
as well as these are meant to clarify the current state of affairs, the
package maintainer always has the last word on what will be done with any
particular package. That means he's free to disregard or contradict
anything I've said. That said, you are also free to provide any patches
you deem appropriate for the maintainer's consideration.
I hope that clarifies the intent of my original response. If not, let
me know and I'll try again.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/