<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 24, 2024 at 1:12 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/22/24 10:26, enh wrote:<br>
> On Fri, Mar 22, 2024 at 8:24 AM enh <<a href="mailto:enh@google.com" target="_blank">enh@google.com</a>> wrote:<br>
>> (tbh, just merging "lsb" into "other" would be a step forwards. wtf<br>
>> is/was "lsb" anyway? and while i can _usually_ guess "POSIX or not?"<br>
>> correctly, "lsb or other" is impossible by virtue of being<br>
>> meaningless.)<br>
> <br>
> (and to be clear, although "lsb" is particularly obscure, i think this<br>
> is the same problem busybox's organization has: why do i have to care<br>
> whether something is in coreutils or linux-utils or procps? how is<br>
> that relevant to me?<br>
<br>
There's a reason I didn't use that as an organizing method. Although I did try<br>
to map them at the end of the roadmap, and need to redo that analysis now since<br>
it's been a while...<br>
<br>
> the best answer i can think of is "because i want<br>
> to only use toybox/busybox to replace _that_ package", but i don't<br>
> think the _directory structure_ helps there, right? that hypothetical<br>
> person actually wants more metadata in the kconfig part of the comment<br>
> inside each file?)<br>
<br>
That's the theoretical use, yes. So distros (and system builders like gentoo,<br>
buildroot, yocto, etc) can annotate package alternatives so if you want to<br>
install busybox's tar instead of gnu tar your package management system could<br>
cope. </blockquote><div><br></div><div>yeah, "equivalent package" might be another field to add to your kconfig replacement --- then folks could configure toybox as "coreutils" or "procps" or both or whatever.</div><div><br></div><div>(but, like i say, _i've_ never used this, and can't really imagine why i'd not just want "all the things", so...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In practice, making something like dpkg handle that was near impossible,<br>
and buildroot only did it because the maintainer of busybox created buildroot. I<br>
tried to add toybox to buildroot years ago and...<br>
<br>
<a href="https://lists.buildroot.org/pipermail/buildroot/2014-September/409298.html" rel="noreferrer" target="_blank">https://lists.buildroot.org/pipermail/buildroot/2014-September/409298.html</a><br>
<br>
People still try from time to time:<br>
<br>
<a href="https://lists.buildroot.org/pipermail/buildroot/2017-January/181960.html" rel="noreferrer" target="_blank">https://lists.buildroot.org/pipermail/buildroot/2017-January/181960.html</a><br>
<a href="http://lists.busybox.net/pipermail/buildroot/2022-September/652474.html" rel="noreferrer" target="_blank">http://lists.busybox.net/pipermail/buildroot/2022-September/652474.html</a><br>
<br>
But even a build system that ALREADY lets you swap in/out buildroot vs gnu<br>
versions of packages accomplished that by hardwiring busybox support deep into<br>
its build system.<br>
<br>
Getting something like debian to do that on the fly is... it's not really<br>
designed for it.<br>
<br>
I can think of better ways to do it (and am studying debian's build system in my<br>
copious free time), but I've been busy with other things and most people aren't<br>
motivated to try...<br>
<br>
I note that I did it by hand back when creating aboriginal linux, which is what<br>
led me to maintaining busybox in the first place, ala:<br>
<br>
<a href="https://landley.net/aboriginal/old/" rel="noreferrer" target="_blank">https://landley.net/aboriginal/old/</a><br>
<br>
> When the Firmware Linux project started, busybox applets like sed and sort<br>
> weren't powerful enough to handle the "./configure; make; make install" of<br>
> packages like binutils or gcc. Busybox was usable in an embedded router or<br>
> rescue floppy, but trying to get real work done with it revealed numerous<br>
> bugs and limitations.<br>
> <br>
> Busybox has now been fixed, and in Firmware Linux Busybox functions as an<br>
> effective replacement for bzip2, coreutils, e2fsprogs, file, findutils, gawk,<br>
> grep, inetutils, less, modutils, net-tools, patch, procps, sed, shadow,<br>
> sysklogd, sysvinit, tar, util-linux, and vim. (Eventually, it should be<br>
> capable of replacing bash and diffutils as well, but it's not there yet.)<br>
<br>
That's the old page from before I restarted the project and renamed it<br>
Aboriginal Linux (based on QEMU instead of User Mode Linux, ala<br>
<a href="https://landley.net/notes-2005.html#27-10-2005" rel="noreferrer" target="_blank">https://landley.net/notes-2005.html#27-10-2005</a>). Before that I was going though<br>
the Linux From Scratch package list and _disposing_ of gnu packages, one by one,<br>
as I got busybox to replace them.<br>
<br>
But "dpkg-query -S $(which $NAME)" is pretty easy to do the mapping yourself on<br>
debian...<br></blockquote><div><br></div><div>(yeah, though i suspect anyone trying to do this hypothetical "swap package $X for toybox" would want the _opposite_ mapping, from package name to all the commands. and i don't know of a way to ask apt that question? other than brute-forcing all of the executables in all of the directories in $PATH, anyway.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>