Re: Dpkg in Ocaml

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

On Wed, Dec 04, 2002 at 10:14:54PM +0100, Sylvain LE GALL wrote:
> Hello all,
> 
> I don't post very often on this list. But a thread join one of my idea :
> rebuilding dpkg in ocaml.
> 
> I see some arguments against :
> - need to control memory 

Well, actually the memory consumption issue is only needed on boxes with
low memory. So you would only need to run the traditional dpkg on such
boxes and use the ocaml dpkg in cases where you have enough memory.

Also, i guess it could be possible to do things in a memory friendly way
in ocaml, controling the GC more strictly and such, but i have no
experience about those. I guess people running ocaml on iPAQs or on
embedded boxes could give more info here.

Anyway, this could be a second stage of optimization.

> And some arguments pro :
> - coq proof.

Well, i am not really a coq user, so i don't know if this is actually
feasible. I was told it is possible though. 

> In fact, from my point of view, ocaml is a very good language to do
> clean code. 
> 
> My idea is that dpkg is "necessary" for debian, if dpkg corrupts
> something you will have a lot of work to do to go back. 
> 
> I have seen a lot of bug, especially memory issue. 
> 
> So : 
> actual dpkg :
> - memory can often be corrupted
> - files ( status, status.old... ) are frequently corrupted...
> 
> maybe an ocaml dpkg :
> - proof of work ( with coq, i don't use it but i know little about
>   Hoare... )
> - memory consumption, but no memory bug
> - tree structure easily programmable
> - ...
> 
> Is anyone intersted in such a projet ? Do you know some people
> interested in this ?

I would be, but have not much time (well no time at all right now) so i
could not do much, but would be open for discution on this subject.

That said, what you propose would be hijacking the dpkg package, which
may (or may not) cause some political problems, and would need high
involvement since we have to stay near the policy and interface with apt
and all that. Also i don't know how the current dpkg developpers would
react to that.

That said, there has been a histrical example of something such, i think
it was 2/3 years ago, dpkg was rewritten, and i think a guy (don't
remember who) did rewrite dpkg in C++ all by himself. I don't really
remember if his code was taken over and became the actual dpkg or not,
actually, i think there were two concurrent (as in opposing) rewrites,
and only one was choosed.

I think your best approach would be to do this as a toy project, choose
a smallish subset of the dpkg related policy, do the coq/ocaml things so
that it conforms to the subset you choose, and then use it. I suppose at
that point you could even do some publications on that, either in the
JFLA and/or give a speach at one of the debian conferences, so that
people become aware of the advantages of this approach.

Then you can begin adding more features (hopefully it would be easily
extensible) and later one maybe replace the official dpkg, or at least
arrive at a state where it is actually usable.

Now, another problem is that a coq/ocaml solution is something very very
remote from what debian developpers are used to, and the step to entry
for people to work on it and do modification and bug fixes (or more
probably new features, since hopefully there would be no bugs) would be
quite high.

That said if it ever happens, it would be a wonderfull vitrine for
coq/ocaml and the functional languages in general.

Friendly,

Sven Luther