setup.hint format change?
Warren Young
warren@etr-usa.com
Wed Dec 31 05:20:00 GMT 2008
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.
More information about the Cygwin-apps
mailing list