Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
Michael DePaulo writes: Consider the example of where I work. After I install the corporate IT department's SCCM package/script for Cygwin (1.7.16, last updated August 2012) That is an entirely different issue and one your IT will have to resolve. Given how these departments operate, don't get your hope up too high; they've already ticked all their checkboxes and moved on to other things. In my own installation I do an incremental rebase and will do a mandb update each time setup has been run (I've patched setup.exe to allow for that). That's the only way to keep things sane at the moment if you're doing installations for anyone but yourself, especially if some of those user do not have local admin rights. I am greeted by this message every time I start the Cygwin Terminal: That will soon become a non-issue with the AD integration that is in the works. Your IT department will have to update to it, though. […] I am not suggesting that users see a mandb message every time they launch cygwin. But I am suggesting that that users see it when they 1st launch cygwin. They already see this message: […] In all these cases it's easy and fast to test for the condition that triggers the message, that is quite necessary since that check will be run on every login. Checking for no database would be easy enough I think, but checking for an outdated database might be more tricky. I could think up something to add to base-files for the first case. I'm not sure what to do for the latter. I think it must be the responsibility of any package that installs man pages to trigger a db update, but that would get us into the situation again that the first install takes inordinately long on some systems (just to note that TeXlive has that same problem). We might need to cook up with some way to defer these until they can be run in the background. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
On Fri, Aug 15, 2014 at 1:52 AM, Yaakov Selkowitz yselkow...@cygwin.com wrote: The following packages have been updated in the Cygwin distribution: * man-db-2.6.7-2 man-db is an implementation of the standard Unix documentation system accessed using the man command. It uses a Berkeley DB database in place of the traditional flat-text whatis databases. This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). -- Yaakov (on behalf of Chris Breisch) IMHO, this sounds like a serious decrease in Cygwin's usability. How do Linux distributions handle this? Linux distros install many more packages by default, so doesn't their cache database generation typically take much longer? Also, should documentation (or perhaps the info a user sees when they start Cygwin for the 1st time) be updated? Respectfully, -Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
On 2014-08-15 07:22, Michael DePaulo wrote: This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). IMHO, this sounds like a serious decrease in Cygwin's usability. How do Linux distributions handle this? Linux distros install many more packages by default, so doesn't their cache database generation typically take much longer? Exactly why they don't seem to do it during postinstall either. For example, in Fedora this is handled by a cron job. A future release may add that functionality, but it is clear that postinstall is the wrong place for it. Also, should documentation (or perhaps the info a user sees when they start Cygwin for the 1st time) be updated? How so? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
On Fri, Aug 15, 2014 at 10:20 AM, Yaakov Selkowitz yselkow...@cygwin.com wrote: On 2014-08-15 07:22, Michael DePaulo wrote: This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). IMHO, this sounds like a serious decrease in Cygwin's usability. How do Linux distributions handle this? Linux distros install many more packages by default, so doesn't their cache database generation typically take much longer? Exactly why they don't seem to do it during postinstall either. For example, in Fedora this is handled by a cron job. A future release may add that functionality, but it is clear that postinstall is the wrong place for it. I disagree, but I need to read more about the subject in order to have a well-informed opinion. Also, should documentation (or perhaps the info a user sees when they start Cygwin for the 1st time) be updated? How so? Yaakov Consider the example of where I work. After I install the corporate IT department's SCCM package/script for Cygwin (1.7.16, last updated August 2012), I am greeted by this message every time I start the Cygwin Terminal: Your group is currently mkpasswd. This indicates that your gid is not in /etc/group and your uid is not in /etc/passwd. The /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group Note that the -d switch is necessary for domain users. I can get rid of the message if do I run those commands. However, here's what happens if I do run them: mkpasswd -l -d takes 9m29.159s outputs 37062 lines mkgroup -l -d takes 4m26.470s outputs 36866 lines (I have to run those commands with admin rights, but fortunately mandb does not require admin rights because of user DBs.) I am not suggesting that users see a mandb message every time they launch cygwin. But I am suggesting that that users see it when they 1st launch cygwin. They already see this message: Copying skeleton files. These files are for the users to personalise their cygwin experience. They will never be overwritten nor automatically updated. './.bashrc' - '/home/mike//.bashrc' './.bash_profile' - '/home/mike//.bash_profile' './.inputrc' - '/home/mike//.inputrc' './.profile' - '/home/mike//.profile' Also, users who are particularly reliant on the apropos command probably don't know about running the mandb command. It's analogous to users launching the Windows Help and Support Center, but its search bar returning 0 results they haven't run another utility 1st. -Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
Greetings, Michael DePaulo! This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). IMHO, this sounds like a serious decrease in Cygwin's usability. How do Linux distributions handle this? Linux distros install many more packages by default, so doesn't their cache database generation typically take much longer? Exactly why they don't seem to do it during postinstall either. For example, in Fedora this is handled by a cron job. A future release may add that functionality, but it is clear that postinstall is the wrong place for it. I disagree, but I need to read more about the subject in order to have a well-informed opinion. The TL;DR version of the issue is that compilation of database is slow and prone to fail, plus the database should be re-indexed each time a page is added, removed or changed. If Cygwin do this only at man-db postinstall, the database WILL go out of reality pretty soon. Also, should documentation (or perhaps the info a user sees when they start Cygwin for the 1st time) be updated? How so? Yaakov Consider the example of where I work. After I install the corporate IT department's SCCM package/script for Cygwin (1.7.16, last updated August 2012), I am greeted by this message every time I start the Cygwin Terminal: Your group is currently mkpasswd. This indicates that your gid is not in /etc/group and your uid is not in /etc/passwd. This is about to change in a short while. I am not suggesting that users see a mandb message every time they launch cygwin. This could be resolved in a more graceful way. I.e. motd/fortune/etc. But I am suggesting that that users see it when they 1st launch cygwin. They already see this message: Copying skeleton files. These files are for the users to personalise their cygwin experience. They will never be overwritten nor automatically updated. Users will only see this message, if the $HOME directory is created anew. I, for one, do not see a reason to keep Cygwin users' $HOMEs separate from a system %USERPROFILE%. Also, users who are particularly reliant on the apropos command probably don't know about running the mandb command. It's analogous to users launching the Windows Help and Support Center, but its search bar returning 0 results they haven't run another utility 1st. That's an issue worth resolving. We just need to find a way to do it in a non-abusive fashion. -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.08.2014, 03:57 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
Suppose a makefile or similar for this issue, would handle only man pages that have changed since the last update: The TL;DR version of the issue is that compilation of database is slow and prone to fail, plus the database should be re-indexed each time a page is added, removed or changed. If Cygwin do this only at man-db postinstall, the database WILL go out of reality pretty soon. Keith On Fri, Aug 15, 2014 at 6:05 PM, Andrey Repin anrdae...@yandex.ru wrote: Greetings, Michael DePaulo! This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). IMHO, this sounds like a serious decrease in Cygwin's usability. How do Linux distributions handle this? Linux distros install many more packages by default, so doesn't their cache database generation typically take much longer? Exactly why they don't seem to do it during postinstall either. For example, in Fedora this is handled by a cron job. A future release may add that functionality, but it is clear that postinstall is the wrong place for it. I disagree, but I need to read more about the subject in order to have a well-informed opinion. The TL;DR version of the issue is that compilation of database is slow and prone to fail, plus the database should be re-indexed each time a page is added, removed or changed. If Cygwin do this only at man-db postinstall, the database WILL go out of reality pretty soon. Also, should documentation (or perhaps the info a user sees when they start Cygwin for the 1st time) be updated? How so? Yaakov Consider the example of where I work. After I install the corporate IT department's SCCM package/script for Cygwin (1.7.16, last updated August 2012), I am greeted by this message every time I start the Cygwin Terminal: Your group is currently mkpasswd. This indicates that your gid is not in /etc/group and your uid is not in /etc/passwd. This is about to change in a short while. I am not suggesting that users see a mandb message every time they launch cygwin. This could be resolved in a more graceful way. I.e. motd/fortune/etc. But I am suggesting that that users see it when they 1st launch cygwin. They already see this message: Copying skeleton files. These files are for the users to personalise their cygwin experience. They will never be overwritten nor automatically updated. Users will only see this message, if the $HOME directory is created anew. I, for one, do not see a reason to keep Cygwin users' $HOMEs separate from a system %USERPROFILE%. Also, users who are particularly reliant on the apropos command probably don't know about running the mandb command. It's analogous to users launching the Windows Help and Support Center, but its search bar returning 0 results they haven't run another utility 1st. That's an issue worth resolving. We just need to find a way to do it in a non-abusive fashion. -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.08.2014, 03:57 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
On Fri, Aug 15, 2014 at 8:05 PM, Andrey Repin anrdae...@yandex.ru wrote: Greetings, Michael DePaulo! This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). IMHO, this sounds like a serious decrease in Cygwin's usability. How do Linux distributions handle this? Linux distros install many more packages by default, so doesn't their cache database generation typically take much longer? Exactly why they don't seem to do it during postinstall either. For example, in Fedora this is handled by a cron job. A future release may add that functionality, but it is clear that postinstall is the wrong place for it. I disagree, but I need to read more about the subject in order to have a well-informed opinion. The TL;DR version of the issue is that compilation of database is slow and prone to fail, plus the database should be re-indexed each time a page is added, removed or changed. If Cygwin do this only at man-db postinstall, the database WILL go out of reality pretty soon. Understood. I was thinking that the db was generated every time you updated or installed packages. That's how Debian and its derivatives do keep it up-to-date. (Actually, they only run mandb if 1 or more of the updated/installed packages have manpage. It's handled by their dpkg trigger feature.) Reference: http://askubuntu.com/questions/178773/is-there-a-way-to-see-what-exactly-the-processing-triggers-does-per-package-ba Also, should documentation (or perhaps the info a user sees when they start Cygwin for the 1st time) be updated? How so? Yaakov Consider the example of where I work. After I install the corporate IT department's SCCM package/script for Cygwin (1.7.16, last updated August 2012), I am greeted by this message every time I start the Cygwin Terminal: Your group is currently mkpasswd. This indicates that your gid is not in /etc/group and your uid is not in /etc/passwd. This is about to change in a short while. I am not suggesting that users see a mandb message every time they launch cygwin. This could be resolved in a more graceful way. I.e. motd/fortune/etc. But I am suggesting that that users see it when they 1st launch cygwin. They already see this message: Copying skeleton files. These files are for the users to personalise their cygwin experience. They will never be overwritten nor automatically updated. Users will only see this message, if the $HOME directory is created anew. I, for one, do not see a reason to keep Cygwin users' $HOMEs separate from a system %USERPROFILE%. Also, users who are particularly reliant on the apropos command probably don't know about running the mandb command. It's analogous to users launching the Windows Help and Support Center, but its search bar returning 0 results they haven't run another utility 1st. That's an issue worth resolving. We just need to find a way to do it in a non-abusive fashion. -- WBR, Andrey Repin (anrdae...@yandex.ru) 16.08.2014, 03:57 Sorry for my terrible english... Thanks, I have a much better understanding of the situation now. I agree that there is no simple solution. -Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: man-db-2.6.7-2
The following packages have been updated in the Cygwin distribution: * man-db-2.6.7-2 man-db is an implementation of the standard Unix documentation system accessed using the man command. It uses a Berkeley DB database in place of the traditional flat-text whatis databases. This release removes the cache database generation from the postinstall step due to its often excessive length. Users will need to manage the database themselves with mandb(1) in order to use whatis/apropos(1). -- Yaakov (on behalf of Chris Breisch) CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
