Re: RFC interaction with external dependency solver: Debian-CUDF
Am Dienstag, den 08.12.2009, 20:33 +0200 schrieb Eugene V. Lyubimkin:
>
> > * Julian was waiting for me on a format proposal: here we go! :-)
> >
> > - Solution description: the above returns solution in "here is the
> > new package status" style. Julian was instead proposing something like
> > "here is a diff from the previous package status". Mine looks cleaner
> > to me, but obviously more bloated.
> I disagree. In case we upgrade something like 2/3 of the system and more, the
> diff approach is even bigger, even without a fact it's more complicated
> without any practical gain IMO.
We have to tell dpkg remove this package/install this package, and not
"bring us to the following state". Thus, I think that receiving those
actions from the solver makes things easier, and not more complicated.
And if one uses a database as the cache in the package manager,
generating the diff in the PM is certainly less efficient than
generating it in the solver which should have the information in-memory,
whereas the PM has to do a database lookup first, selecting all
installed packages and passing this forward.
I have not decided about cache storage yet, candidates are:
1. (bin) SQLite3 database backend
2. (bin) custom binary format (or a binary implementation of CUDF)
3. (txt) storage in CUDF-derived format
4. (txt) storage in Debian format
5. (txt) storage in JSON (JavaScript Object Notation)
Obviously, option 3 seems to be the best for external solvers, as we
could just pass them the cache directly. Option 5 also seems
interesting, given that there already is libpersistence on
git.freesmartphone.org[1]. But it currently takes about 2 seconds to
load a JSON cache for Debian sid; which is not very efficient. And all
data would be kept in-memory and dumped to the disk on exit. The SQLite
version is best suited for the internal solvers, as they can use the
power of the database to find the packages they are looking for (e.g.
SELECT * from packages where name='%s' and architecture='%s').
But as I already told some people, I believe that interface comes first
and afterwards we care about how to store the data.
[1] http://git.freesmartphone.org/?p=libpersistence.git;a=summary
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: