This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Making Cygwin README optional

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

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:

  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 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... :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]