This is the mail archive of the
mailing list for the Cygwin project.
RE: ITP: Guile 1.5.6
- From: "Robert Collins" <robert dot collins at syncretize dot net>
- To: "'Charles Wilson'" <cwilson at ece dot gatech dot edu>,"'Nicholas Wourms'" <nwourms at netscape dot net>
- Cc: <cygwin-apps at cygwin dot com>,"'Jan Nieuwenhuizen'" <janneke at gnu dot org>
- Date: Fri, 5 Jul 2002 08:58:12 +1000
- Subject: RE: ITP: Guile 1.5.6
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Charles Wilson
> Sent: Friday, 5 July 2002 6:13 AM
> Now, all of the RPM-nuts are jumping up and down screaming
> "RPM! RPM!"
> right now -- and the Debian faction is yelling "dpkg! dpkg!". BEFORE
> voicing that, please go back and READ the 27,374 threads
> where this has
> been suggested in the past. Here's a summary:
> -- setup.exe must be able to install the packages
> -- setup.exe is a native windows program
> -- therefore, we'd need
> + a native port of rpm, or
> + change our whole modus operandi to a "two-step" procedure;
> natively install the "core" packages from regular tarballs --
> an rpm package -- using a native setup.exe, and then use a different
> tool for system maintainance (or use setup in a different
> "mode" where
> it exec's the cygwin rpm.exe -- but this leads to other problems: a
> cygwin-dependent rpm.exe won't be able to update the cygwin package,
> unless some of the 'in-use-replace' magic from the current setup is
> grafted into rpm)
> All of these same arguments apply to dpkg. So stop yelling
> "RPM! RPM!"
> or "dpkg! dpkg!" and THINK a bit.
An interesting data point (not intended to fan the flames). Both rpm and
dpkg have been ported multiple times to <cygwin>, but with one
exception, not natively. The exception is a win32 install using dpkg
natively (or at least I think it's natively).
Also a data point: reading rpm or dpkg files is not the challenge. The
challenge is providing (and maintaining) the base infrastructure that
dpkg and rpm expect. (ie a static bezerkly db for rpm, and a plethora of
support scripts (i.e. update-alternatives) for dpkg.) And finally,
grokking and processing correctly the dependency/conflicts/ording issues
that apply to dpkg and rpm. (There's not much point saying, hey guys,
build rpm's and setup will install them, if every single .spec file
needs to be altered because cygwin uses something different for a key
dependency. We've been through package renames. It used to be ugly, but
it's still not pretty.
Fortunately setup is slowly creeping along a path to where rpm or dpkg
support will be purely the file format, not the other stuff. It would be
nice to end up supporting dpkg and rpm packages to allow folk their
** WARNING **
If no one submits a patch for rpm compatability or dpkg compatability
with setup, then what you get will be what I code.
I happen to be a dpkg convert. So that will come along eventually.
However, rpm does nothing for me, so ... It will need a contributor to
add that. I'm happy to discuss timeframes, requirements, order of
feature addition etc with a motivated contributor.
** END WARNING **.