Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Cc: cygwin-apps AT cygwin DOT com
Subject: Re: broken setup.hint files
References: <m3667hsrm9 DOT fsf AT appel DOT lilypond DOT org>
	<3C126412 DOT 1060903 AT ece DOT gatech DOT edu>
Organization: Jan at Appel
From: Jan Nieuwenhuizen <janneke AT gnu DOT org>
Date: 08 Dec 2001 21:03:48 +0100
In-Reply-To: <3C126412.1060903@ece.gatech.edu> (Charles Wilson's message of "Sat, 08 Dec 2001 14:03:46 -0500")
Message-ID: <m3n10tqy1n.fsf@appel.lilypond.org>
Lines: 56
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Charles Wilson <cwilson AT ece DOT gatech DOT edu> writes:

> >      hint="$(echo | cat $i/setup.hint - | grep -Ev '^(prev)|(curr|@) ' | sed -e 's/^\(\(category\)\|\(ldesc\)\|\(requires\)\|\(sdesc\)\|\(test\)\). */\1: /' | grep -v '^$')"
> 
> 
> Ummm...they are not broken.  You just dislike some stylistic choices...

Well, setup.exe barfs on the.  Quoting from inilex.l:

   "sdesc:"		return SDESC;
   "ldesc:"		return LDESC;
   "category:"		return CATEGORY;
   "requires:"		return REQUIRES;

So, after reading this and the setup.hint spec on cygwin.com, I
implemented hinting, in gen-ini.sh and it *broke* setup.exe.  So, I
considered it a bug, and wanted you to know about it.  But if you
don't care, fine.

> Also, blindly removing the prev/curr/test markers is not a good thing 
> either.

For me, it's *a lot* better than a barfing setup.exe.

> Sometimes (when upset's automatic version parser fails)

Who is `upset'?  I haven't seen my version parser fail, but in general
one should not provide the same information from two sources.  Which
do you trust when they do not match?  Why not just have a sane
archive, or fix setup.ini by hand if you don't like it?

If a version parser fails, the offending package (filename) should be
fixed, imo.

> the hints may just be old.

Yes, I guess that they're old.  If old things don't get fixed, the get
bitrot.

> In my case, I will update a given setup.hint to follow that new 
> *recommendation* (not requirement) the next time I update the package 
> controlled by it, and not until then.

Indeed, parts of the cygwin archive are a bit of a mess, but it's too
bad if it's by principle, and not for want of time.

> If it ain't broken (and it ain't) then don't fix it.

Well, sorry to bother you then.  I can keep kludging around this small
thing too.

Jan.

-- 
Jan Nieuwenhuizen <janneke AT gnu DOT org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org