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
Message-ID: <3C12F5CD.9030400@ece.gatech.edu>
Date: Sun, 09 Dec 2001 00:25:33 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jan Nieuwenhuizen <janneke AT gnu DOT org>
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> <m3n10tqy1n DOT fsf AT appel DOT lilypond DOT org>	<3C1283D0 DOT 3090201 AT ece DOT gatech DOT edu> <m3wuzxp8y2 DOT fsf AT appel DOT lilypond DOT org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)

Jan Nieuwenhuizen wrote:


>>Ah -- upset is the setup.hint parser that creates setup.ini.  You seem 
>>to have written your own setup-ini builder and called it
>>'gen-ini.sh'.
>>
> 
> Yes, I looked around and asked once before but.
> 
> 
>>I am not going to "fix" my setup.hint files to make your parser happy -- 
>>the only parser I care about is the REAL one, upset.
>>
> 
> Now that you've sent the code to upset, that seems a lot more
> reasonable.


Actually, now that I think about it, I should have asked Chris for 
permission to post his code (sorry Chris).  It is not part of the public 
src archives for a reason...more below.

 
>>  Also, us normal cygwin maintainers CANNOT force the upstream 
>>maintainers to use a sane naming scheme (see below).
>>
> 
> Ok, but cygwin could do some sanatising? 


No.(*)  "Is foo-09 the same as foo-9?"  "Yes, we renamed it so that it 
would sort properly against foo-10." "That was dumb".

Where do you stop?  Since the gettext package provides the "intl" 
libraries, should we rename them to intl-?  Should we assume that all 
packages will eventually reach version 10, and rename everything with a 
single-digit versionnumber (-x) to -0x as a proactive strike?

(*) In the interests of full disclosure: my 'jpeg' package contains 
'jpegsrc'. So there's some 'imposed sanity' in one of my packages -- but 
I claim immunity by ex-post-facto: jpeg is one of the oldest packages 
that is part of cygwin, and I contributed it long before we discussed 
renaming packages or source code naming schemes...

 
>>the new *recommendation* is to NOT specify curr/prev in setup.hint
>>and rely on upset's parsing of archive names.  [..] If your parser
>>doesn't work, that's not my problem.
>>
> 
> Ok.  Too bad I didn't have update before.
> 
> 
>>It's not principle or want of time.  AFAICT, there is no mess.
>>
> 
> I would never have introduced bz2,


some people care about bandwidth.  Also, eventually Robert plans to 
support other archive types -- rpm?  deb?

> or if I had, I would surely have
> run a small script like:
> 
>     gzip -dc $foo.gz | bzip2> $foo.bz2
> 
> over the archive. 


Oh boy.  That would REALLY screw up setup.  See robert's message.

> There are now two flavours of -src.tar.* packages.


later there will be even more.


> There are quite some packages (patched!) that don't do --srcdir builds
> anymore.  etc.  


Take those issues up with the maintainer of the specific package you are 
concerned about.  Provide patches to enable that package to build 
"correctly" (in your opinion).

> Small things that make `make world' mode hairy.


Make world is not a goal.  It's not something anybody is going to go out 
of their way to BREAK -- but neither is anyone inclined to go out of 
their way to ENABLE.  If you want it, provide patches to the individual 
package maintainers and they may consider using them.

 
>>How about don't "kludge around it" -- try fixing your parser.
>>
> 
> Sure.  But I still think that running a script once, that replaces
> some spaces with commas, is way better than writing (and carrying
> along) more (hairy) code...


Right.  Eventually, setup.exe will gain the ability to parse the 
setup.hints directly, AND the setup.hints will be incorporated directly 
into the -src archives (robert's "self-describing source package" model)

Until then, we have a two step process...setup.hint --(upset)--> 
setup.ini --(setup.exe)--> installation

 
>>the precursor to cgf's current upset.
>>
> 
> Thanks!  [Why] isn't this is cvs!?


Because it is completely and totally unsupported for any use except 
"there is a cron job on sourceware that runs upset at regular intervals 
to create the official setup.ini".  Chris posted that precurser script 
because we begged for it -- but he made strong disclaimers of 
non-support. (and I haven't seen the "real" upset script).

The fact is, there is only limited utility (yet) for any machine other 
than sourceware to ever try to generate a setup.ini.  (Yes, there are a 
few cases, but quite rare...)  Therefore, cgf had reservations about the 
inevitable support load he would encumber if he released upset -- too 
much cost, not enough (global) benefit.  Therefore: unsupported and not 
widely available.


> Ah, not fair, 200 lines of perl, where I only have 100 lines of bash.
> No wonder my scripts lacks some features.


Yeah.  But you assumed that it was the setup.hints on sourceware that 
had a problem -- and went so far as to post "corrected" ones on a public 
webserver -- instead of considering the possibility that your 100 lines 
of bash were not quite feature-rich enough.  *That's* what rubbed me the 
wrong way -- but I am sorry for the rant-ness of my earlier message.

--Chuck