Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Barker <paul@paulbarker.me.uk>
Cc: OE Core <openembedded-core@lists.openembedded.org>
Subject: Re: opkg, opkg-config-base and opkg-collateral
Date: Wed, 26 Nov 2014 16:17:08 +0100	[thread overview]
Message-ID: <20141126151708.GA2460@jama> (raw)
In-Reply-To: <CANyK_8dxvZU8wnqFQGWL=DgFxOdgdq-yaaOkOJrR60w7_M6pfg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]

On Wed, Nov 26, 2014 at 01:50:38PM +0000, Paul Barker wrote:
> On 26 November 2014 at 12:14, Richard Purdie
> <richard.purdie@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

Please also check
http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/meta/distro-feed-configs.bb

+ filtering the architectures

https://github.com/shr-distribution/meta-smartphone/blob/master/meta-shr-distro/recipes-core/meta/distro-feed-configs.bbappend

+ stricter filter for individual MACHINEs based on selected DEFAULTTUNE

https://github.com/shr-distribution/meta-smartphone/blob/master/meta-shr-distro/conf/distro/include/defaulttunes.inc

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2014-11-26 15:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25 20:27 opkg, opkg-config-base and opkg-collateral Paul Barker
2014-11-26 12:14 ` Richard Purdie
2014-11-26 13:43   ` Mike Looijmans
2014-11-26 13:53     ` Paul Barker
2014-11-26 13:50   ` Paul Barker
2014-11-26 15:17     ` Martin Jansa [this message]
2014-12-13 12:54       ` Paul Barker
2014-12-13 19:34         ` Michael Gloff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141126151708.GA2460@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@paulbarker.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox