[ITP] qt3-3.3.4

Nicholas Wourms nwourms@gmail.com
Thu Sep 29 02:17:00 GMT 2005

On Fri, 02 Sep 2005 13:52:30 -0500, in gmane.os.cygwin.applications
you wrote:



First, thank you for packaging this.  I was supposed to do it 2 years
ago but I never got around to it.  First, libtool actually names
plugins the way you did, so no need to worry there.

I have some suggestions about the packaging:

The manpages are screwed up.  The issue, as you know, is that there
are a number of manpages which have the same name/different case.  For
each pair that does so:

- All of the all-lowercase manpages contain actual manpage content.
- All of the mixed-case manpages contain a groff .so link to the
corresponding all-lowercase version.

So, for example, you have:
  - qaccessibleobject.3qt
  - QAccessibleObject.3qt

The qaccessibleobject.3qt contains the actual content and the
QAccessibleObject.3qt contains just '.so man3/qaccessibleobject.3qt'.

The first thing you need to do is make sure that the lowercase
manpages aren't clobbered by the mixed-case ones when the package is
untarred.  Fortunately, newer cygwin dlls contain an undocumented
feature which allows you to mount a directory where files can exist
with the same name/different case.  This is called a 'managed' mount.
One source package, gcc, is actually using managed mounts as part of
the build (since gcj has case issues).  Anyhow, you would change
unpack() in the generic build script like so:

unpack() {
  winbase=`cygpath -m ${srcdir}`
  mkdir -p ${srcdir}
  mount -u -omanaged ${winbase} ${srcdir}
  tar xv${opt_decomp}f "$1"

and modify finish() like so:
finish() {
  rm -rf ${srcdir}
  umount -u ${srcdir}

Ok, so that stops the clobbering, now you have three options on how to
deal with the actual packaging of the manpages.

  1) `cd doc/man && rm -f Q*`

  2) Put man1 and the all-lowercase man3 in:

     Then put the mixed-case man3 in:


     Update MANPATH scripts to reflect this.

  3) Make /usr/share/qt3/doc/man a managed mount.

Unfortunately, #3 is out of the question since setup.exe does not
(yet) support the creation of managed mounts.  Nor can packages direct
it to do so (though I suppose if it supported pre-install scripts,
maybe it could).  However, when, and if it does, I would definitely go
with this method.

Option #1 is the easiest, but you might cause problems in
cross-references that want mixed-case pages (for programs which
interpret troff cross-references).

Option #2, given the current state of cygwin and setup.exe, is
probably your best bet.  Given that you already modify the MANPATH,
this should not be that hard to integrate into the packaging.


The versioned dll's should go into a different package.  In theory,
that should allow a person to just install only them, with no other
items.  So, for example, I would put them in a package using the
following template:

libqt{major}{minor}{dll version}

So, for example, it would be:


And you would bump the dll version whenever an incompatible change was
introduced.  I think it is critical to plan ahead for possible
incompatible changes in the API which windows is hypersensitive to,
especially with c++ libraries.

So, for example, maybe libqt340-1 should contain:

Now that versioned dlls are out of the main package, you should
probably merge the -bin package into the base to cutdown on the number
of packages.

So, for example, the base package qt3-3.4-1, might contain:


Just a thought, but you might considier merging -doc into -devel, to
cut down on the number of packages.

As a former Gentoo package developer I was quite surprised to see that
the buildscript is an ebuild (sorta).  I think it is cool that you've
hacked portage to support Cygwin.  However, in converting it from an
ebuild to a standalone script, I think that you've reinvented the
wheel.  A modest suggestion, just use the Generic Build Script
provided by Cygwin and keep the ebuild stuff seperate.  Once you've
fixed the GBS template to handle multiple packages (see gettext for
how), I should think it would take no longer to make new  packages
than it had with the ebuild-base template.  Although it isn't required
now, I think the hope is that someday we can standardize the
buildscripts so that we have some uniformity.

I've only visually inspected the packages, but it's definitely a good
start.  I'll try them out later when I get on a machine that doesn't
already have a local installation of qt.


More information about the Cygwin-apps mailing list