[ITP] man-db

Chris J. Breisch chris.ml@breisch.org
Mon Jun 2 15:36:00 GMT 2014

I replied to this off-list accidentally.

Yaakov (Cygwin/X) wrote:
 > On 2014-05-30 12:32, Yaakov (Cygwin/X) wrote:
 >> I started reviewing this, see inline.
 > My modifications can be found here:
 > https://sourceforge.net/p/cygwin-ports/man-db/
 >> On 2014-05-30 09:22, Chris J. Breisch wrote:
 >>> Still, I've put up a new set of files, now. I eliminated the library
 >>> package for a few reasons.
 >>> 1) The libraries can't be compiled into DLL's without some effort.
 >>> They appear to have unresolved references.
 >> I'm looking into this.
 > There are two issues here:
 > 1) The "undefined symbols not allowed in $host shared libraries" warning
 > just means that you need to add -no-undefined to *_la_LDFLAGS. In fact,
 > that's the only issue with making libman shared. (See my
 > 2.6.7-shared-libman.patch)
 > 2) OTOH, libmandb also depends on two global variables which are meant
 > to be defined by executables. In order to make this shared, the global
 > declarations need to be moved to libmandb itself, while the executables
 > still define their values, making for a somewhat larger patch. (See my
 > 2.6.7-shared-libmandb.patch)

Yes, it figures. I had looked into libmandb, not libman. And had noticed 
this, so I never went any farther.
 > This latter patch may be harder to carry from one version to the next,
 > and if another executable is added which depends on libmandb and you
 > forget to adapt it accordingly, it will crash. So I'm actually going to
 > suggest that you NOT use the latter, and leave libmandb static (which is
 > the smaller of the two anyway).

Makes sense to me.
 >>> 2) There's no simple set of include files related to just the
 >>> libraries. I could put out all of the includes, but it looks to me 
as if
 >>> that would get messy rather quickly.
 >> These libraries are private, that's why no headers are installed. The
 >> libraries are shared just to save space by not duplicating the same
 >> objects in all the binaries.
 > This stands; there should be neither a -libs nor -devel subpackage.
 >>> I also updated the postinstall and preremove scripts to handle creation
 >>> and removal of the database.
 > I made some changes to these, but I'm wondering if we need a special
 > _update-mandb package (similar to _update-info-dir) to manage this
 > instead. Thoughts?

Possibly. It would not be a bad idea for the database to updated when 
new packages are installed. However, it looks like to me that 
update-info-dir wipes and recreates the info files. It's rather time 
consuming to create the initial mandb database, and I'd be hesitant 
about doing that every time someone installs something. Perhaps I'm 
misunderstanding what you're suggesting.
 >>> This being my first attempt, I'm sure I've done something wrong. Just
 >>> let me know what it is and I'll fix it promptly (and it actually should
 >>> be promptly this time as my crisis is now under control).
 > Other changes I made:
 > * Use explicit --with-browser and --with-pager flags to not be affected
 > by builder's environment (e.g., on my system BROWSER=epiphany , and
 > added these to REQUIRES.

 > * po4a is a build requirement for localized manpages of man itself; I
 > just added this to the 64-bit distribution, and will attempt to do so
 > soon for the 32-bit distribution as well.

 > Please review the changes I made in my .cygport, let me know if you have
 > any questions.
I think this looks good. I'll see about producing another build in the 
morning using these patches. I'm away from the machine I've been 
building from at the moment.
 > Yaakov

Thanks, Yaakov. This has been a big help.

Chris J. Breisch

More information about the Cygwin-apps mailing list