Handle conflicting files with Busybox

One of the requirement to implement per-package SDK is that a package should not overwrite files installed by another package. The busybox package creates such a situation with numerous other packages, because it provides applets that are also provided as full-featured programs in other packages.

In order to avoid having other packages overwrite the Busybox applet symbolic link with their own variant, this commit improves the logic in busybox.mk to disable the applets when the corresponding full-featured program will be installed by a different package.

Signed-off-by Thomas Petazzoni <[email protected]>

---
Note: the list is not complete, this is just a RFC version to find out if that's the direction we want to take.

---
 package/busybox/busybox.mk | 58 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

package/busybox/busybox.mk +58 -0

index 8b720b30b8..e51dbc4887 100644
@@ -250,6 +250,63 @@ endef
 BUSYBOX_DEPENDENCIES += linux-pam
 endif
 
+# Avoid collision with other packages
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_BC) += dc
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_BINUTILS) += ar strings
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_CPIO) += cpio
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_DCRON) += crond crontab
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_DEBIANUTILS) += run-parts which
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_DIFFUTILS) += cmp diff
+# test1 removes the [ applet
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_COREUTILS) += \
+	chmod tail printf uname touch echo od realpath sha512sum rmdir readlink \
+	sync mknod du true nlink ln ls fold who logname chown dirname chgrp \
+	basename uptime sha256sum uniq env rm expr wc pwd tee cat test chroot \
+	nohup head sha1sum df dd nl seq truncate id cp mkfifo tty whoami factor \
+	tr mkdir paste cksum sort stty shred md5sum hostid nproc install date \
+	mv sleep yes cut false unlink test1
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_FBSET) += fbset
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_KMOD_TOOLS) += lsmod rmmod modprobe insmod
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += blkid
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += dmesg
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += fdisk
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += flock
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += fstrim
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += hexdump
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += mkswap
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += readprofile
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += renice
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += setsid
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += swapoff
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_BINARIES) += swapon
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_EJECT) += eject
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_FALLOCATE) += fallocate
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_FDFORMAT) += fdformat
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_FSCK) += fsck
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_HWCLOCK) += hwclock
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_IPCRM) += ipcrm
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_IPCS) += ipcs
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_KILL) += kill
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_LAST) += last
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_LOGGER) += logger
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_LOGIN) += login
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_LOSETUP) += losetup
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_MESG) += mesg
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_MORE) += more
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_MOUNT) += mount umount
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_MOUNTPOINT) += mountpoint
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_PIVOT_ROOT) += pivot_root
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_SCHEDUTILS) += chrt
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_SU) += su
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_SULOGIN) += sulogin
+BUSYBOX_DROP_APPLET_$(BR2_PACKAGE_UTIL_LINUX_SWITCH_ROOT) += switch_root
+
+define BUSYBOX_DROP_CONFLICTING_APPLETS
+	$(foreach applet,$(BUSYBOX_DROP_APPLET_y),\
+		$(call KCONFIG_DISABLE_OPT,CONFIG_$(call UPPERCASE,$(applet)),$(BUSYBOX_BUILD_CONFIG))
+	)
+endef
+
 # Telnet support
 define BUSYBOX_INSTALL_TELNET_SCRIPT
 	if grep -q CONFIG_FEATURE_TELNETD_STANDALONE=y $(@D)/.config; then \

@@ -276,6 +333,7 @@ define BUSYBOX_KCONFIG_FIXUP_CMDS
 	$(BUSYBOX_SET_SELINUX)
 	$(BUSYBOX_SET_INDIVIDUAL_BINARIES)
 	$(BUSYBOX_MUSL_TWEAKS)
+	$(BUSYBOX_DROP_CONFLICTING_APPLETS)
 endef
 
 define BUSYBOX_CONFIGURE_CMDS

This means that a custom Busybox .config will automagically be transformed to something quite different. This is a significant change in behaviour.

Can't we just move the symlink removal logic into busybox.mk instead? That would leave the busybox binary alone, and keep the magic .config transformations to minimum.

Quoted 2 lines · Baruch Siach

This means that a custom Busybox .config will automagically be transformed to something quite different. This is a significant change in behaviour.

We already tweak the Busybox .config file quite significantly in busybox.mk, so it's not really new. But I agree that the scale of the change is very different.

Quoted 3 lines

Can't we just move the symlink removal logic into busybox.mk instead? That would leave the busybox binary alone, and keep the magic .config transformations to minimum.

If I understand your proposal, we would not tweak the Busybox .config file, but instead add a post install target hook that would remove the symbolic links installed by Busybox "make install" when such symbolic links are going to conflict with full-blown versions of the corresponding applications, added by other packages. Is that correct ?

If so, then I see two drawbacks with this approach. They are not unacceptable, but they are drawbacks:

1. We have to keep the optional dependency on Busybox in util-linux, coreutils, fbset, and all those packages that conflict with Busybox. Indeed, removing the symbolic link installed by Busybox only works if Busybox is installed first. Unless Busybox "make install" is careful enough to not install a given symlink if a file of the same name already exists.

2. The Busybox binary would contain lots of useless code, which simply can't be reached, except by calling explicitly "busybox cmd".

So neither are unacceptable drawbacks, but they are drawbacks. If the general opinion is that we should do what you propose, I'm fine with implementing that.

What do others think ?

Quoting busybox.mk:

# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any

# full-blown versions of apps installed by other packages with sym/hard links.

Unfortunately, the noclobber implementation is racy. So the alternative is to remove apps from the generated busybox.links file that install.sh uses as input.

Quoted 2 lines

2. The Busybox binary would contain lots of useless code, which simply can't be reached, except by calling explicitly "busybox cmd".

This is not different than the situation we have now. The added useless code size is in most cases negligible compared to any one of the full-blown version. In the end it's the responsibility of the user to fine tune the target image size.

Hi Thomas,

Quoted 21 lines · Thomas Petazzoni

Quoted 2 lines · Baruch Siach

This means that a custom Busybox .config will automagically be transformed to something quite different. This is a significant change in behaviour.

We already tweak the Busybox .config file quite significantly in busybox.mk, so it's not really new. But I agree that the scale of the change is very different.

Quoted 3 lines

Can't we just move the symlink removal logic into busybox.mk instead? That would leave the busybox binary alone, and keep the magic .config transformations to minimum.

If I understand your proposal, we would not tweak the Busybox .config file, but instead add a post install target hook that would remove the symbolic links installed by Busybox "make install" when such symbolic links are going to conflict with full-blown versions of the corresponding applications, added by other packages. Is that correct ?

If so, then I see two drawbacks with this approach. They are not unacceptable, but they are drawbacks:

Quoted 6 lines

1. We have to keep the optional dependency on Busybox in util-linux, coreutils, fbset, and all those packages that conflict with Busybox. Indeed, removing the symbolic link installed by Busybox only works if Busybox is installed first. Unless Busybox "make install" is careful enough to not install a given symlink if a file of the same name already exists.

Quoting busybox.mk:

# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any

# full-blown versions of apps installed by other packages with sym/hard links.

Unfortunately, the noclobber implementation is racy.

So the alternative is to
remove apps from the generated busybox.links file that install.sh uses as input.

Quoted 2 lines

2. The Busybox binary would contain lots of useless code, which simply can't be reached, except by calling explicitly "busybox cmd".

This is not different than the situation we have now. The added useless code size is in most cases negligible compared to any one of the full-blown version. In the end it's the responsibility of the user to fine tune the target image size.

Quoted 5 lines

So neither are unacceptable drawbacks, but they are drawbacks. If the general opinion is that we should do what you propose, I'm fine with implementing that.

What do others think ?

baruch

Signature · 7 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

On 2017-12-14 08:58 +0200, Baruch Siach spake thusly:

Quoted 5 lines

Quoting busybox.mk:

# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any

# full-blown versions of apps installed by other packages with sym/hard links.

Quoted 1 line

Unfortunately, the noclobber implementation is racy.

How is it racy?

At the moment we're gonna call it, no other package will be installing at the same time (in the location seen by busybox at least), so there should be no race.

On 2017-12-28 17:23 +0100, Yann E. MORIN spake thusly:

Quoted 1 line

On 2017-12-14 08:58 +0200, Baruch Siach spake thusly:

[--SNIP--]

Quoted 5 lines

Quoted 5 lines

Quoting busybox.mk:

# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any

# full-blown versions of apps installed by other packages with sym/hard links.

Quoted 7 lines

Quoted 1 line

Unfortunately, the noclobber implementation is racy.

How is it racy?

At the moment we're gonna call it, no other package will be installing at the same time (in the location seen by busybox at least), so there should be no race.

Yet there were some issues with that part, so I've sent a small patch-series to busybox to fix the noclobber stuff:

    http://lists.busybox.net/pipermail/busybox/2017-December/086039.html

So, with this, we should be able to:

- invert the dependency chain, so thatr busybox now depends on all

    otehr packages that it may install applets of;

- drop the big list of applets-to-disable in busybox, and rely on the install-noclobber install rule

If upstream accepts that series, of course...

Quoted 22 lines

On 2017-12-28 17:23 +0100, Yann E. MORIN spake thusly:

Quoted 1 line

On 2017-12-14 08:58 +0200, Baruch Siach spake thusly:

[--SNIP--]

Quoted 5 lines

Quoted 5 lines

Quoting busybox.mk:

# Enable "noclobber" in install.sh, to prevent BusyBox from overwriting any

# full-blown versions of apps installed by other packages with sym/hard links.

Quoted 7 lines

Quoted 1 line

Unfortunately, the noclobber implementation is racy.

How is it racy?

At the moment we're gonna call it, no other package will be installing at the same time (in the location seen by busybox at least), so there should be no race.

Yet there were some issues with that part, so I've sent a small patch-series to busybox to fix the noclobber stuff:

    http://lists.busybox.net/pipermail/busybox/2017-December/086039.html

So, with this, we should be able to:

Quoted 2 lines

- invert the dependency chain, so thatr busybox now depends on all

    otehr packages that it may install applets of;

Why would we need a dependency at all? Either busybox builds before that other package (like we do today) in which case the other package overwrites the busybox symlink, or that other package builds before busybox, and then the noclobber option does the right thing.

As was discussed during the DevDays in Pragues about top-level parallel build, we've concluded that we could not have two packages that touch the same file.

When we are doing top-level parallel build, we no longer have any guarantee of the ordering, especially the order packages install in target/, so we loose the reproducibility that sequentiallity currently provides.

So we have to ensure proper install ordering, so that we guarantee what files are in target/.

So we either go with the current dependencies, added to all packages to ensure they get installed after busybox, or we add them to busybox so it gets installed after all the packages for which it may provide applets.

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) \
    [...]

Rather than duplicate the optional dependency on Busybox in all the packages (and as Thomas demonstrated, there are quite a few of them).

I may even go further: we could even make busybox depend on *all* packages, irrespective on whether it provides applets for them or not, since busybiox is pretty fast to build and does build in parallel quite nicely anyway. That would nicely solve the issue.

Quoted 24 lines

As was discussed during the DevDays in Pragues about top-level parallel build, we've concluded that we could not have two packages that touch the same file.

When we are doing top-level parallel build, we no longer have any guarantee of the ordering, especially the order packages install in target/, so we loose the reproducibility that sequentiallity currently provides.

So we have to ensure proper install ordering, so that we guarantee what files are in target/.

So we either go with the current dependencies, added to all packages to ensure they get installed after busybox, or we add them to busybox so it gets installed after all the packages for which it may provide applets.

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) \
    [...]

Quoted 2 lines

Rather than duplicate the optional dependency on Busybox in all the packages (and as Thomas demonstrated, there are quite a few of them).

Seems like a good idea to me.

Quoted 4 lines

I may even go further: we could even make busybox depend on *all* packages, irrespective on whether it provides applets for them or not, since busybiox is pretty fast to build and does build in parallel quite nicely anyway. That would nicely solve the issue.

I don't really like this approach, I find it too brutal.

Since we have the testing logic to validate that no package overwrites files from another package, I think the approach of having explicit dependencies in Busybox is good enough.

Quoted 4 lines

Quoted 2 lines

Rather than duplicate the optional dependency on Busybox in all the packages (and as Thomas demonstrated, there are quite a few of them).

Seems like a good idea to me.

For that, we'll need the three-patch series I submitted to Busybox:

    http://lists.busybox.net/pipermail/busybox/2017-December/086039.html

Quoted 1 line

I don't really like this approach, I find it too brutal.

Sorry, I was not advocating for this solution. What I meant was that, to simplify things even further we could do that. But I don't think we need that.

Quoted 3 lines

Since we have the testing logic to validate that no package overwrites files from another package, I think the approach of having explicit dependencies in Busybox is good enough.

Once we turn the warniong into a hard error, yes. ;-)

Quoted 5 lines

Quoted 3 lines

Quoted 2 lines

Rather than duplicate the optional dependency on Busybox in all the packages (and as Thomas demonstrated, there are quite a few of them).

Seems like a good idea to me.

For that, we'll need the three-patch series I submitted to Busybox:

    http://lists.busybox.net/pipermail/busybox/2017-December/086039.html

Absolutely. Hopefully, upstream will give some feedback soon.

Upstream has merged those three patches now, so we can rely on a clean way to install without clobbering existing utils; we just have to use:
make install-noclobber

Quoted 3 lines

Upstream has merged those three patches now, so we can rely on a clean way to install without clobbering existing utils; we just have to use:
make install-noclobber

Great! So the idea is to have Busybox install its stuff *after* all the packages that install full-blown versions. Correct ?

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) \
    [...]

Quoted 4 lines

I prefer the second option, because it concentrates the dependency chain in a single package, and it becomes very easy to write:

Quoted 4 lines

    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:

BUSYBOX_INSTALL_DEPENDENCIES = coreutils util-linux ...

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.

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.

On 2017-12-29 19:54 +0000, Trent Piepho spake thusly:

Quoted 10 lines · Yann E. MORIN

Quoted 8 lines

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) \
    [...]

Quoted 2 lines

Could one have a package variable specifically for install dependencies, like:

I think you already suggested so on IRC a while back, right?

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.

As we discussed during the Prague Buildroot Developers meeting, in order to implement per-package SDK, we need to ensure that no package overwrites files installed by another package.

This RFC series is an attempt at solving this problem for Busybox. I have not fixed all packages yet: since it is a very boring task to do, I wanted to first get some feedback on whether the approach looks reasonable or not.

If the feedback is positive, I'll go ahead and submit proper patches that fix all packages that conflict with Busybox.

Thanks for your feedback!

Thomas

Thomas Petazzoni (2):
busybox: avoid conflict with other packages
packages: drop no longer needed busybox dependencies

 package/bc/bc.mk                   |  5 ----
 package/binutils/binutils.mk       |  5 ----
 package/busybox/busybox.mk         | 58 ++++++++++++++++++++++++++++++++++++++
 package/coreutils/coreutils.mk     |  6 ----
 package/cpio/cpio.mk               |  1 -
 package/dcron/dcron.mk             |  5 ----
 package/debianutils/debianutils.mk |  2 --
 package/diffutils/diffutils.mk     |  4 ---
 package/fbset/fbset.mk             |  5 ----
 package/kmod/kmod.mk               |  3 --
 package/util-linux/util-linux.mk   |  6 ----
 11 files changed, 58 insertions(+), 42 deletions(-)

Signature · 6 lines

2.14.3

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 7 lines

This RFC series is an attempt at solving this problem for Busybox. I have not fixed all packages yet: since it is a very boring task to do, I wanted to first get some feedback on whether the approach looks reasonable or not.

If the feedback is positive, I'll go ahead and submit proper patches that fix all packages that conflict with Busybox.

As I previously said on IRC: I do not much like the big list we will now have to maintain; that's sad...

However, I like the fact that we can get rid of the many dependencies in so many packages here and there. :-)

What I would have suggested, though, is to do what Baruch hinted at: use the noclobber install of Busybox, and then have Busybox depend on all the packages it provides applets for:

    BUSYBOX_DEPENDENCIES = \
        $(if $(BR2_PACKAGE_COREUTILS),coreutils) \
        $(if $(BR2_PACKAGE_util_LINUX),util-linux) \
        etc...

But unfortunately, the noclobber install option is not usable:

- first, there is no way to cause a noclobber install;

- second, the noclobber is not accounted for in the case shell wrappers are used.

So, I'm afraid we don't have much choice but to do as your series does...

Hello,

Thanks for the feedback.

Quoted 5 lines · Yann E. MORIN

Quoted 5 lines

This RFC series is an attempt at solving this problem for Busybox. I have not fixed all packages yet: since it is a very boring task to do, I wanted to first get some feedback on whether the approach looks reasonable or not.

Quoted 5 lines

Quoted 2 lines

If the feedback is positive, I'll go ahead and submit proper patches that fix all packages that conflict with Busybox.

As I previously said on IRC: I do not much like the big list we will now have to maintain; that's sad...

Even though I agree it's not nice to maintain, I think it's unavoidable if we want to solve the overwriting issue.

Quoted 14 lines

However, I like the fact that we can get rid of the many dependencies in so many packages here and there. :-)

What I would have suggested, though, is to do what Baruch hinted at: use the noclobber install of Busybox, and then have Busybox depend on all the packages it provides applets for:

    BUSYBOX_DEPENDENCIES = \
        $(if $(BR2_PACKAGE_COREUTILS),coreutils) \
        $(if $(BR2_PACKAGE_util_LINUX),util-linux) \
        etc...

But unfortunately, the noclobber install option is not usable:

Quoted 7 lines

- first, there is no way to cause a noclobber install;

- second, the noclobber is not accounted for in the case shell wrappers are used.

So, I'm afraid we don't have much choice but to do as your series does...

There is however one remaining debate: my patch series tweaks the Busybox configuration to not build the support for applets for which the functionality is provided by a full-featured program. But Baruch didn't like this tweaking of the Busybox configuration, and would prefer to not install the symlinks, and leave the Busybox configuration unchanged (which means we have lots of Busybox applets built into Busybox that are not really used on the target).

Do you have an opinion on this specific topic ?

Another question is whether we want to have this logic centralized in busybox.mk, or spread into the packages that provide the full-featured variants of the applets ? The latter may have some variable definition ordering issues though.

On 2017-12-28 18:04 +0100, Thomas Petazzoni spake thusly:

Quoted 9 lines

Thanks for the feedback.

Quoted 5 lines · Yann E. MORIN

Quoted 5 lines

This RFC series is an attempt at solving this problem for Busybox. I have not fixed all packages yet: since it is a very boring task to do, I wanted to first get some feedback on whether the approach looks reasonable or not.

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

If the feedback is positive, I'll go ahead and submit proper patches that fix all packages that conflict with Busybox.

As I previously said on IRC: I do not much like the big list we will now have to maintain; that's sad...

Even though I agree it's not nice to maintain, I think it's unavoidable if we want to solve the overwriting issue.

So that we are on the same line: I do agree with the underlying reason for the change, yes. I'm just trying to see if there are better ways to go with that.

Quoted 30 lines

Quoted 14 lines

However, I like the fact that we can get rid of the many dependencies in so many packages here and there. :-)

What I would have suggested, though, is to do what Baruch hinted at: use the noclobber install of Busybox, and then have Busybox depend on all the packages it provides applets for:

    BUSYBOX_DEPENDENCIES = \
        $(if $(BR2_PACKAGE_COREUTILS),coreutils) \
        $(if $(BR2_PACKAGE_util_LINUX),util-linux) \
        etc...

But unfortunately, the noclobber install option is not usable:

Quoted 7 lines

- first, there is no way to cause a noclobber install;

- second, the noclobber is not accounted for in the case shell wrappers are used.

So, I'm afraid we don't have much choice but to do as your series does...

There is however one remaining debate: my patch series tweaks the Busybox configuration to not build the support for applets for which the functionality is provided by a full-featured program. But Baruch didn't like this tweaking of the Busybox configuration, and would prefer to not install the symlinks, and leave the Busybox configuration unchanged (which means we have lots of Busybox applets built into Busybox that are not really used on the target).

Quoted 1 line

Do you have an opinion on this specific topic ?

I prefer they be explicitly disabled as you did.

First, because this is a security issue that there is dead code: these applets are still usable by calling 'busybox foo' for example, and that is a security issue.

Second, yes it gains a bit of space. But that is not so compelling, becasue if you already have the big buddies enabled, a few kB lost inBusybox is not that much of a burden anyway...

Quoted 4 lines

Another question is whether we want to have this logic centralized in busybox.mk, or spread into the packages that provide the full-featured variants of the applets ? The latter may have some variable definition ordering issues though.

Please leave it centralised in busybox.mk.

Quoted 1 line

On 2017-12-28 18:04 +0100, Thomas Petazzoni spake thusly:

Quoted 8 lines

Quoted 8 lines

There is however one remaining debate: my patch series tweaks the Busybox configuration to not build the support for applets for which the functionality is provided by a full-featured program. But Baruch didn't like this tweaking of the Busybox configuration, and would prefer to not install the symlinks, and leave the Busybox configuration unchanged (which means we have lots of Busybox applets built into Busybox that are not really used on the target).

Quoted 3 lines

Quoted 1 line

Do you have an opinion on this specific topic ?

I prefer they be explicitly disabled as you did.

As I said earlier, I don't like this heavy handed modification of the Busybox configuration. I'm not sure how robust this solution would be, as there might be unintended consequences. Kconfig 'select' and 'depends' contribute to that. I prefer to keep config modifications to minimum.

Quoted 3 lines

First, because this is a security issue that there is dead code: these applets are still usable by calling 'busybox foo' for example, and that is a security issue.

That is no different than the current behaviour.