ITP: Guile 1.5.6

[Charles Wilson]

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