[OE-core] opkg, opkg-config-base and opkg-collateral

[Paul Barker]

On 26 November 2014 at 12:14, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
>
> On Tue, 2014-11-25 at 20:27 +0000, Paul Barker wrote:
> > Hi all,
> >
> > Does anyone know why the configuration files for opkg are split into
> > opkg-config-base (containing just '/etc/opkg/arch.conf') and
> > opkg-collateral (containing just '/etc/opkg/opkg.conf')? It looks like
> > the split dates back to openembedded classic.
> >
> > If there isn't a good reason for this perhaps now would be a good time
> > to merge all this back into the 'opkg' recipe and package. I'm happy
> > to put the patch together, just checking if it sounds like a good idea
> > before I do the work.
>
> I think at least one of the above was intended to allow distro specific
> package feeds to be preconfigured as as such belonged as a standalone
> config file.

That would probably be opkg-collateral as it pulls in a 'src' file
which is empty in oe-core.

However there's also the poky-feed-config-opkg recipe which provides
feed configurations in /etc/opkg/base-feeds.conf. It also fills in
/etc/opkg/arch.conf which means it would not be installable alongside
opkg-config-base.

I suggest the config settings are merged back into the opkg recipe,
removing opkg-collateral completely. We can then improve
poky-feed-config-opkg and rename it to something like opkg-feed-config
so that it's clear it's usable by distros other than poky. This
improved recipe would just contain /etc/opkg/feeds.conf (the 'base-'
filename prefix is unnecessary).

In terms of improving the feed config for opkg, by default I suggest
we just setup feeds for 'all', ${ALL_MULTILIB_PACKAGE_ARCHS} and
${MACHINE_ARCH}. This should avoid creating feed entries for
architectures which the target system supports but for which we never
create packages (for example, qemux86 lists 'all', 'any', 'noarch',
'x85', 'i586' and 'qemux86' as supported architectures but we only
ever create packages for 'all', 'i586' and 'qemux86'). By using a
bbappend a layer should be able to add to these defaults. The URI for
each package feed would be prefixed with ${OPKG_FEED_PREFIX} which
must be set in the distro config or local.conf. If OPKG_FEED_PREFIX is
not set, the recipe would create an empty base-feeds.conf file.

It would be possible with a bit of scripting to set the hold flag on
the opkg-feed-config package when it is installed so that even if a
new version of the package is compiled, the feeds for a target board
will not be automatically upgraded with 'opkg upgrade'. We could then
create a dist-upgrade script which removes the hold flag, upgrades
opkg-feed-config, and re-sets the hold flag. So to provide a new
version of a distro which users could upgrade to but are not
automatically upgraded to, you'd build a new version of
opkg-feed-config (probably by changing OPKG_FEED_PREFIX) and run the
dist-upgrade script on the target.

I'll put together RFC patches to show what I mean, I think that's a
pretty good explanation for now though.

>
> The architecture file is also machine specific, we wouldn't want opkg
> itself rebuilding for every machine so that is probably why its
> separate.
>

I didn't spot this but it does make sense. Perhaps opkg-config-base
should be renamed to opkg-arch-config to avoid future confusion.

> Three different things on the other hand seems excessive. We probably
> could survive with some merhing with opkg and the remainder being
> machine specific.
>

I'd keep three, but refactor them as I've described above:
- opkg: Includes '/etc/opkg/opkg.conf'
- opkg-arch-config: Includes '/etc/opkg/arch.conf', machine specific
- opkg-feed-config: Includes '/etc/opkg/feeds.conf', distro and
possibly machine specific

> Cheers,
>
> Richard
>

Thanks,

-- 
Paul Barker

Email: paul at paulbarker.me.uk
http://www.paulbarker.me.uk