From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 1/2] busybox: avoid conflict with other packages
Date: Fri, 29 Dec 2017 21:18:06 +0100 [thread overview]
Message-ID: <20171229201806.GR3176@scaer> (raw)
In-Reply-To: <1514577289.26695.127.camel@impinj.com>
Trent, All,
On 2017-12-29 19:54 +0000, Trent Piepho spake thusly:
> On Fri, 2017-12-29 at 10:38 +0100, Yann E. MORIN wrote:
> >
> > I prefer the second option, because it concentrates the dependency chain
> > in a single package, and it becomes very easy to write:
> >
> > BUSYBOX_DEPENDENCIES = \
> > $(if $(BR2_PACKAGE_COREUTILS),coreutils) \
> > $(if $(BR2_PACKAGE_UTIL_LINUX),util-linux) \
> > [...]
>
> Could one have a package variable specifically for install
> dependencies, like:
I think you already suggested so on IRC a while back, right?
In fact, I do see the reasoning behind this, but I don;t think there is
a big advantage for us, in Buildroot.
In any case, we will want those dependencies to be installed befiore the
package itself is installed, so we don't care that they were installed
before the package is built.
One case where that might be interesting is to test-build a package
without building its install dependencies. But except for busybox, it
would only be usefull for very few packages, because in the vast
majority of cases, dependencies are build dependencies.
So I don't think it warrants the extra complexity in the infra...
> BUSYBOX_INSTALL_DEPENDENCIES = coreutils util-linux ...
If we were to add support for install dependencies, we would want to
treat them as the other dependencies and not do magical thigns like list
all of them and defer to the infra to sort out those that are enabeld.
In fact, that would go contrary to what we currently do for the existing
dependencies: if a package lists a dependency but it is not enabled, we
explicitly fail.
So we'd want to have:
BUSYBOX_INSTALL_DEPENDENCIES = \
$(if $(BR2_PACKAGE_COREUTILS),coreutils) \
[...]
Adn then...
> It seems like the base pkg infra could automagically turn that into
> conditional dependencies, e.g. "coreutils" -> "(if
> $(BR2_PACKAGE_COREUTILS), coreutils)". And then append those to the
> package dependencies.
>
> So less boilerplate to write in the package file.
... that would not diminish the "boilerplate" in the package's .mk file.
But know that this is specifically just for busybox (and maybe a very
few other packages), so that really does not warrant extra support in
the infra, IMHO...
Regards,
Yann E. MORIN.
> But it would also allow the possibility to take advantage of knowing
> that coreutils is an install dependency rather than a build dependency.
> So it's allowed to build busybox and coreutils at the same time in
> parallel. The requirement is only that coreutils be installed to the
> target dir first. Usually installing is much faster than building, so
> one gets more parallelism this way.
>
> Of course this optimization is not necessary, but separating out the
> install deps now allows the possibility in the future, while being less
> boilerplate and more clear documentation now.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2017-12-29 20:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 13:01 [Buildroot] [RFC 0/2] Handle conflicting files with Busybox Thomas Petazzoni
2017-12-13 13:01 ` [Buildroot] [RFC 1/2] busybox: avoid conflict with other packages Thomas Petazzoni
2017-12-13 14:43 ` Baruch Siach
2017-12-14 5:18 ` Thomas Petazzoni
2017-12-14 6:58 ` Baruch Siach
2017-12-14 7:17 ` Thomas Petazzoni
2017-12-28 16:23 ` Yann E. MORIN
2017-12-28 22:56 ` Yann E. MORIN
2017-12-29 5:59 ` Baruch Siach
2017-12-29 9:38 ` Yann E. MORIN
2017-12-29 9:42 ` Thomas Petazzoni
2017-12-29 9:52 ` Yann E. MORIN
2017-12-29 9:55 ` Thomas Petazzoni
2018-01-04 15:20 ` Yann E. MORIN
2018-01-04 15:29 ` Thomas Petazzoni
2018-01-04 15:39 ` Yann E. MORIN
2017-12-29 19:54 ` Trent Piepho
2017-12-29 20:18 ` Yann E. MORIN [this message]
2017-12-29 21:50 ` Trent Piepho
2017-12-13 13:01 ` [Buildroot] [RFC 2/2] packages: drop no longer needed busybox dependencies Thomas Petazzoni
2017-12-28 17:00 ` [Buildroot] [RFC 0/2] Handle conflicting files with Busybox Yann E. MORIN
2017-12-28 17:04 ` Thomas Petazzoni
2017-12-28 17:20 ` Yann E. MORIN
[not found] ` <CANQCQpZ-qO6v+K4kdqmAEdk2+Dk1Yca1fBqyNwfAjau=50cY7A@mail.gmail.com>
[not found] ` <CANQCQpYmpCKopmh_5yYV74kOyezJSCLxp6T1mUiqnocHLZV92A@mail.gmail.com>
2017-12-28 17:36 ` Matthew Weber
2017-12-28 18:01 ` Baruch Siach
2017-12-28 19:11 ` Yann E. MORIN
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=20171229201806.GR3176@scaer \
--to=yann.morin.1998@free.fr \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox