[ITP] qt3-3.3.4

Igor Pechtchanski pechtcha@cs.nyu.edu
Thu Sep 29 05:00:00 GMT 2005

On Wed, 28 Sep 2005, Nicholas Wourms wrote:

> On Fri, 02 Sep 2005 13:52:30 -0500, in gmane.os.cygwin.applications
> you wrote:
> [SNIP]
> Yaakov,
> 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.

Two firsts, eh?  That's a first! :-) (SCNR)

> I have some suggestions about the packaging:
> 1)
> 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}`


winbase="`cygpath -m "${srcdir}"`"

>   mkdir -p ${srcdir}

mkdir -p "${srcdir}"

>   mount -u -omanaged ${winbase} ${srcdir}

mount -u -omanaged "${winbase}" "${srcdir}"

>   tar xv${opt_decomp}f "$1"
> }
> and modify finish() like so:
> finish() {
>   rm -rf ${srcdir}
>   umount -u ${srcdir}

Actually, I've seen some weird behavior when attempting to remove a
mounted directory, so it's probably better to unmount first.  And, of
course, the quoting

umount -u "${srcdir}"
rm -rf "${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*`

This one assumes that man will be doing case-insensitive searches...

>   2) Put man1 and the all-lowercase man3 in:
>      /usr/share/qt3/doc/man/man{1,3}
>      Then put the mixed-case man3 in:
>      /usr/share/qt3/doc/mann/man3
>      Update MANPATH scripts to reflect this.

This, IMO, is the best solution...

>   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.

Hmm, managed mounts are an experimental feature.  They're fine and good
for building from source, but I don't think they should be automatically
created for every user installing Qt.  Not yet, at any rate.

> 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.

I'd create an /etc/profile.d script that fixes up MANPATH...  Don't forget
to leave a trailing ':'...

> 2)
> 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:
> libqt340-3.4-1
> 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:
> /usr/bin/cygqt34-mt-0.dll
> /usr/bin/cygqui34-0.dll

Right.  See Chuck's essay on the topic -- it's in the cygwin-apps

> 3)
> 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.

This makes sense...

> So, for example, the base package qt3-3.4-1, might contain:
> [snip]
> 4)
> Just a thought, but you might considier merging -doc into -devel, to
> cut down on the number of packages.

This doesn't.  People who want the documentation may not want the
headers...  Either merge the whole kit'n'caboodle into the base package,
or have functional packages...

> 5)
> 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),

Okay, are there any plans to submit patches so that hacking the g-b-s in
this way is easier?

> 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.

Using the g-b-s for new packages is certainly encouraged nowadays...  And,
as always, PTC.
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

More information about the Cygwin-apps mailing list