New Maintainer

Charles Wilson
Fri Mar 28 01:59:00 GMT 2008

DRC wrote:
 > Is there a spec for which files go in which packages, etc.?  Any other
> advice to get started, or should I just start downloading and tinkering?

Given the "new" modular structure of the releases, it seems to me 
that each "module" should be treated independently.  However, that being 
said, each "module" may represent multiple tarballs.  E.g.

Take, for instance, the libXext module.  Obviously, you'd have

           ^   ^
           |   +---------- cygwin release number of this version
         upstream version

This should contain, at minimum, the source code you compiled. Ideally, 
it would contain the "pristine" source (a internal libXext-1.0.3.tar.bz2 
tarball), plus any patches necessary for building on cygwin, and a build 
script so that any schmoe could automatically rebuild it and recreate 
your exact binaries.

There are a number of (custom cygwin) tools that can help:
   The "generic build script" referenced in an earlier message
   The "cygport" tool
   Jan Nieuwenhuizen's 'GUB' tool (google...)
   The 'netrel' tool (check cygwin-apps CVS repository)
In this case, I recommend cygport -- for a very good reason below.

Next, the tarballs related to libXext would also include:


This is the "main" binary tarball. It should contain utility programs, 
*basic* documentation (/usr/share/doc/libXext-1.0.3/, man1 manpages, 
info pages), a Cygwin-specific documentation file 
(/usr/share/doc/Cygwin/libXext.README), etc.


This contains any static libraries, import libraries, header files, 
developer and API documentation (such as man3/ manpages), etc.


This contains only and exactly the DLL for libXext: cygXext-6.dll.  Note 
that the DLL number "6" is appended to the package name itself.  This 
helps manage DLL version compatibility issues.

Sometimes, you might choose to put documentation into a separate package 
(such as libXext-doc-1.0.3-1.tar.bz2). Really, it's up to you at that 
point.  We do have to insist on a rational scheme for packages that 
provide DLLs, because otherwise dependency management becomes a nightmare.


So, modular X has a couple dozen separate modules, each of which might 
result in three or four binary "packages" plus the -src package. Whoo.

Guess what (and I'll let Yaakov correct me if I'm overstating this):

with the exception of the Xserver itself, ALL of the other relevant modules have already been ported to Cygwin, packaged in a manner 
compatible with Cygwin's setup.exe, and following the rules laid out above.

Thank you, Yaakov Selkowitz and the cygwin ports project!
The -src packages each include a .cygport file that can be used to drive 
the build, using the cygport tool.

I'm sure that Yaakov would be overjoyed if an official maintainer 
stepped up, and used his cygports to get these packages into the 
official distro.  The only thing that has been holding him up, from what 
I understand, is that he hasn't had time to get the Xserver itself 
working, and didn't want the other modules to go "gold" without the server.

> I assume that part of the duties are to also feed back patches into the
> master repository to fix the Cygwin build, etc.

Ideally, yes.


Unsubscribe info:
Problem reports:

More information about the Cygwin-xfree mailing list