[oe] [oe-commits] org.oe.dev ipkg-utils*: Re-add support for openwrt-style .ipk's.

[Paul Sokolovsky]

Hello,

On Wed, 20 Feb 2008 08:59:37 +0100
Marcin Juszkiewicz <openembedded at haerwu.biz> wrote:

> Dnia Tuesday, 19 of February 2008, pfalcon commit napisał:
> > ipkg-utils*: Re-add support for openwrt-style .ipk's.
> > * There're two .ipk formats: one with ar top-level wrapping
> > (essentially, .deb format, native OE format) and with tar.gz
> > top-level wrap, used by OpenWRT and some tiny distros. When I did
> > performance optimization work on ipkg-make-index, I just blocked
> > support of tar.gz-style ipk's, as it was unclear if those are used
> > in OE at all. Now support is readded, with the old code to handle
> > them (i.e. not as optimal as ar-style ones).
> > * This makes DISTRO=openwrt-sdk usable for producing compatible
> > packages and deploy-feed for them. But there're still some issues to
> > resolve before OE can be said to provide seamless support for
> > building packages for OpenWRT.
> 
> OpenWRT use tar.gz type but on device it handle both types. I am
> using OpenWRT 'whiterussian' rc5 (last jffs2 one) and 'ar type'
> packages generated by OE were working for me (ipkg 0.99.149 on
> device).
> 
> But I do not know how situation looks in Kamikaze (OpenWRT devel
> tree). 

OpenWRT Kamikaze is for quite some time the latest
production branch of OpenWRT, with at least 2 releases made for that
(they use ubuntu versioning now too, so latest 7.09). They did a lot
of /etc cleanup there, and we even can learn from them ;-). For example,
I find it very convenient to use /etc/init.d/<service> enable/disable
to add/remove service to autoload on boot ;-).

Back to topic, .deb-style .ipk's didn't work for me with it.

> From what I see they indeed use old shell version of ipkg in
> SDK.

root at OpenWrt:~# which ipkg
/usr/bin/ipkg
root at OpenWrt:~# ipkg -version
ipkg: version 0.99.162

So, they either hacked it, or ..., or ... In either case, ipk's they
ship are tar.gz-wrapped, and openwrt-sdk is intended to follow all
official conventions, to be as much drop-in replacement for their
buildroot as possible.


I'd appreciate comments on ldconfig issue.




-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com