Extension Development :: gnu-utils



Having being caught out again by compiling with gnu-utils loaded (thanks for the feedback Jason), I'm wondering if it makes sense to have a gnu-utils.uci that can be unloaded.

A couple of questions:

1. Was gnu-utils originally intended to be only coreutils from here http://directory.fsf.org/project/coreutils/ ?
2. Given that there are probably more extensions containing xlibs, gtk2, etc than when gnu-utils was created, does it make sense to have only coreutils in gnu-utils?
3. Without having looked yet, I presume gnu-utils.dsl overwrites some apps in the base dsl - in the uci, I guess it would be OK to add a load script that moves these apps to /tmp and an unload script that moves them back?

The reasoning behind all this is that I need gnu-utils loaded at boot to load alsa at boot and (I guess) I also use some of the fully fledged (versus busybox) utilities without realising it, but I also need a way to unload gnu-utils to check that extensions do not depend on it.

The original concept of gnu-utils were to be the gnu versions of that which busybox replaced - period.

While the extension managment was not under my control, gnu-utils became a catch-all of stuff, including X.

I would think it would be worthy to clean up gnu-utils to be that which it was meant to be. This would reduce conflicts but likely break old(er) extensions.

If gnu-utils is cleaned up, then we would need some effort to test and correct and/or remove old extensions that depended on a catch-all gnu-utils.

coreutils is already a mountable extension...I just got the latest release yesterday so there might be an update to the extension if people are actually using it.  Might also look into updating some of the other basics like findutils and procps.

As robert said gnu-utils is much more than coreutils. But it is *less* than a full busybox replacement, as some busybox applets remain unchanged after installation.

I also agree that gnu-utils could be improved, among other things by making a uci version.  Another suggestion I would have is to separate a few of the apps into individual packages. I extracted wget from gnu-utils and use that almost daily (busybox wget is kinda lame in my opinion), but hardly ever use gnu-utils itself.

Quote
coreutils is already a mountable extension...I just got the latest release yesterday so there might be an update to the extension if people are actually using it.  Might also look into updating some of the other basics like findutils and procps.

- now that sounds like a good idea. Now I know that coreutils.uci exists I'll try it out instead of gnu-utils, though I guess I'll still need find.

I guess I also need to check if the alsa boot code looks for gnu-utils or just the app(s) it requires from gnu-utils in which case coreutils.uci might do the job.

Quote
I also need to check if the alsa boot code looks for gnu-utils


yes:
Code Sample
grep -qw gnu-utils /tmp/mydsl.map || [ -f "$MYDSLINSTALLED"/gnu-utils


But you could make up your own boot code and check for it from bootlocal.sh, using the alsa code from /etc/init.d/dsl-config (lines 449-457 in DSL 4.2)

Next Page...
original here.