Re: apt on handheld issues
On Sun, 2003-03-02 at 18:18, Klaus Weidner wrote:
> > This is essentially what the ipkg packaging system does, is it not? And
> > some handheld distributions are starting to outgrow it. It becomes
> > difficult to support smooth upgrades and complex packages when you do not
> > have access to a complete dependency graph. And, as you say, we would lose
> > the option of adapting an existing apt frontend for our use, rather than
> > writing a new one from scratch.
>
> Not really - the ipkg system is a complete reimplementation of the
> packaging system that doesn't use dpkg, and the *.ipk files are not
> compatible directly with *.deb files.
We changed the .ipk format to be compatible with the .deb files some
time ago. ipkg continues to be a self-contained utility that performs
the functions of apt and dpkg. ipkg does actually have access to the
complete dependency graph. ipkg currently handles Depends, Provides,
and Replaces. We are working on a new version of ipkg that should
handle more complex upgrades by considering all the
remove/upgrade/install operations as a group instead of individually.
> I was thinking about keeping the dpkg back-end and work with *.deb files
> and the official archives, and just use a simpler script to build the
> dependency graph and do the upgrades. But I'm not very keen on doing
> that, since the complexity to do it *right* is very large.
I do not think it can be done as a shell script, but it could be done in
python.
> > This is a serious problem, though. Not only would it be a significant
> > amount of work to change apt to work without writable mmap, but it would end
> > up using more memory (which is already short on a handheld).
>
> The cache files are currently around 3-5 MB in size, I don't think it
> would be a problem to keep that amount of information in memory,
> especially because it could be freed before calling dpkg to do the
> installation.
>
> > One option that has been brought up is to move the problematic functionality
> > to a server side program. A lightweight, dumb client would run on the
> > handheld, and communicate with a smart client on a remote server.
> [...]
> > Then the lightweight client does not need to make difficult decisions about
> > installation ordering, conflict resolution, etc., and does not need to store
> > the entire package database locally. It basically only needs to be able to
> > talk to the APT download methods and be a frontend to dpkg.
>
We have many users on handhelds.org who do not have network access.
Therefore, a lightweight client would leave them with a crippled
system. The C implementation of ipkg shows that you can implement the
full functionality in a small utility. ipkg, stripped, is 88KB.
-Jamey
Reply to: