On 9/7/26 11:12, Benjamin Drung wrote:
...
For initrd, please use regular, non-static, busybox build. Since many
other binaries in initrd already require libc, there's no need to keep
*another* copy of libc within busybox binary. And the regular busybox
is build without PREFER_APPLETS option, so you can use a more advanced
version of some utility.
You are right. This is a XY problem and I failed to describe the
underlying problem.
For an initrd it makes sense to use the busybox package that is linked
against libc, because the libc will be included in the initrd anyway. So
the static busybox would make the initrd bigger without a benefit.
The real problem I am facing is: The busybox and busybox-static packages
conflict with each other. So in case users wants to install busybox-
static they have to remove busybox and would loose using busybox inside
the initrd. That was the pure reason for me to try to support busybox-
static.
Aha. This all makes perfect sense now. And this is a very good topic
you bought up, something I failed to think about for years if not
decades.
We've quite a few tools like this in debian aimed for rescue purposes, -
sash, ef2fsc-static, bash-static, even zsh-static (!). Some of them
made sense back in 1990s, but I think all of them makes no sense now
in 2020s.
Would it be possible to rename busybox to busybox-static in the busybox-
static package to make both packages co-installable?
Yes, that would be one of the solutions. But a better solution, it looks
like, is to just drop busybox-static package entirely. It serves no real
purpose these days.
One more question: You say that busybox-static should not be used in the
initrd, but why does busybox-static ship an initramfs-tools hook to use
it in the initrd? I assume that initramfs-tools might have similar
issues when using with busybox-static.
I think it was just for symmetry and/or due to inertia. And due to lack
of real attention to this matter for decades. We should've thought about
the relation between busybox and busybox-static packages long, long time
ago. Instead, we just marked the two to conflict with each other, in
order to fix some immediate issue, and that's it.
I looked at reverse dependencies of busybox-static, - most dependencies
are written as alternative --
Depends|Recommends: busyox | busybox-static
this is because both provides similar set of applets in a same-named
binary (so reaming the binary is a bit more complicated). Some do it
in reverse order:
Depends|Recommends: busyox-static | busybox
so preferring the static build, but still accepting regular. These are
Ok too. But some actually depends on the static build, for example:
lxc-templates: Recommends: busybox-static
and especially:
virtme-ng: Depends: busybox-static
This one needs to be fixed.
This is a more general question, -- I'll bring it up on debian-devel@.
Thank you for the input!
/mjt
