This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
- From: Michael DePaulo <mikedep333 at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 16 Aug 2014 01:48:39 -0400
- Subject: Re: [ANNOUNCEMENT] Updated: man-db-2.6.7-2
- Authentication-results: sourceware.org; auth=none
- References: <announce dot 53EDA004 dot 7060207 at cygwin dot com> <CAMKht8jp2tA1SLtXpSs1=ubrfTNQkpwzNUHW7omo0OF4=cvXuw at mail dot gmail dot com> <53EE1737 dot 7080306 at cygwin dot com> <CAMKht8jpQVfDhDorom24OiJ9YE07zBqjDSF5zVfWiFsdN1kaUg at mail dot gmail dot com> <496613926 dot 20140816040503 at yandex dot ru>
On Fri, Aug 15, 2014 at 8:05 PM, Andrey Repin <email@example.com> wrote:
> Greetings, Michael DePaulo!
>>>>> This release removes the cache database generation from the postinstall
>>>>> due to its often excessive length. Users will need to manage the
>>>>> 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
>> 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.)
>>>> Also, should documentation (or perhaps the info a user sees when they
>>>> start Cygwin for the 1st time) be updated?
>>> How so?
>> 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.
> Andrey Repin (firstname.lastname@example.org) 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple