New Maintainer

[Charles Wilson]

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

libXext-1.0.3-1-src.tar.bz2
           ^   ^
           |   +---------- 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:

libXext-1.0.3-1.tar.bz2

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.

libXext-devel-1.0.3-1.tar.bz2

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

libXext6-1.0.3-1.tar.bz2

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.

See:
http://cygwin.com/ml/cygwin-apps/2005-07/msg00228.html


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 
X.org 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!
ftp://sunsite.dk/projects/cygwinports/release/X11/
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 X.org 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 X.org 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 X.org repository to fix the Cygwin build, etc.

Ideally, yes.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/