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