ipkg vs. opkg

[Richard Purdie]

On Wed, 2008-07-30 at 23:22 -0300, Werner Almesberger wrote:
> However, I wonder if there are any other differences beyond the
> mere format. E.g., could systems that use dpkg, ipkg, or opkg
> actually install .deb, .ipk, or .opk packages (provided that
> they're built for the respective architecture), or are there
> other differences beyond just the package format that would cause
> this to fail or to cause other problems (such as putting invalid
> metadata into the local package database) ?

The reason for creating opkg was that ipkg was an effectively a dead end
project (not dead, just a dead end). OE has had ipkg patches sitting
around for years and there was no active ipkg maintainer and no active
ipkg development. I was perfectly happy to see ipkg being renamed and
development continued under a new banner. As has been mentioned, IPKG
was taken out as a trademark and the rename also neatly avoids any
problems with that and handhelds.org which has some history of being
problematic in various ways. I was lead to understand that while
OpenMoko needed this and was sponsoring it, it was a community project
and other ipkg/opkg users were welcome to participate.

So on the technical side, what are the different file formats?

.ipk

Back in the mists of time when ipkg was young the files were basically
tgz files. As it grew they changed the format to match the .deb
structure - ar files with a data.tar.gz and control.tar.gz in them. This
later file format has been around for many years. There are still some
using the older format, notably openwrt but anything OE derived such as
the nslu2, poky etc. uses the newer format and always has.

.opk

These are simply .ipk files renamed. There is no technical differences
whatsoever, the rename is being done purely for appearance.

.deb

These are not the same as .ipk files. The structure is the same but the
way the control fields work is subtly different. The biggest difference
is the way ipkg/opkg handle architecture. dpkg and the .deb files just
accept "arm", ipkg/opkg allow a spectrum of architectures e.g. "arm,
armv4, armv4t, om-gta02" which allows the idea of machine specific
packages.

opkg can handle installing .deb files as long as the architecture
matches something it accepts. It will also accept .ipk and .opk,
obviously.

ipkg will accept .deb and .ipk but "mv x.opk x.ipk" would let it
install .opk.

dpkg will only take .deb. To work around the architecture issue, you
create a feed for each of the traditional ipkg architectures and then
allow a given machine to pull from a carefully selected set of feeds.

> If .opk is identical to .ipk for all practical purposes, then I
> don't think this is a good change and it may not be too late to
> revert it.

They're the same.

> I also don't know what is actually the difference between opkg
> and ipkg. I just thought it's somehow "better" without affecting
> the core functionality. Could anyone please explain ? I think I
> may not be the only one confused :-)

opkg has been heavily updated compared to ipkg now, tons of memory leaks
have been fixed, signed feeds are now supported, various bugfixes and
enhancements in OE were applied so opkg is "better" than ipkg now, not
least for being actively maintained and being maintainable.

I hope that makes things clearer :)

Personally, I have no issue with opkg being around, I fully support that
and its great to see. I'm not so happy about the .ipk -> .opk name
change.

Cheers,

Richard