----- Original Message ----- From: "David A. Cobb" <[EMAIL PROTECTED]> To: "Charles Wilson" <[EMAIL PROTECTED]> Cc: "Nicholas Wourms" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Jan Nieuwenhuizen" <[EMAIL PROTECTED]> Sent: Monday, July 08, 2002 8:27 AM Subject: Re: ITP: Guile 1.5.6
> Charles Wilson wrote: > > 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 -- > > including 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) > > > I'm just a plain-nut! Would it be worthwhile, in your opinion, to look > at GNUpdate? At least, it doesn't carry any corporate baggage. Sigh. http://www.cygwin.com/ml/cygwin-apps/2002-07/msg00122.html. Substitute GNUpdate for dpkg. Here is the recipe to get me agreeing with a specific 'native' package format. Semi-formally review the rpm and dpkg and foo backend database information model and provide a reasoned comparison. Include standalone package file meta-information in the comparison if appropriate. Do that, as a report, and I will seriously review its findings. It is not 'my' decision per se - we need group input on this, but I rather suspect that having me in agreement with a proposal will help (or at least remove one rabbit warren generator!). Until then: I am happy with a goal of dpkg|rpm package file reading. I am happy with a goal of dpkg|rpm local database support (with the proviso's I made before). I don't care about corporate baggage - whatever we use will be GPL, and that's open enough for me. I do care about functionality, and dpkg has enough, and AFAIK rpm has enough. I won't be doing a wide scale review of alternatives. If someone here favours one over all others, do an impartial report and advocate we use that instead. Rob
