Re: ITP: Guile 1.5.6

["Robert Collins" <robert dot collins at syncretize dot net>]

----- Original Message -----
From: "David A. Cobb" <superbiskit@cox.net>
To: "Charles Wilson" <cwilson@ece.gatech.edu>
Cc: "Nicholas Wourms" <nwourms@netscape.net>; <cygwin-apps@cygwin.com>; "Jan
Nieuwenhuizen" <janneke@gnu.org>
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