setup.hint format change?

[Christopher Faylor]

On Tue, Dec 30, 2008 at 10:19:10PM -0700, Warren Young wrote:
> Christopher Faylor wrote:
>>>> Would anyone mind if I changed the format of setup.hint to some
>>>> existing markup language?
>
> What problems are you trying to solve?

The one in the paragraph that you snipped.

>>yaml
>
>This seems closest to the current setup.hint format, and appears well
>supported.
>
>I only question whether it provides anything we really need.
>Hierarchical data structures?  Cross-references?  List/array
>functionality?  How do these help?

It provides a parser that I don't have to write for a fairly popular
and well-understood markup language.

>>curly ml
>
>There's only one library linked from the sf.net pages, written in Java,
>and it hasn't been touched in over two years.  Seems like a dead end.
>
>One you didn't list, which is simple and quite well supported, is JSON.
>There are parsers for it now for every major language, so don't let the
>"JS" throw you off.  Plus, it might allow a faster cygwin.com/packages
>page.  Mmmmm....yummy Ajax.  :)

Actually, I probably meant json when I said curly ml.  I went back
quickly through the list of things that I considered and chose the wrong
one.

Since I'm planning on putting things in a database, that is what will be
generating the package list.  So, if I really do this, I'll probably go
with YAML.

>>I'm also wondering if we should just be using rpm and forgetting about
>>our own package format.
>
>I for one would prefer to be managing my Cygwin installations with yum
>and rpm, and much prefer spec files to Cygport, the best current Cygwin
>packaging tool.  There's also hope when doing this that existing RPMs
>could more readily be ported to Cygwin, sometimes even with no changes.

It's a possibility but I did this for two years at my last job and found
very few packages that just worked on Cygwin.  Or even just worked on
different versions of linux for that matter.  RPM maintainers aren't
generally very good at thinking about portability.  It's possible that
this has changed since 2006 but I suspect that it is still a problem.

>>Of course rpm comes with its own set of problems.
>
>I've been using RPM-based distributions since the mid 90's, and can
>only think of two serious RPM-related problems I've encountered:

We've discussed RPM and other package managers here a few times.  The
biggest problem is that it or any other linux-based package manager
requires the Cygwin DLL to work.

The other problem is that the RPM database can get fairly big and can
become corrupted.

>On this note, I offer an unasked-for anti-vote for DEB.  I'd rather
>stick with the incompleteness of Cygport than the complexities of
>debian/* trees.  RPM packages are far easier to maintain than packages
>for these other two packaging systems, and lack for nothing I want in a
>packaging system.

I don't necessarily agree with that.  I've used Debian and Gentoo and
neither bothers me much.  However, since Cygwin is owned by Red Hat I
think it would be a little strange to be using anything besides RPM.

>I'll also note that the most trouble I've had with a packaging system
>in recent memory is with Sun's new Image Packaging System in Solaris.
>I've twice made Solaris boxes unbootable just by playing around in
>their GUI package manager, without even trying to force anything.  The
>tool happily collaborated with a Solaris newbie (me) to author its own
>demise.  I attribute this to IPS's 1.0ness.  This is another reason I
>like the RPM option; I've never killed a Linux box just with RPM.

I don't want to go down the horror story path too far but I have to note
that my son very nearly bricked his Mac laptop by cancelling an software
update.  If google is to be believed, he wasn't the only one either.  So
I don't think we've yet reached the state of package manager perfection.

Except maybe for setup.exe.  That's nearly perfect of course.

cgf