Missing /opt/local/share/man/whatis DB

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Missing /opt/local/share/man/whatis DB

Stephen Baber
Hi MacPorts architects/maintainers,

Author of JPortsUI here.  I have built features into the next version
of my application that use the "whatis" DB to describe the executable
files installed after MacPorts completes a "port install foo".
Presently I am letting the user know that this feature won't work for
them until they Terminal in and run "sudo /usr/libexec/makewhatis
/opt/local/share/man".

My question is, were there configuration consequences that MacPorts
needed to avoid as the reason it does not "makewhatis" itself upon
updating or installing ports?  All I can foresee is that the
additional information might change expected responses from "apropos"
(which would never be used in a production shell script anyway).
Should I not even be encouraging my users to run "makewhatis" in your
"/opt/local/share/man/" directory?

Thanks,
Steve
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

Ryan Schmidt-24

On Jun 20, 2017, at 18:53, Stephen Baber wrote:

> Hi MacPorts architects/maintainers,
>
> Author of JPortsUI here.  I have built features into the next version
> of my application that use the "whatis" DB to describe the executable
> files installed after MacPorts completes a "port install foo".
> Presently I am letting the user know that this feature won't work for
> them until they Terminal in and run "sudo /usr/libexec/makewhatis
> /opt/local/share/man".
>
> My question is, were there configuration consequences that MacPorts
> needed to avoid as the reason it does not "makewhatis" itself upon
> updating or installing ports?  All I can foresee is that the
> additional information might change expected responses from "apropos"
> (which would never be used in a production shell script anyway).
> Should I not even be encouraging my users to run "makewhatis" in your
> "/opt/local/share/man/" directory?

Other developers may have other answers as to why MacPorts doesn't do this, but for myself, the answer is that I'm not aware of makewhatis or what it does.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

Dave Horsfall
On Wed, 21 Jun 2017, Ryan Schmidt wrote:

> Other developers may have other answers as to why MacPorts doesn't do
> this, but for myself, the answer is that I'm not aware of makewhatis or
> what it does.

It's a basic Unix command; it rebuilds the manpage indices.  Got to your
favourite shell window and type "whatis man", for example.

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

Richard L. Hamilton-3
And ideally, anything that installs (or removes) man pages from a man page directory should, after installing (or removing) the pages, run makewhatis, e.g.

/usr/libexec/makewhatis /opt/local/'share/man

to regenerate the index for that man page hierarchy.

That would (assuming /opt/local/share/man is in MANPATH or in /etc/manpaths or an /etc/manpaths.d file) allow "whatis" (or man -k) to find the pages.

It's not perfect; some man pages may not play nice with it.  But if you don't run makewhatis, it definitely won't work.

> On Jun 21, 2017, at 22:48, Dave Horsfall <[hidden email]> wrote:
>
> On Wed, 21 Jun 2017, Ryan Schmidt wrote:
>
>> Other developers may have other answers as to why MacPorts doesn't do
>> this, but for myself, the answer is that I'm not aware of makewhatis or
>> what it does.
>
> It's a basic Unix command; it rebuilds the manpage indices.  Got to your
> favourite shell window and type "whatis man", for example.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."
>


signature.asc (859 bytes) Download Attachment
db
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

db
On 22 Jun 2017, at 05:09, Richard L. Hamilton <[hidden email]> wrote:
> And ideally, anything that installs (or removes) man pages from a man page directory should, after installing (or removing) the pages, run makewhatis, e.g.
>
> /usr/libexec/makewhatis /opt/local/'share/man

If you have man 1.6g via macports you might want to use `sudo makewhatis -w`, but it doesn't seem to work.

-w     Use manpath obtained from `man --path`

$ sudo makewhatis -w
tr: Illegal byte sequence

On the other hand

$ sudo /usr/libexec/makewhatis -v `man --path | tr : ' '`

works but duplicates some entries, as expected I suppose.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

