Mail Archives: cygwin-apps/2001/12/09/00:25:51
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
- Raw text -