enhancing ipks

Goetz Bock writes:
> Hi all,
>
> while I love ipkg (thanks for all the work Carl)

You're welcome.

> I think is has some serious shortcommings:

Naturally! This is still pretty early code. :)

> - no support to install into e.g. /usr or a CF drive mounted at
> /ust/local

Absolutely. This is high on my TODO list. I'm still thinking about the
right way to handle this.

> - can not install packages that don't fit into the device twice
> (well, actually nothing that does not fit into the ramdisk)

I only realized this was a hard limit recently when James Conner
proposed a 185MB ipkg for intimate. The problem is really only due to
the two layers of tar files used in the current .ipk format.

> unfortunately my sollution for 1 & 2 would breake the current ipkg version:
>
> - change the ipkg format to be just one .tar.gz. This should contain
> the files as if they were put into /usr and additionally the controll
> files in tmp/$pkg_name/
> (all meta data must be moved to a seccond file, probably the Packages
> file already contains all the required information)

Rather than changing any of the .ipk format, we might just make it
possible to send the existing data.tar.gz and control.tar.gz files
separately. That should allow everything to be streamed and will avoid
duplicate files. This would really be a rather minor change to ipkg.

[snip]

> while this fixes 1 & 2 it has other problems:
>
> - you can only use one CF card at any given time

This is definitely a problem that must be avoided with whatever
solution we come up with.

> - while a wget -O - foo_pkg.ipk | tar -xzOf -
> could be used to fatch a package that just fills the remaining
> storage, this would simply whipe any file with the same name
> (I don't know how JFFS2 handles moving of files, but perhapes the
> Journaling saves us there: when installing to /usr, extract to
> /usr/ipgk_install (on the same filesystem as /usr) and move to
> /usr after all clashes are resolved)

Nod. The current ipkg does something like this now. It installs to a
temporary location, resolves conflicting file (currently limited to
configuration files -- other conflicts are simply overwritten), then
performs a mv of each file to its final location.

> - if we can add/remove software by adding/removing CF cards, we realy
> need a way to add the software to the menu

Definitely. I've been looking at Debian's menu system as well as the
.desktop files used by the Gnome/KDE groups.

[snip]

-Carl
Received on Thu May 17 2001 - 06:32:57 EDT