Rainer Müller-4
In reply to this post by Stephen Baber
On 2017-06-21 01:53, Stephen Baber wrote:

> Author of JPortsUI here.  I have built features into the next version
> of my application that use the "whatis" DB to describe the executable
> files installed after MacPorts completes a "port install foo".
> Presently I am letting the user know that this feature won't work for
> them until they Terminal in and run "sudo /usr/libexec/makewhatis
> /opt/local/share/man".
>
> My question is, were there configuration consequences that MacPorts
> needed to avoid as the reason it does not "makewhatis" itself upon
> updating or installing ports?  All I can foresee is that the
> additional information might change expected responses from "apropos"
> (which would never be used in a production shell script anyway).
> Should I not even be encouraging my users to run "makewhatis" in your
> "/opt/local/share/man/" directory?

This request goes in a similar direction than what we have already
pending for info for a long time:

https://trac.macports.org/ticket/777

Technically, there is no hold up to add functionality to run makewhatis
automatically, it just needs someone to do it. In the current state,
running makewhatis manually is safe.

Going further into the development idea for base, that would ideally be
a generic hook interface for activate/deactivate. There are lots of
ports that would benefit from this, all that are running utils to update
databases after port activation.

In addition to man and info, I can immediately think of:

  xmlcatmgr
  update-mime-database (shared-mime-info)
  update-desktop-database (desktop-file-utils)
  gtk-update-icon-cache (gtk{2,3})
  ...

Rainer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

Richard L. Hamilton-3
Might add fc-cache to your list of programs that a port might want to run following activate/deactivate, or is that already being done as applicable?

Alll this sort of thing that could be automated seems great to me, provided it doesn't extend to that which people might reasonably want to keep in a fixed configuration despite activation/deactivation of ports; or if there were an option to disable those automatic actions which there's some slight case for wanting to do manually.

> On Jun 22, 2017, at 08:57, Rainer Müller <[hidden email]> wrote:
>
> On 2017-06-21 01:53, Stephen Baber wrote:
>> Author of JPortsUI here.  I have built features into the next version
>> of my application that use the "whatis" DB to describe the executable
>> files installed after MacPorts completes a "port install foo".
>> Presently I am letting the user know that this feature won't work for
>> them until they Terminal in and run "sudo /usr/libexec/makewhatis
>> /opt/local/share/man".
>>
>> My question is, were there configuration consequences that MacPorts
>> needed to avoid as the reason it does not "makewhatis" itself upon
>> updating or installing ports?  All I can foresee is that the
>> additional information might change expected responses from "apropos"
>> (which would never be used in a production shell script anyway).
>> Should I not even be encouraging my users to run "makewhatis" in your
>> "/opt/local/share/man/" directory?
>
> This request goes in a similar direction than what we have already
> pending for info for a long time:
>
> https://trac.macports.org/ticket/777
>
> Technically, there is no hold up to add functionality to run makewhatis
> automatically, it just needs someone to do it. In the current state,
> running makewhatis manually is safe.
>
> Going further into the development idea for base, that would ideally be
> a generic hook interface for activate/deactivate. There are lots of
> ports that would benefit from this, all that are running utils to update
> databases after port activation.
>
> In addition to man and info, I can immediately think of:
>
>  xmlcatmgr
>  update-mime-database (shared-mime-info)
>  update-desktop-database (desktop-file-utils)
>  gtk-update-icon-cache (gtk{2,3})
>  ...
>
> Rainer
>


signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Missing /opt/local/share/man/whatis DB

Rainer Müller-4
On 2017-06-22 15:30, Richard L. Hamilton wrote:
> Might add fc-cache to your list of programs that a port might want to
> run following activate/deactivate, or is that already being done as
> applicable?

All of what I listed is done by ports and as you said, the same is done
with fc-cache. These ports currently have to implement this explicitly
with post-activate/post-deactivate phases.

While this works for these ports at the moment, explicitly adding
makewhatis to every port that installs man pages just does not seem
reasonable...

Rainer
Loading...