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/
