This is the mail archive of the
mailing list for the Cygwin project.
Re: Maintainer newbie questions
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 03 Jul 2007 13:25:05 -0700
- Subject: Re: Maintainer newbie questions
- References: <468A8935.firstname.lastname@example.org>
Steffen Sledz wrote:
> 1. What's the best way to find all the dependency information needed for
> hint files if multiple binary packages (with own hint files) are made
> from the same source? Calling cygport with the deps parameter does not
> split the dependencies to different packages.
By running cygcheck on each binary/DLL in each package, just just by knowing
e.g. "this package requires files from package foo at runtime so this package
needs to require foo."
> 2. Is there an automatic way to determine the Runtime requirements for
> the different README files?
Essentially the same as above. Don't get caught up with worrying about specific
version numbers; list the version installed on your machine when you built the
> 3. Same question for the build requirements.
There's no automatic way to determine this, you just have to know which
developer tools are required to build the software. For the most part it's
pretty straightforward, e.g. it requires the 'make' package if a step was typing
make, and if there's C code you require 'gcc' (which automatically pulls in
binutils and w32api, so you don't really need to mention those, but some people
still do.) You also need to list the corresponding -devel packages of any
libraries that your package links to, which you determined above. If you're
using cygport then that favors running autoreconf at configure time instead of
running it on the builder's machine and including changes to generated files in
the patch, so you'd want to list autoconf/automake/libtool/m4 as build
requirements if you use cygport.
> 4. What's the best way to install/test the self-made packages? Is it
> necessary to install an own Cygwin mirror and run the genini script?
There are several ways. You can run a local "mirror" that is just a directory
of files and point setup.exe to it with "Install from local directory". There's
no need to actually run a server of any kind, nor is there a need for the
"mirror" to contain any files but the packages you're testing. But this will
still require a setup.ini, which you can generate from setup.hints with genini.
Of course, using an actual http server for this does make it easier for anyone
else to test your packages as they can just enter the URL in setup. And also
you'll need to eventually have them on a server somewhere so that they can be
copied to sourceware.org.
Alternatively you can just take your binary packages and "tar -C /" them to
simulate installation, and then run any postinstalls manually. Obviously this
isn't the greatest way to test things (as it doesn't exercise their actual use
pattern) but it's reasonable in a bind.