This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Cygwin needs a man-db port
- From: "Chris J. Breisch" <chris dot ml at breisch dot org>
- To: cygwin at cygwin dot com
- Date: Thu, 17 Apr 2014 14:32:46 -0400
- Subject: Re: Cygwin needs a man-db port
- Authentication-results: sourceware.org; auth=none
- References: <5241EF7D dot 9080309 at xs4all dot nl> <52433E7A dot 4070600 at xs4all dot nl> <524341E5 dot 6080601 at xs4all dot nl> <5322EA04 dot 3040008 at xs4all dot nl>
Erwin Waterlander wrote:
Hi,
The major linux distributions have switched for their man system to
'man-db' (http://man-db.nongnu.org/) in favour of the classic man.
I think that Cygwin should also switch to man-db. man-db is much better
in handling man pages in different encoding.
Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be
ported, because man-db uses it.
I have tried to port man-db to Cygwin, but I did not succeed. I got
stuck in libpipeline. Did anyone else succeed?
Yes. And I agree this is a good idea.
Dependencies: gdbm, libpipeline
Build dependencies: pkgconfig, check, and the typical build stuff (make,
gcc, etc.)
As I indicated earlier, I believe the current version of check is not
working properly.
Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr.
"make check" on check reports all tests passed, despite what appear to
be some failures. The CHANGELOG says that this version should pass all
tests on Cygwin. I've just subscribed to the mailing list and will check
on whether these failures can be ignored or not. Still, it definitely
appears to work better than the version we have now, which only passes 1
test in the test suite.
Libpipeline-1.3.0 seems to work out-of-the-box. Configure with
--prefix=/usr.
Oddly a "make check" for libpipeline-1.3.0 doesn't appear to actually do
anything. This was not the case for earlier versions of libpipeline.
Well, that's one way of getting rid of the test failures, I guess.
Man-db-2.6.7 appears to work out-of-the-box.
Configuring man-db is a little harder than the other two.
../man-db-2.6.7/configure --prefix=/usr --disable-setuid
--docdir=/usr/share/doc/man-db
If you don't add the --disable-setuid, you'll need to add a "man" user
to your system. If you're not using Corinna's snapshots, you'll need to
add the user to /etc/passwd as well.
I'm not sure about the --docdir switch. That seemed to be consistent
with Cygwin, but an actual package maintainer would be a better source
of info on this.
A couple of warnings are generated:
*** Warning: This system can not link to static lib archive
/usr/lib/libpipeline.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
and a similar one for libman.la.
I do have shared versions of these libraries, so I'm not sure why the
warnings appear. I seem to recall a thread about something similar
recently in the Cygwin mailing lists. I may go back and check.
Once installed, you'll want to do a 'mandb -c' to create the database.
It will report numerous warnings which can generally be ignored. See the
manpage on mandb. This takes a while.
When new packages are added or updated on your system, you should run
'mandb -c' again. This seems like something that should be part of
postinstall.
My 32-bit Cygwin install has a lot of gzipped files and the uncompressed
versions under /usr/share/man. mandb didn't like that at all. That is
probably something I did and not a Cygwin problem.
Note that I've done only the most minimal of testing. make check passes
for man-db and I've opened a few man pages. They seem to work.
Obviously, someone with decision making power should decide if this is
something we want to add to Cygwin. My vote is yes, but that's just one
vote. Or maybe even zero. I'm not sure I get a vote. :)
Also obviously, if the decision is to go forward, these three items need
to be packaged up appropriately and a package maintainer assigned. Check
is already a Cygwin package, but needs updating.
Somehow I have a feeling about who will be nominated for this task.
What minimal testing I have done has been on both 32-bit and 64-bit
Cygwin 1.7.29.
--
Chris J. Breisch
--
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