From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/7] linux-pam: introduce BR2_PACKAGE_LINUX_PAM_ARCH_SUPPORTS
Date: Fri, 7 Jul 2017 09:50:35 +0200 [thread overview]
Message-ID: <20170707095035.0e268fe2@windsurf.lan> (raw)
In-Reply-To: <20170707033626.ma6y3kcn7o6vadp6@tarshish>
Hello,
On Fri, 7 Jul 2017 06:36:26 +0300, Baruch Siach wrote:
> > diff --git a/package/linux-pam/Config.in b/package/linux-pam/Config.in
> > index 33e5154..0daffe4 100644
> > --- a/package/linux-pam/Config.in
> > +++ b/package/linux-pam/Config.in
> > @@ -1,9 +1,20 @@
> > -config BR2_PACKAGE_LINUX_PAM
> > - bool "linux-pam"
> > +# Use this option instead of duplicating the dependencies in each
> > +# dependent package.
> > +#
> > +# If you change these dependencies then update the comment below
> > +# and the # corresponding ones in other Config.in files.
> > +#
> > +config BR2_PACKAGE_LINUX_PAM_ARCH_SUPPORTS
> > + bool
> > + default y
> > depends on (BR2_ENABLE_LOCALE && BR2_USE_WCHAR)
> > depends on !BR2_STATIC_LIBS
> > depends on !BR2_TOOLCHAIN_USES_MUSL
> > depends on BR2_USE_MMU # fork()
>
> These are feature dependencies, not arch dependencies, so the config name is
> misleading. But regardless of that, we want to see this list in all dependent
> packages, IMO. This allows us to (more) easily see and grep for direct and
> indirect dependencies. It also makes dependencies comments easier to maintain
> as you noted.
Correct: the <foo>_ARCH_SUPPORTS hidden options should really only be
used for architecture dependencies. So in the list above, that would be
just BR2_USE_MMU. All the other dependencies are *not* architecture
dependencies, and we want to repeat them explicitly, because each
package anyway needs to have a Config.in comment that tells the user
about such toolchain dependencies.
Therefore, I'm afraid the patch series is not correct :/
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-07-07 7:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 2:22 [Buildroot] [PATCH 0/7] introduce BR2_PACKAGE_LINUX_PAM_ARCH_SUPPORTS Carlos Santos
2017-07-07 2:22 ` [Buildroot] [PATCH 1/7] linux-pam: " Carlos Santos
2017-07-07 3:36 ` Baruch Siach
2017-07-07 7:50 ` Thomas Petazzoni [this message]
2017-07-07 11:11 ` Carlos Santos
2017-07-07 11:52 ` Thomas Petazzoni
2017-07-07 2:22 ` [Buildroot] [PATCH 2/7] nodm: use BR2_PACKAGE_LINUX_PAM_ARCH_SUPPORTS Carlos Santos
2017-07-07 2:22 ` [Buildroot] [PATCH 3/7] openvmtools: " Carlos Santos
2017-07-07 2:22 ` [Buildroot] [PATCH 4/7] python-pam: " Carlos Santos
2017-07-07 2:22 ` [Buildroot] [PATCH 5/7] rsh-redone: " Carlos Santos
2017-07-07 2:22 ` [Buildroot] [PATCH 6/7] sudo: " Carlos Santos
2017-07-07 2:22 ` [Buildroot] [PATCH 7/7] util-linux: " Carlos Santos
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=20170707095035.0e268fe2@windsurf.lan \
--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.