All of lore.kernel.org
 help / color / mirror / Atom feed
From: Graham Gower <graham.gower@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Why PREFERRED_VERSION setting of <distro>.conf overrules local.conf setting ?
Date: Wed, 11 Aug 2010 12:13:08 +0930	[thread overview]
Message-ID: <AANLkTik64PqPOV4cjfzy4sOzgmr5Q4HDWsnBf=pZcdsQ@mail.gmail.com> (raw)
In-Reply-To: <20100811014245.GF7189@denix.org>

On 11 August 2010 11:12, Denys Dmytriyenko <denis@denix.org> wrote:
> On Wed, Aug 11, 2010 at 09:14:41AM +0930, Graham Gower wrote:
>> On 11 August 2010 06:26, Chris Larson <clarson@kergoth.com> wrote:
>> > On Tue, Aug 10, 2010 at 1:50 PM, Koen Kooi <k.kooi@student.utwente.nl>wrote:
>> >> What's the point of setting a preferred version at all if you make it a
>> >> weak assignment?
>> >> The distro nearly always knows better and if you want to use a different
>> >> version, sending a patch to change that version for review isn't exactly
>> >> rocket science.
>> >
>> >
>> > How about having decent usability?  The user asking for something and not
>> > getting it is completely unintuitive.  If the user doesn't know what they
>> > want, they won't request a specific version.  If they do request it, they
>> > should get it, anything else is an OE usability issue.
>>
>> Precisely. The user shouldn't have to understand the details of
>> parsing order, weak assignments, etc. in order to write a local.conf
>> which works for them.
>
> Yeah, and then distro maintainers are blamed for the breakage when users unpin
> and change specific dependency for a package.
>
> It's not just the parsing order problem. It's not clear for users that if they
> change anything in local.conf, it can break. I.e. you break it - you fix it.


Ok, I'm not so passionate about this change... But I'd like to
highlight why this is not particularly intuitive.
My experience has been that only certain image targets will build
without overrides in a local.conf.

E.g.
In order to get gpe-image to build, i needed to set
PREFERRED_VERSION_gpsd = "2.39", because prismstumbler doesn't work
with the API of newer gpsd versions and prismstumbler is included in
the gpe-image.

Since no gpsd version was pinned in the distro i was using, this
override worked.

But then i determined that udev 151 didn't like my old kernel, so I
set  PREFERRED_VERSION_udev = "141". Only this doesn't work because
the (angstrom) distro pins it and the 151 version is silently picked
up. I now understand why, but I didn't at the time.

So PREFERRED_VERSION_foo="123" might work, or it might not. And the
same goes for PREFERRED_PROVIDER_foo, which is actually less
consistent because some use a weak assignment in the conf files and
others don't.

Oh, and where is the ?= operator documented? I would have expected to
find it here: http://bitbake.berlios.de/manual/ch02.html

-Graham



  reply	other threads:[~2010-08-11  2:43 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
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 [this message]
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='AANLkTik64PqPOV4cjfzy4sOzgmr5Q4HDWsnBf=pZcdsQ@mail.gmail.com' \
    --to=graham.gower@gmail.com \
    --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.