All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Westerhof <mike@mwester.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Why PREFERRED_VERSION setting of <distro>.conf overrules local.conf setting ?
Date: Tue, 10 Aug 2010 22:59:08 -0500	[thread overview]
Message-ID: <4C62200C.8070702@mwester.net> (raw)
In-Reply-To: <AANLkTin83G-uHv8oC1P0eQSxwddzAx406wjYV5jSqoZG@mail.gmail.com>

Frans Meulenbroeks wrote:
> 2010/8/10 Graham Gower <graham.gower@gmail.com>:
>> On 10 August 2010 04:31, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
>>> 2010/8/9 Chris Larson <clarson@kergoth.com>:
>>>> On Mon, Aug 9, 2010 at 6:26 AM, Hauser, Wolfgang (external) <
>>>> Wolfgang.Hauser.external@eads.com> wrote:
> 
>>>> PREFERRED_VERSION_<package>_local = "xxx" is how you use the override.
>>> The real solution woud be to either temporary store the
>>> PREFERRED_VERSION and apply it later on.
>>> Alternately we could parse local.conf twice, the first time ignoring
>>> the PREFERRED lines, and the 2nd time only looking at these.
>>> Yet another solution could be to split local.conf into two pieces, one
>>> with settings like MACHINE and DISTRO, the other one with the
>>> overrides.
>> Wouldn't it be far simpler to fix the distro conf file(s)? E.g. apply
>> something like this:
>> s/^PREFERRED_VERSION_\([a-z]*\) =/PREFERRED_VERSION_\1 ?=/
> 
> Yeah.
> Didn't really think about that one, but if distro's want to change and
> adhere to it, that would be the simplest solution
> Machines that pin something should probably also use weak binding.
> Conceptually it is probably marginally less desirable than a solution
> where local.conf has *always* control.
> 
> What do the distro's think about this?

I think it is the decision of EACH DISTRO to make, and not something to
be dictated by OE in general.

Mind you, I appreciate the general recommendation -- it's a sound idea
to make it so that a knowledgeable developer's local.conf overrides most
distro preferred version settings.  I use the technique frequently.

But on the other hand, I appreciate the ability to lock down some
preferred versions where I feel that it simply doesn't make sense to let
local.conf override.  For example, there's usually a LOT more to
changing the kernel version for SlugOS than just setting
PREFERRED_VERSION.  By the time a developer has figured out OE well
enough so they can find the distro conf files and understand how they
work, then I expect they also understand what extra stuff they need to
do for the kernel as well.  (Not to mention that I could - and should -
add some comments in the distro conf file to explain how that all works,
which is something I can't do in a generic local.conf file quite so well.)

It's a trivial point; if the community wants to begin to dictate such
little nuances to distros, it's not important enough to me to argue.
But you asked what the distros think, so I answered. :)

-Mike (mwester)



  reply	other threads:[~2010-08-11  4:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-09 13:26 Why PREFERRED_VERSION setting of <distro>.conf overrules local.conf setting ? Hauser, Wolfgang (external)
2010-08-09 14:22 ` Chris Larson
2010-08-09 19:01   ` Frans Meulenbroeks
2010-08-09 23:15     ` Graham Gower
2010-08-10  7:00       ` Frans Meulenbroeks
2010-08-11  3:59         ` Mike Westerhof [this message]
2010-08-10 20:50       ` Koen Kooi
2010-08-10 20:56         ` Chris Larson
2010-08-10 23:44           ` Graham Gower
2010-08-11  1:42             ` Denys Dmytriyenko
2010-08-11  2:43               ` Graham Gower
2010-08-11  3:10                 ` Denys Dmytriyenko
2010-08-11  5:16           ` Khem Raj
2010-08-11  6:08             ` Frans Meulenbroeks
2010-08-11  6:20               ` Martin Jansa
2010-08-11  7:53                 ` Hauser, Wolfgang (external)
2010-08-11  8:28                   ` Khem Raj
2010-08-11  9:50                     ` Why PREFERRED_VERSION setting of <distro>.conf overruleslocal.conf " Hauser, Wolfgang (external)

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=4C62200C.8070702@mwester.net \
    --to=mike@mwester.net \
    --cc=openembedded-devel@lists.openembedded.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.