All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package: udev is now provided by systemd or eudev.
Date: Wed, 18 Sep 2013 17:56:55 +0200	[thread overview]
Message-ID: <20130918175655.3f3a8466@skate> (raw)
In-Reply-To: <52394EEA.4000603@mind.be>

Dear Arnout Vandecappelle,

On Wed, 18 Sep 2013 08:57:46 +0200, Arnout Vandecappelle wrote:

> > No, I disagree with this. There are some other packages (currently
> > udisks and network-manager) that explicitly need the udev extras. So I
> > believe it's useful for these packages to be able to 'select
> > BR2_PACKAGE_UDEV_ALL_EXTRAS'. Of course, they could 'select
> > BR2_PACKAGE_LIBGLIB2' and depend on udev, but this means that they have
> > internal knowledge of the fact that udev needs libglib2 to enable 'all
> > extras', an internal knowledge that could very well be broken if
> > tomorrow udev needs another dependency to build its 'all extras' things.
> >
> > So, the BR2_PACKAGE_(E)UDEV_ALL_EXTRAS option should remain in place, I
> > believe.
> 
>   I didn't write the network-manager and udisks integration, but I think 
> that they _actually_ need gudev, not some vague "all extras". And for 
> gudev it's pretty darn obvious that there is a relation with libglib2. In 
> fact, both of them should probably select libglib2 directly, because they 
> are based on gobject classes.

Right, that's one way of seeing things, indeed. It sounds a bit
convoluted to me, though. When a package A needs a specific feature
from package B (such as gudev), I believe it makes sense for package B
to provide a sub-option that package A can select, rather than package
A having intimate knowledge of the dependencies needed by package B to
enable whatever feature package A needs to have from package B.

No?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-09-18 15:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-06 14:01 [Buildroot] [PATCH 1/1] package: udev is now provided by systemd or eudev eric.le.bihan.dev at free.fr
2013-09-06 14:08 ` Eric Le Bihan
2013-09-10 20:24 ` Arnout Vandecappelle
2013-09-17 10:40   ` Eric Le Bihan
2013-09-18  4:45     ` Thomas Petazzoni
2013-09-18  6:52     ` Arnout Vandecappelle
2013-09-17 18:37   ` Thomas Petazzoni
2013-09-18  6:57     ` Arnout Vandecappelle
2013-09-18 15:56       ` Thomas Petazzoni [this message]
2013-09-18 16:04         ` Arnout Vandecappelle
2013-09-18 16:40           ` Thomas Petazzoni
2013-09-18 21:46             ` Arnout Vandecappelle
2013-09-17  5:17 ` Thomas Petazzoni
2013-09-17 12:53   ` Eric Le Bihan
2013-09-17 18:45     ` Thomas Petazzoni
2013-09-18  7:00       ` Arnout Vandecappelle
2013-09-18 15:58         ` Thomas Petazzoni
2013-09-18 16:06           ` Arnout Vandecappelle
2013-09-18 16:41             ` Thomas Petazzoni
2013-09-18 17:34               ` Sagaert Johan
2013-09-18 17:39                 ` Thomas Petazzoni
2013-09-18 18:13                   ` Sagaert Johan
2013-09-18 18:05                 ` [Buildroot] [PATCH 1/1] package: udev is now provided bysystemd " Sagaert Johan
2013-09-18 18:16                   ` Thomas Petazzoni

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=20130918175655.3f3a8466@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=buildroot@busybox.net \
    /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.