Re: ITP: Guile 1.5.6

[Charles Wilson <cwilson at ece dot gatech dot edu>]

Robert Collins wrote:

> Also a data point: reading rpm or dpkg files is not the challenge. The
> challenge is providing (and maintaining) the base infrastructure that
> dpkg and rpm expect. (ie a static bezerkly db for rpm, and a plethora of
> support scripts (i.e. update-alternatives) for dpkg.) And finally,
> grokking and processing correctly the dependency/conflicts/ording issues
> that apply to dpkg and rpm. (There's not much point saying, hey guys,
> build rpm's and setup will install them, if every single .spec file
> needs to be altered because cygwin uses something different for a key
> dependency. We've been through package renames. It used to be ugly, but
> it's still not pretty.

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...



> Fortunately setup is slowly creeping along a path to where rpm or dpkg
> support will be purely the file format, not the other stuff. It would be
> nice to end up supporting dpkg and rpm packages to allow folk their
> choice. 

The thing that worries me about this grand plan is database 
syncronization.  Suppose dpkg, rpm, and today's tarball-oriented setup 
are all supported.

rpm stores the installed package list in /var/lib/rpm/???

dpkg stores its database in <I dunno>...

setup uses /etc/setup/*.lst.gz and /etc/setup/installed.db, plus 
setup.ini for conflicts/dependency.

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)

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).

This is a *hard* problem.   How does 'alien' handle this?

--Chuck