This is the mail archive of the
mailing list for the Cygwin project.
Re: [RFC] Making Cygwin README optional
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: Mailing List: CygWin-Apps <cygwin-apps at cygwin dot com>
- Date: Fri, 18 Mar 2011 11:20:57 -0400
- Subject: Re: [RFC] Making Cygwin README optional
- References: <1300418929.2280.22.camel@YAAKOV04>
- Reply-to: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
On 3/17/2011 11:28 PM, Yaakov (Cygwin/X) wrote:
> I wish to propose that Cygwin READMEs no longer be absolutely required
> for Cygwin packages, for several reasons:
OK by me, in general. That being said, I quibble about some of the
> * Most of the information contained therein is duplicated elsewhere:
> - the package description is in setup.int
a) Nobody can easily SEE the ldesc; AFAIK there is no way to convince
setup.exe to show it, and the individual setup.hints are not downloaded.
You can look in $DOWNLOAD_DIR/setup.ini, but...
b) Even the ldesc in setup.hint is severely truncated in many cases,
since each ldesc adds to the already unwieldy length of setup.ini.
So, I don't really think the ldesc in setup.hint is a suitable
replacement for a more long-format description somewhere else.
HOWEVER, I still agree that this should be the maintainer's decision,
and not imposed by policy (especially if the maintainer thinks that
/usr/share/doc/$PKG/README is already good enough, to not require an
> - runtime deps are handled by setup;
> - rebuild instructions for cygport-based packages are already covered in
> cygport's documentation, and in any case, how to rebuild the source
> package is not really relevant to the *binary* package;
> - the package contents are available through cygcheck;
> - changes in the latest release are already in announcements, and in
> many cases, there may not be any Cygwin-specific changes, just upstream
> ones already covered by ChangeLog/NEWS/etc.
I do like the field that newer cyg-specific readmes have detailing the
license of each package by name:
MIT/X (or BSD or LGPLv3+ or whatever)
Makes it convenient for me, rather than looking for
/usr/share/doc/$PKG/Copying, COPYING, LICENSE, <buried in README>,
But that minor benefit (not even present in all current cyg-specific
readmes) is certainly not reason enough to require one.
Although maybe an optional (free-text) field in setup.hint for this
purpose might be nice?
license: 2-clause BSD
The Language field is kinda useless...it used to be interesting as it
indicated which compiler or interpreter you'd need, but...that info is
available in other ways.
> That leaves build-time deps and long-term package history. For those, I
> would suggest the following:
> * I'm working on a method to add build deps to .cygport(5) files and
> have cygport(1) verify their presence.
That would be great!
> * Each package would get a git repository on sourceware for
> its .cygport, .hint, and other packaging files, as in Fedora and as I
> started doing in Ports.
Maybe that is what it would take for me to finally start using source
control on these things, instead of unpacking the prev release's -src
each time... :-)