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>
- Cc: "'Nicholas Wourms'" <nwourms at netscape dot net>,<cygwin-apps at cygwin dot com>, "'Jan Nieuwenhuizen'" <janneke at gnu dot org>
- Date: Fri, 5 Jul 2002 12:25:16 +1000
- Subject: Re: ITP: Guile 1.5.6
- References: <000f01c223ae$468506c0$0200a8c0@lifelesswks> <3D24E498.firstname.lastname@example.org>
----- Original Message -----
From: "Charles Wilson" <email@example.com>
To: "Robert Collins" <firstname.lastname@example.org>
> Yah, but custom spec files are no worse than custom build scripts (e.g.
> method 2) -- and custom spec files are probably *better* than method2
> scripts. Spec-language is much higher level...and rumor has it that
> rpm4 supports XML for spec files...
Likewise for debian build recipes. The point is that the issue isn't reading
the format, it's the associated difficulties - like the database
syncronisation you mention below. I can download a binary of dpkg and build
.deb files for cygwin now - but it won't help setup.
> The thing that worries me about this grand plan is database
> syncronization. Suppose dpkg, rpm, and today's tarball-oriented setup
> are all supported.
Check. This is a nice goal. I would like to see the tarball oriented setup
data stored in the backend database. It's one reason I've not been tweaking
the local storage, I'd rather just leverage an existing database format.
> rpm stores the installed package list in /var/lib/rpm/???
> dpkg stores its database in <I dunno>...
I do :}, but only when I go refer to my notes.
> setup uses /etc/setup/*.lst.gz and /etc/setup/installed.db, plus
> setup.ini for conflicts/dependency.
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.
> Fine, we can make sure that setup automatically updates all three
> databases. But what if I run the "standalone" rpm.exe to install a
> package? That'll update rpm's database -- but not dpkg's or setup's.
> Ditto dpkg. How to solve this problem? Manual synchronization?
> (blech). Setup first magically synchronizes the databases? Okay, but
> which one is "right" -- and this means you must run setup.exe before
> "switching" from rpm to dpkg, or vice versa -- it basically boils down
> to manual synchronization. (blech again)
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
> Patch rpm and dpkg to update all the other databases too? Patch rpm and
> dpkg to use setup's database instead? (or patch setup and dpkg to use
> rpm's, or patch setup and rpm to use dpkg's?) Blech -- and probably
> heresy to the various factions <g>. Actually, the various databases all
> support different information sets -- so it's not really clear that you
> CAN take an rpm database and magically create all the data necessary to
> populate a dpkg database (or vice versa, or throw setup in the mix).
My understanding is that dpkg has a superset of rpm's information, making
it's store the appropriate master store.
> This is a *hard* problem. How does 'alien' handle this?
AFAIK: It reads the rpm file format, and matches dependencies against the
dpkg database, and adds the package to the dpkg database. I haven't looked
all that closely :}.
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).
2) Setup support for reading the dpkg | rpm file format as an io_stream
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.
Until those three are accomplished, any discussion of how to address backend
syncronisation is just that - discussion. And all three will be needed for
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.
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.