Hi,
while reading the README file of sbase I noticed `sponge`, remembered
that that's from moreutils and realized that sbase does not provide a
strict subset of coreutils, what I assumed for some reason.
The description of sbase is:
sbase is a collection of unix tools that are inherently portable
across UNIX and UNIX-like systems.
The description of ubase is:
ubase is a collection of tools similar in spirit to util-linux
but much simpler.
Both definitions make sense, but they are a bit unprecise IMO.
I did some digging and came up with the following numbers based on
package contents of Debian jessie. I chose that distro just because
that's what I have on my main laptop.
Since sbase and ubase are modeled loosely after coreutils and util-linux
I had a look especially on those.
coreutils:
number of executables installed: 101
number of ports in sbase: 58
number of ports in ubase: 5
missing: 38
util-linux:
number of executables installed: 72
number of ports in sbase: 1
number of ports in ubase: 12
missing: 59
The fact that a minor number of tools from coreutils ended up in ubase
and one from util-linux in sbase is clearly because of
(non-)portability.
The binaries in sbase come from these 16 packages on Debian jessie:
binutils
bsdmainutils
bsdutils
coreutils
cron
diffutils
findutils
grep
hostname
moreutils
procps
sed
sharutils
tar
time
util-linux
The binaries in ubase come from these 16 packages on Debian jessie:
coreutils
eject
initscripts
kbd
kmod
loadlin
login
mount
ncurses-bin
passwd
procps
readahead-fedora
sysvinit
sysvinit-tools
sysvinit-utils
util-linux
That's not totally straight-forward :)
Also, some tools in sbase are non-POSIX, but the vast majority is.
Though, even coreutils just contains a subset of the POSIX utilities,
see [1], there are 160 utilities listed.
Most likely it won't make sense to implement all of them, even in the
long run.
Over time the list of implemented utilities will grow and sbase will
suck because it contains a confusing number of utilities.
There are people who want/need a strict set of POSIX utilities, nothing
else.
Here are some actions I'd like to discuess:
* Split sbase in two parts
+ A collection of a subset of POSIX utilities, implemented suckless
+ A collection of portable non-POSIX utilities
* Add clarifications to the README files of both sbase and ubase
+ A short motivation for each utility in sbase that's not in
coreutils
+ A short motivation for each utility in ubase that's not in
util-linux
+ For all utilities from coreutils that are not (yet) in sbase,
are they wanted/needed or not. If not, then why.
+ For all utilities from util-linux that are not (yet) in ubase,
are they wanted/needed or not. If not, then why.
+ For all utilities demanded by POSIX but not (yet) implemented in
either sbase or ubase, are they wanted/needed or not. If not, then
why.
+ Why does sbase have the name sbase?
If I did not know the name of the project and should pick one
myself, I'd choose ubase like 'UNIX base'.
sbase may be confusing to some people and should therefore be
clarified.
+ Why does ubase have the name ubase?
If I did not know the name of the project and should pick one
myself, I'd choose lbase like 'Linux base'.
ubase may be confusing to some people and should therefore be
clarified.
I am quite sure the motivation for all those are either in the heads of
the developers or in the ML archive or both, they would just have to be
written down.
Kind regards,
-Alex^Wblackbit
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html
Received on Mon Mar 09 2015 - 01:51:59 CET