All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Blundell <philb@gnu.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE
Date: Wed, 23 Nov 2011 16:48:59 +0000	[thread overview]
Message-ID: <1322066940.26081.27.camel@phil-desktop> (raw)
In-Reply-To: <3298934.bvzy1dahMQ@helios>

On Wed, 2011-11-23 at 16:33 +0000, Paul Eggleton wrote:
> On Wednesday 23 November 2011 16:59:56 Koen Kooi wrote:
> > We also agreed that the current behaviour should be retained, so needing to
> > add pulse to distro features would go against that. Having said that, I
> > personally would dislike having negative ('nopulseaudio') entries to
> > address that. Feedback needed :)
> 
> I don't see how we can achieve this without making a huge mess. I'm happy to 
> be proven wrong, but I would really like us to figure this stuff out soon so we 
> can get the actual problem here fixed.

Agreed.  This problem (or variants of it) comes up fairly frequently: we
had a similar amount of grief when ipv4 and ipv6 became DISTRO_FEATURES
and everybody who wasn't paying attention found that they suddenly had
no networking.  But I think it is basically insoluble in the general
case without any extra stateful mechanics: we need to either:

a) decide that what we have today, or at some other arbitrary point, is
the "base configuration" and any departure from that (including
removals) will now be a DISTRO_FEATURE.  This means accepting things
like "nopulseaudio" which are, admittedly, ugly; or

b) introduce some sort of concept of "feature epochs", where the DISTRO
gets to declare what epoch it is expecting and the compatibility code
then backfills DISTRO_FEATURES to take account of things that were
enabled by default in past epochs but have since been removed.  This
introduces a certain extra maintenance burden but it means that DISTROs
will no longer get unpleasant surprises; or

c) just live with the status quo and accept that things will break when
features are turned off.

My personal preference would be for (b) but I could live with (a) just
as well.

p.





  reply	other threads:[~2011-11-23 16:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 15:32 [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE Paul Eggleton
2011-11-23 15:32 ` [PATCH 1/3] default-distrovars: add pulseaudio to DISTRO_FEATURES Paul Eggleton
2011-11-23 15:32 ` [PATCH 2/3] qt4: make pulseaudio support conditional upon DISTRO_FEATURES Paul Eggleton
2011-11-23 15:32 ` [PATCH 3/3] gst-plugins-good: " Paul Eggleton
2011-11-23 15:59 ` [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE Koen Kooi
2011-11-23 16:33   ` Paul Eggleton
2011-11-23 16:48     ` Phil Blundell [this message]
2011-11-23 17:09       ` Richard Purdie
2011-11-23 17:45         ` Paul Eggleton
2011-11-23 17:49           ` Paul Eggleton
2011-11-23 17:53           ` Phil Blundell
2011-11-23 18:22             ` Otavio Salvador
2011-12-29 12:55         ` Paul Eggleton
2012-01-16 17:58           ` Paul Eggleton
2012-01-16 18:12             ` Phil Blundell
2012-01-17 23:13             ` Process for New DISTRO_FEATURES (was: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE) Richard Purdie
2012-01-17 20:02           ` [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE Tom Rini
2012-01-27 10:43             ` Samuel Stirtzel
2012-01-27 10:54               ` Paul Eggleton
2012-01-27 11:34                 ` Samuel Stirtzel
2012-01-27 12:13                   ` Paul Eggleton
2012-01-28 20:05                 ` Khem Raj

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=1322066940.26081.27.camel@phil-desktop \
    --to=philb@gnu.org \
    --cc=openembedded-core@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.