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 rationale, below... > * 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 additional /usr/share/doc/Cygwin/$PKG.README) > - 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: License: 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>, etc. 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... :-) -- Chuck