This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ITP: Guile 1.5.6


Robert Collins wrote:

Setup will use *one* of the above formats. My current preference is the dpkg
one because IIRC it's plain text - which means a smaller setup.exe, and
greater flexability for scripters.

LONG term: ditching custom "database"; using either rpm or dpkg:  <Cool>
Using dpkg instead of rpm: <whatever works>

Well, as both rpm and dpkg are abstractions for the install process, I
imagine that you'd link rpm | dpkg against a cross-storage version of their
internal libraries.

Right, I was using "rpm" as a synonym for librpm; ditto dpkg. Either way, each library needs to be adapted so that it mucks with both databasi. Way in the future. Not now.


My understanding is that dpkg has a superset of rpm's information, making
it's store the appropriate master store.

That would be cool (if true; I dunno).

Anyway, I'd like to suggest an approach:

We need to accomplish 3 things:
1) A cygwin native port of dpkg | rpm. (Both have been accomplished. Anyone
who wants to could contribute a cygwin native package immediately by
leveraging the existing ports out there in the net).

AFAIRC, nobody has ported rpm4 yet. Since it is much more capable than older versions (and fixes a number of bugs), that's probably the way to go -- but it needs db4...



2) Setup support for reading the dpkg | rpm file format as an io_stream
archive.

Good point.


3) Setup support for writing the dpkg|rpm backend database so that the
commandline auto-build tools recognise that the required build depends
packages are installed.

Righto.


Until those three are accomplished, any discussion of how to address backend
syncronisation is just that - discussion. And all three will be needed for
any solution.

Yep.


I really don't have time to spend hypothesising - what we really need is for
someone to semi-formally review the rpm and dpkg backend database
information model and provide a reasoned comparison.

Yep.


Something like:
dpkg stores foo, bar,and ray that rpm doesn't.
rpm stores gamma, delta, sigma that dpkg doesn't.
rpm can|cannot be extended to store foo,bar, ray.
dpkg can|cannot be extended to store gamma, delta, sigma.


Deciding on the appropriate back end database (presuming that we don't want
to create YAPakageFormat) is not something to be done lightly, or one any
one individuals preference.

For now, I'm working on the front end to handle conflicts, provides and
other -useful- stuff.

Understood. Remember this subthread began NOT from a "setup sucks, let's all speculate about how great rpm/dpkg is". It actually grew from "method 2 buildscripts suck. There's 84 different semi-supported ways to build setup-compatible tarballs, but no standard. There must be a better way".

Unfortunately, existing "build tools" (like rpm and dpkg) also double as system maintainance/package installers -- which invades setup.exe's turf. Sorry. :-)

BTW, your message should be on everybody's bookmark list the NEXT time "setup should use rpm/dpkg/yast/whatever" comes up...

--Chuck



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]