Re: setup.hint format change?

[Warren Young <warren at etr-usa dot com>]

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?

> I am not sure that the setup files require XML though.

I agree.

> 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?

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

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

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

- Back in the days before journaling file systems were common on Linux, 
every now and then a system crash would roach the RPM DB.  That hasn't 
happened to me in many years now, roughly corresponding to ext3 becoming 
the default in most Linux distros.  With Cygwin 1.7 requiring an 
NTFS-capable OS, I don't see a reason to worry about it on Windows 
today, either.

- Sometimes you get a dependency tangle.  You can say the same about 
every dependency-aware packaging tool.  Most of these problems come down 
to poorly-made package description files, or mixing RPMs from multiple 
Linux distributions.  Cygwin being so centralized, we shouldn't have to 
worry about either problem.

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'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.