Re: Time to rewrite dpkg
Joey Hess <joey@kitenet.net> writes:
> Goswin Brederlow wrote:
> > I think its a bad idea to say "You want to access to dpkg, programm in
> > XXX". All interaction should be via a call to dpkg itself. Also
> > modules should be programs by itself and not linked.
> >
> > dpkg would then call "dpkg-download-ftp" to download a package via
> > ftp, or it could call "dpkg-download-apt" to use apt and so on.
> >
> > That way all modules can be written in any language. They only must
> > share a common interface via commandline options, which all programs
> > can provide easily.
>
> Library interfaces can be much richer and let you do a lot of things that
> are a royal pain with a command line interface. They also have less overhead.
>
> C libraries are quite usable from other languages.
For modules that download stuff and many other the interface is real
easy and the most time is spend on waiting anyway. There is no need to
make a library for those stuff. The problem with libraries is that you
can't just create or exchange one easily. You have to know a lot about
the structure and code behind it. Also you have to recompile programs
to use new libraries.
Take binary diffs of deb packages for example. Via a command interface
to download packages, its a matter of seconds to write a script that
downloads the binary diff of a package and patches the already
existing package to the new version and return that for
installation. With a library you have to write C (or other language)
code, compile that, link that and recompile dpkg to use it. That takes
far more time.
Of cause for the database that controls whats installed and what state
packages are in and so, speed is vital. Esspecially one doesn't want
to parse the database again and again. Maybe for that a database
interface that starts automatically when first used and keeps runnig
for some time in the background would be best.
May the Source be with you.
Goswin
Reply to: