RFC
Is it possible to limit BusyBox applets to /bin
and /sbin
by default?
Goal
Prevent opkg from modifying /usr/bin
and /usr/sbin
when the user upgrades BusyBox.
Is it possible to limit BusyBox applets to /bin
and /sbin
by default?
Prevent opkg from modifying /usr/bin
and /usr/sbin
when the user upgrades BusyBox.
maybe...
CONFIG_BUSYBOX_DEFAULT_INSTALL_NO_USR
Yep, it looks promising.
I wonder why this is not enabled by default.
removed the solved... looking forward to more input also...
as nobody weighed in yet... i'll throw out some hypothesis;
it would seem this is not a relevant topic to most with the skills or power to make a difference...
BysyBox applets are just symlinks, so it shouldn't really matter where they are located as long as it is within the PATH.
But, I'm afraid this issue may be a bit more complicated:
> for PKG in ip-tiny ip-full busybox; \
> do opkg files ${PKG}; done | grep -e /ip
/usr/libexec/ip-tiny
/usr/libexec/ip-full
/sbin/ip
Thus, isolating BusyBox is not a complete solution.
The best option would be using something like alternatives.
On the other hand, it is still better than the current situation.
The event doesn't happen often, but it's already multiple users who reported the issue.
In my experience, there are usually at least ten times more people who have encountered the problem than reported.
And this is not the first time, the wave of cries floods the forum every time we have a new BusyBox version.
i'm trying to track down a post where jow / slh / hnyman? laid out some useful info re: package postinst like scripts... and something about updating all their makefiles... best info on this topic i've seen here...
while i'm looking ... may as well pin some of the more useful... / related posts I come across...
ib sort conflict query
buildroot make selections order issue ~ transient?
related to above
when something core needs to be less core
waxing the shell spot
you [s]scream[/s] stream are another fish kettle
ok... this is the one I was looking for... thank @hnyman
application centric philosophy
nope: it was this one...
for this in $(opkg files busybox | grep -vE '(^Pack|^/etc)'); do echo "$this: $(readlink -f $this) $(opkg search $(readlink -f $this) | cut -d' ' -f1)" | grep -v ' busybox$'; done
/sbin/ip: /usr/libexec/ip-full ip-full
/bin/sleep: /usr/bin/gnu-sleep coreutils-sleep
/usr/bin/sort: /usr/bin/gnu-sort coreutils-sort
/usr/bin/cmp: /usr/bin/gnu-cmp diffutils
/usr/bin/top: /etc/custom/busybox.static.4-model-b
Yep, I've already checked that way, but it works only for installed packages and only if they were installed later than busybox
, e.g. you are missing ip-tiny
.
This whole issue seems to be part of a bigger and more serious problem.
Currently it is not recommended to perform package upgrades.
However, time flies and things change...
High performance network hardware, virtualization and containers are not so rare nowadays.
These use cases have no hardware limitations to perform upgrades.
If OpenWrt cannot provide this functionality, it may eventually lose its position and users.
It looks like there's no much point to keep this thread open.
What should have been said has already been said.
The BusyBox config parameter works around the issue for me well enough.
Probably it's best to continue by opening a ticket on the bug tracker, or contributing the patches directly.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.