[PATCH v2 6/7] coreutils: Import from packages feed

[Thibaut]

> Le 9 janv. 2023 à 04:09, Brian Norris <computersforpeace at gmail.com> a écrit :
> 
> On Sun, Jan 8, 2023 at 1:37 PM Thibaut <hacks at slashdirt.org> wrote:
>>> Le 8 janv. 2023 à 21:53, Christian Marangi <ansuelsmth at gmail.com> a écrit :
>>> 
>>> On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote:
[…]
>>>>      include $(INCLUDE_DIR)/target.mk
>>>>     +
>>>>     +DEPENDS:= \
>>>>     +       + at BUSYBOX_DEFAULT_BASE64
>>>>     +
> 
> Thanks! That does indeed work for me. And I might just throw it into
> target/linux/ipq806x/chromium/target.mk instead, since the generic
> target won't be using base64.

I believe that won’t work, see below.

>>> Is this already used for other target? Wonder if this special thing
>>> would cause some problem for packages of this target? Like discrepancy
>>> with stage2 and final image?
> 
> stage2 as in sysupgrade? I don't immediately see how that would be a
> problem, but maybe I'm not understanding well enough.

Packages are built on architecture-basis by a separate set of builders (« phase2 »). For ipq806x, that’s arm_cortex-a15_neon-vfpv4.
While adjusting this tunable will have an effect on phase1 builds (images) and local builds from source, my understanding is it won’t affect the global architecture setting, meaning that the busybox package that’s built by the « phase2 » builders will not have this knob enabled.
Thus, anyone building from imagebuilder or updating busybox from the package repo will get a version without base64, and this will break.

>> AFAICT this isn’t used anywhere so far (at least according to a quick git grep).
> 
> Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in
> the current tree or in the git history.
> 
> And I can't even find anyone doing a bare 'DEPENDS:=' in their
> Makefile under target/linux/ at all. All usages are as part of
> packages (modules), not device/target specifications.

Most likely because of the above, which is why I’m not convinced it’s such a good idea to « set this precedent ».

>>> Anyway this looks to be the best solution for the problem.
>> 
>> I wonder if it’s such a good idea to have discrepancies in busybox features between targets?
> 
> I don't think I know enough about OpenWrt development yet to have a
> good answer on this, so I'll let you all try to answer this.

Regardless of the above, I think these types of features (core utils that are typically used in scripts) should be enabled/disabled tree wide: otherwise, a user building a script which uses any of these features will have the « surprise » that it doesn’t work consistently on all devices, and that IMHO is bad.

My 2c.

T