A quick comparison w/ only basics installed: | /bin | /lib (+pam -kernel mods) --------+-------+----------------------------- DEBIAN | 2.4M | 3.4M LFS | 1.9M | 2.8M GENTOO | 6.4M | 4.1M (assuming 1K blocksize - default 4K makes matters even worse) Add /sbin and kernel and the resulting size will be too big to fit into a 16MB ROM - no prob w/ deb & lfs. Biggest offenders are bzip2, coreutils, gawk, gzip, pam. bzip2: only bzip2 should be in /bin coreutils: 80% of provided apps are never used until /usr is mounted gawk: pgawk & igawk not essential for booting (+ mawk is a lot smaller) gzip: should be in /usr/bin except for gzip lib: .so symlinks and .a files should be in /usr/lib - ld never look for libs in /lib mailx: not really useful until mta (in /usr) is started pam: some modules (esp. pam_console) are non-standard, rarely used and severely bloated (make optional per useflag?) -- Merry Xmas - and keep up the good work Reproducible: Always Steps to Reproduce: 1. emerge base system 2. try to copy root file system to 16MB flash partition Actual Results: It's too big. Expected Results: It should not be too big. Procedure works on Debian and LFS w/o resorting to busybox.
Sorry about the table formatting - looks like a css problem - shouldn't text in <pre> be rendered with a fixed width font? -- Merry Xmas - and keep up the good work
Just some ideas.. ------------------------------------------------------------------------ bzip2: agreed ------------------------------------------------------------------------ coreutils: Please paste the 20% you think that should stay before /usr mounted. ------------------------------------------------------------------------ gawk: I think this is used by the initscripts when mounting the file system. ------------------------------------------------------------------------ gzip: agreed ------------------------------------------------------------------------ lib: -fPIC and strip see pam: ------------------------------------------------------------------------ mailx: should be moved to /usr/bin/mailx and symlink pointed back to /bin/mailx shell scripts look for mailx in /bin ------------------------------------------------------------------------ pam: pam_console - seems to be everybodys nightmare. Is it however needed for devfsd? --- If pam is compiled -fPIC and it should be as any shared object should be then should be strip safe. 608K security (stripped) 684K security.bak (no stripped) perhaps in the /usr/lib/portage/bin/prestrip we can add the follwing code if [ -z "${f/*SB shared object*/}" ]; then echo " ${x:${#D}:${#x}}" ${STRIP} --strip-debug "${x}" if [ -x /usr/bin/readelf ]; then ret=`readelf -d /bin/ls | grep TEXTREL` if [ $? == 1 ]; then echo "Strip Safe Shared Object" ${STRIP} --strip-unneeded "${x}" fi fi -------------------------------------------------------------------------------- We welcome user contributions especially when they include the functionalty your asking for. Eg: patches for all ebuilds you would like to see fixed.
- ret=`readelf -d /bin/ls | grep TEXTREL` + ret=`readelf -d "${x}" | grep TEXTREL`
i think he was saying that gawk is needed for booting, but igawk and pgawk are not ... and he was saying that mgawk is a smaller binary and could possibly be used to substitue for gawk
what has strip got to do with -fPIC? shared libraries are always stripped. you can strip static libs if relevant sections are left intact; -fPIC or not. don't compile static libs with -fPIC; thats pure nonsense. a. see drobin's post on mailing list b. static libs have no buziness beeing in /lib (I'm talking about libpci, libwrap, libz) pam modules dont need -fPIC pam_console is an ugly hack which serves no useful purpose (do any of debian, slackware, suse, knopix, etc use it?)
Sorry, bad timing - I don't have access to my Gentoo box over the holydays, > coreutils: > Please paste the 20% you think that should stay before /usr mounted. There does not seem to be a standard which binaries are required to be in /bin (or Google just did not find it), but there seems to be a set of progs which are always in /bin across all vendors/distributors plus some programs which different distributions move to /bin individually based on what is needed in their init scripts (the 80% are based on size, not number of files, on Debian (20% /bin, 80% /usr/bin) - although I have not been able to get down to Debian's file sizes - even using the same version of coreutils / binutils / gcc, Debian's is always smaller). > gawk: > I think this is used by the initscripts when mounting the file system. The way I see it gawk (but not igawk/pgawk ;)) is used a lot for line splitting, but as a additional improvement, can't that be done in plain sh also? > pam: In my experience, -fPIC usually makes binaries slightly bigger, and since pam_modules are dlopen'ed only while they're in use, they are smaller and faster w/o -fPIC (difference most likely not measurable though, + some mixed 32/64 bit architectures may require -fPIC for shared objects always). But what I was talking about is, other vendors (Debian for example) provide only the very basics in their PAM package and usually package all the more exotic modules separately - that's why I suggested to make them optional per USE flag. (du -h /lib/security: DEBIAN: 304K, GENTOO: 612K) > mailx: Maybe it's just me, but sometimes I have the opposite problem ;) - mail is looked for in /usr/bin and not found because it is in /bin. --
I'm inclined to disagree about pam modules needing PIC. Every shared object (.so) on a file system should by PIC aware. Debian is one such distro that has adpoted this as a policy for a few years now. In due time chances are Gentoo will adopt a similar policy. As for filenames.a I'm willing to work you guys to try and rid the root file systems of these. Please understand this will take some time, as changes in core packages have to be approved by a larger group of people. *awk: igawk/pgawk # epm -q -l gawk | xargs file | grep ELF | cut -d : -f 1 | xargs md5sum | sort 8fa1f640415b11542004d11ac89cd7d8 /bin/pgawk 8fa1f640415b11542004d11ac89cd7d8 /bin/pgawk-3.1.3 Looks like this is getting installed twice (or a hardlink happened) adding azarah@gentoo to look at this bug. coreutils: A list of filenames would help. mailx: well a move to /usr/bin/ with a symlink on /bin/ will fix this for everybody. adding net-mail@ to the CC list pam_console: Still a thorn in everybodys side. As far as I can tell here the only things that depends on it from /etc/pam.d/* is X stuff. I could be wrong. adding pam-bugs@ to the CC list. Re: comment #5 shared libraries are only stripped of debug info on gentoo as of now, so more can go..
Maybe I can help with the coreutils file list of files in `/bin'... slackware: ---------- (f): chgrp, chmod, chown, cp, dd, df, dircolors, du, ln, ls, mkdir, mkfifo, mknod, mv, rm, rmdir, shred, sync, touch (s): date*, echo*, false*, pwd*, sleep*, stty*, true*, uname* (t): cat*, cut*, head* (f=fileutils, s=sh-utils, t=textutils, *=symlinked from `/usr/bin') debian (coreutils_5.0.91, unstable) ----------------------------------- cat chgrp chmod chown cp date dd df dir echo false ln ls mkdir mknod mv pwd readlink rm rmdir vdir sleep stty sync touch* true uname (*=symlinked from `/usr/bin') ((debian also thinks `chroot' should be in `/usr/sbin'...makes sense because mortals are not allowed to use it)) As for `pam_console', I would not call it completely useless...in bigger networks it can be really annoying if users are able to eject each other's CDs (or floppies, remember those software ejectable floppy drives on older SUN hardware?) or pipe random garbage to `/dev/snd'...and there's a privacy issue with giving all floppy/cdrom members access to the raw devices (I know of a couple of inhouse solutions to grant users group memberships based on login-locations, but has anyone looked at `pam_group'?). The problem with pam_console, as I see it, is just that it depends on glib, which as far as I know has never been audited for use in system-critical applications and of course singnificantly increases module size. SuSE and Debian (and possibly others) have `pam-devperm', which provides similar functionality and does not depend on glib (which still leaves a couple of races with devfs and `/lib/dev-state').
SuSE also moves `sort' to `/bin' (symlink in `/usr/bin').
> bzip2: only bzip2 should be in /bin Sure. > coreutils: 80% of provided apps are never used until /usr is mounted I see somebody listed what Slack have - just rember, its not universal. FHS do have some guides, but I think its more what is really used, and what not, so if somebody want to do it, make sure you go trough all the scripts that runs in boot, and /sbin/rc (with whatever is related in /lib/rc-scripts/) to verify we do not break things. Oh, and halt.sh in /etc/init.d/. > gawk: pgawk & igawk not essential for booting (+ mawk is a > lot smaller) We use gawk, not mawk. Anyhow, mawk linked to awk/gawk will break the boot, as it uses gawk specific features. > gzip: should be in /usr/bin except for gzip Once again, somebody should verify that. > lib: .so symlinks and .a files should be in /usr/lib - ld never > look for libs in /lib Err, come again? Sure, .a's should be in /usr/lib (I am just not 100% sure about the pic .a's and .map's ..., and until proven otherwise, they stay). As for the .so symlinks, 90% of the time a binary links to a .so symlink (most of the times say libfoo.so.1 and not the real libfoo.so.1.43, as you want it to still work if minor version 1.44.0 comes out - all part of major/minor/micro versioning and binary compadibility), so move all those to /usr/lib, and /usr on another partition, and what as things break =) > mailx: not really useful until mta (in /usr) is started Err, you may be confused. you get two 'mail' programs: /usr/bin/mail: Usually just a client to send mail with, shipped with you MTA. /bin/mail: Simple client (with full read/write support) usually used in scripts etc. Mailx provides /bin/mail. > pam: some modules (esp. pam_console) are non-standard, rarely > used and severely bloated (make optional per useflag?) Err, you use pam_console as you sit here ? Its already used in system-auth. Sure, we can make them optional, but once again somebody have to walk the tree and see that we do not use any one that we try to rip (I know ssh use some sub standard ones).
Ok, I moved pgawk and igawk to /usr/bin; fixed pgawk to be a symlink to pgawk-$PV; moved libwrap.a to /usr/lib, and fixed bzip2 to use symlinks where appropriate: -- nosferatu root # ls -Sl $(epm -ql gzip | grep /bin/) -rwxr-xr-x 1 root root 59596 Jun 29 11:03 /bin/gzip -rwxr-xr-x 1 root root 3863 Jun 29 11:03 /bin/gzexe -rwxr-xr-x 1 root root 3526 Jun 29 11:03 /bin/znew -rwxr-xr-x 1 root root 2935 Jun 29 11:03 /bin/zgrep -rwxr-xr-x 1 root root 1953 Jun 29 11:03 /bin/zdiff -rwxr-xr-x 1 root root 1866 Jun 29 11:03 /bin/zmore -rwxr-xr-x 1 root root 1001 Jun 29 11:03 /bin/zforce -rwxr-xr-x 1 root root 94 Jun 29 11:03 /bin/zless lrwxrwxrwx 1 root root 5 Jun 29 11:03 /bin/zcmp -> zdiff lrwxrwxrwx 1 root root 5 Jun 29 11:03 /bin/zegrep -> zgrep lrwxrwxrwx 1 root root 5 Jun 29 11:03 /bin/zfgrep -> zgrep lrwxrwxrwx 1 root root 4 Jun 29 11:03 /bin/gunzip -> gzip lrwxrwxrwx 1 root root 4 Jun 29 11:03 /bin/gzcat -> gzip lrwxrwxrwx 1 root root 4 Jun 29 11:03 /bin/zcat -> gzip nosferatu root # ls -Sl $(epm -ql bzip2 | grep /bin/) -rwxr-xr-x 1 root root 108140 Dec 28 20:40 /bin/bzip2 -rwxr-xr-x 1 root root 8952 Dec 28 20:40 /bin/bzip2recover -rwxr-xr-x 1 root root 2105 Dec 28 20:40 /bin/bzcmp -rwxr-xr-x 1 root root 2105 Dec 28 20:40 /bin/bzdiff -rwxr-xr-x 1 root root 1582 Dec 28 20:40 /bin/bzegrep -rwxr-xr-x 1 root root 1582 Dec 28 20:40 /bin/bzfgrep -rwxr-xr-x 1 root root 1582 Dec 28 20:40 /bin/bzgrep -rwxr-xr-x 1 root root 1259 Dec 28 20:40 /bin/bzless -rwxr-xr-x 1 root root 1259 Dec 28 20:40 /bin/bzmore lrwxrwxrwx 1 root root 5 Dec 28 20:40 /bin/bunzip2 -> bzip2 lrwxrwxrwx 1 root root 5 Dec 28 20:40 /bin/bzcat -> bzip2 nosferatu root # -- So except for the main binary, most others is scripts and symlinks.
Just to clear things up here.. Nobody is talking about making .a files PIC aware.
Those of glibc is if you have 'pic' in USE - it then installs needed .a's and .map's.
I don't use pam_console - never did ;) I agree pam_console may have a place in large sites (see above) if it worked properly, but I don't like its dependency on glib also, plus it was never designed to work w/ devfs: - when devfsd is started & pam_console_apply_devfs.so is called in for the first time, /var (where it keeps lock & state files) is not mounted. - if devfsd startup is deferred until /var is available, expect various init scripts to break (classical deadlock situation). - pam_console can't be used if device file attributed are saved in /lib/dev-state. But again, that is not what I was complaining about ;) - the problem is the root file system as it is now is way to big to fit on small root devices - partly because programs/modules are installed in '/' which are rarely used (pam_console, pam_pwdb seems to be banned in other distributions also because of design flaws) - partly because of programs in '/' which are not needed for booting (csplit, expand, factor, fmt, fold, install, join, m5sum, nl, od, paste, pathchk, pinky, pr, sha1sum, shred, split, sum, tac, tail, test, tsort, unexpand, uniq, users, bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2recover, bzless, bzmore, date, dircolors, gzexe, wall, wc, zcat, zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore, znew). This list may be to short or too long - not sitting on my Gentoo Box now, if I missed something, sorry in advance. > mail: No confusion, there is no /usr/bin/mail (mta=sendmail) (2 binaries in path w/ the same name would also be in violation w/ several policies on other distributions) --
Sure, pam_pwdb is broken. Last time I checked, pam_console is still being used by RH and MDK - not sure about the others, and I for one use it all the time - start to wonder if I logged in as root in a console first, and then start another as user, and a lot of things break :/ As for the dup binaries in different locations - see postfix and some others. Another example of dups is mkpasswd. I never said we will not - I said _verify_ that whatever you want in /usr is NOT used, and now the second thing - make a patch and add it here. As for the small root idea - you will start to run into more and more issues, as glibc, etc start to support more features, etc. Also, have you checked lately what the size of /etc on a normal destop system is? then you sorda forget about /bin :/ If you ask my opinion - a small / will become something that is a very hard to maintain with the default packages, and will move to the catagory of special setups like livecd's etc that use busybox for instance, with maybe later on uclibc or klibc. Just my opinion though.
Well, then how about this first step: - reduce the basic PAM package to only modules present in unpatched upstream sources, - minus pam_cracklib (packaged separately) - minus pam_pwdb - minus pam_radius ==> /lib/security is cut down to a nice 232KB and contains everything most users will ever need. - get rid of pam_pwdb and pam_stack (breaks some modules) from services in pam.d that use them. - replace pam_console w/ pam_devperm IFF devfs is NOT used, otherwise use neither (plus put in optional ebuild to keep size of '/' small). - move all remaining PAM modules to their own ebuilds. - move non-essential core-utils (see list in my previous comment) to /usr --
We use both pam_cracklib and pam_stack in default setup. If you are that much against pam (and also the setup for a small system/boot disk), add USE='-pam' and build the system.
(no no no) I'm not against PAM at all, I apologise if it sounded like that. All I'm trying to be able to is, after package updates, to create a new rootfs image and write that to the FLASH. Currently that is not possible w/o deleting/ moving around a lot of files because '/' is too big - one reason being PAM - a large number of modules in the single PAM package in Gentoo are never used in typical installations / are considered unsafe and/or broken - so cleaning up the PAM ebuild is a first step in reducing root bloat also. pam_cracklib is a very useful module, but it's not essential for system operation and therefore very optional. pam_stack is not the right way to do things (sorry, maybe I should have made that a separate suggestion) - if you want to include common functionality in a shell script, do you include ('source') an external file providing that functionality, or do you call out to an external program which in turn fires up a subshell in which the external file is sourced? There is a patch floating around (I think it first appeared on the PAM ml - already used in a number of distros) to libpam which adds '@include' to the parser code and acts just like pam_stack, but w/o its several brokennesses. Instead of -- <...> required pam_stack.so service=system-auth -- you can write -- @include system-auth -- What do coreutils people think of the move of non-essential programs to /usr? What is the opinion of PAM maintainers? Thomas, if you're following this - you have Gentoo on your espresso machine and satelite set top box - what's your secret? What about embedded people? --
Right, I did not say you were against it as such, but it is an issue for a small/embedded system. As for pam_stack - I am not sure about your persistance that it is broken? RH and MDK, even Suse I think, with prob most of the RH clones out there use it - why so if it is broken? Sure, I do not deny that initial versions was flaky. Also, out of a distro point of view - even sys admin point of view, pam_stack is the the logical easy way to do things, as changing system-auth reflects on all pam enabled programs making things easier. Yes, I know there are still a few things that I have to fix to use it, but then rather let us do that. I am not against removing things such as pam_pwdb, but out of distro outlook, I do not want to change from pam_stack, or even get things to a state where it might be dubious what configuration of pam there could be. If the user are sure he knows what he is doing, _then_ let him go from the default (should be) secure setup to what he wants. As for weird deps - pam 0.77 should address all lib deps such as glib, etc. they are only needed at build time, but pam links to the static versions of the libs, meaning they can be removed afterwards (or won't matter if /usr is never mounted) ...
Since I'm the "somebody" who listed the `/bin' progs... that was just to show what the absolute minimum may look like. I think it is very difficult and error-prone to start with everything in `/bin' and move unneeded files to `/usr' (you'd have to find all ebuilds that install init scripts, all arches, conflicting ebuilds, check which one needs to run before `/usr' and `/var' are mounted, check dependencies between init scripts, I could go on and on...). [I'm not sure if it's doable, and it may look like more work for more people at first, but...] A better approach in my opinion would be to start with everything but a minimum number of files in `/usr/(s)?bin' and have authors of init scripts send requests to some sort of authority with a detailed description of 1. Which binary needs to be moved to `/'. 2. Why a script has to run without `/usr' available. 3. Why the same functionality can't be implemented using shell builtins and programs already in `/bin'. Another way to save space is to strip sections from executables and shared libraries which are never used/loaded into memory, notibly `.note' and `.comment' (they contain info such as what tool has been used to generate the object file ("GCC: <gcc version string>") and can grow quite huge in executables built from a large number of object files). [This is the reason Debian executables are always smaller (comment #6) Debian, as well as .rpm based systems, do this by default (have a look at `lib/rpm/<some_script_there>' and `dh_strip' in `debhelper') (some versions of rpm check and see if `.comment' is allocated first and only strip it if it is not, however, I'm not sure if there ever could be a reason why `.comment' should be +A or if this was caused by a bug in some short-lived binutils version on a single hardware arch]
re: /usr/bin/mail: the only mta that still installs this is `exim', which it shouldn't (I think there's already a bug open about this) : Exim only acts special if it is called as `mailq', `rmail', `rsmtp', `runq' or `newaliases', but not `mail'. In this case it just prints an error message telling it is not a mua and exits.
Well, as good as this might seem, how about moving progs from *my* list back to /usr/bin which absolutely positively nobody should be using at system init time as a first step, like, csplit, expand, factor, fmt, fold, install, join, m5sum, nl, od, paste, pathchk, pinky, pr, printf, sha1sum, shred, split, sum, tac, tail, test, tsort, unexpand, uniq, users, bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2recover, bzless, bzmore, date, dircolors, gzexe, mail, wall, wc, zcat, zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore, znew ?
*** Bug 36457 has been marked as a duplicate of this bug. ***
could perhaps the kbd package be given an eye over ? seems like some of those binaries require keymaps that are in /usr/share/ ... theres no point to having the binaries in /bin over /usr/bin if they require access to /usr/share to work properly
Better shared object stripping should be going into portage .50_pre11 I'm saving from 1-3k per shared object just changing --strip-debug to --strip-unneeded
coreutils should now install a few things in /usr (from Martin's list)
uniq needs to be in /, it is used by /etc/init.d/checkroot.
pciutils-2.1.11-r1 now installs libpci.a into /usr/lib/
looking at my /lib directory, stuff that could possibly be moved. glibc is the worst offender. we should get nearly 4mb back from it alone. sys-libs/glibc: -rw-r--r-- 1 root root 1362 Jan 5 06:08 /lib/libBrokenLocale_pic.a -rw-r--r-- 1 root root 10832 Jan 5 06:08 /lib/libSegFault_pic.a -rw-r--r-- 1 root root 14696 Jan 5 06:08 /lib/libanl_pic.a -rw-r--r-- 1 root root 3075840 Jan 5 06:08 /lib/libc_pic.a -rw-r--r-- 1 root root 23684 Jan 5 06:08 /lib/libcrypt_pic.a -rw-r--r-- 1 root root 17796 Jan 5 06:08 /lib/libdl_pic.a -rw-r--r-- 1 root root 4936 Jan 18 09:09 /lib/libipq.a -rw-r--r-- 1 root root 43956 Jan 18 09:09 /lib/libiptc.a -rw-r--r-- 1 root root 648078 Jan 5 06:08 /lib/libm_pic.a -rw-r--r-- 1 root root 12220 Jan 5 06:08 /lib/libmemusage_pic.a -rw-r--r-- 1 root root 139186 Jan 5 06:08 /lib/libnsl_pic.a -rw-r--r-- 1 root root 36788 Jan 5 06:08 /lib/libnss_compat_pic.a -rw-r--r-- 1 root root 13454 Jan 5 06:08 /lib/libnss_dns_pic.a -rw-r--r-- 1 root root 57836 Jan 5 06:08 /lib/libnss_files_pic.a -rw-r--r-- 1 root root 20000 Jan 5 06:08 /lib/libnss_hesiod_pic.a -rw-r--r-- 1 root root 56442 Jan 5 06:08 /lib/libnss_nis_pic.a -rw-r--r-- 1 root root 71068 Jan 5 06:08 /lib/libnss_nisplus_pic.a -rw-r--r-- 1 root root 2316 Jan 5 06:08 /lib/libpcprofile_pic.a -rw-r--r-- 1 root root 157298 Jan 5 06:08 /lib/libpthread_pic.a -rw-r--r-- 1 root root 92834 Jan 5 06:08 /lib/libresolv_pic.a -rw-r--r-- 1 root root 62926 Jan 5 06:08 /lib/librt_pic.a -rw-r--r-- 1 root root 63110 Jan 5 06:08 /lib/libthread_db_pic.a -rw-r--r-- 1 root root 10526 Jan 5 06:08 /lib/libutil_pic.a sys-libs/zlib: -rwxr-xr-x 1 root root 75778 Dec 23 03:03 /lib/libz.a sys-libs/libcap: -rw-r--r-- 1 root root 11676 Oct 1 15:41 /lib/libcap.a sys-apps/pciutils: -rw-r--r-- 1 root root 27722 Sep 16 10:51 /lib/libpci.a
Martin Flugeldufel, How are we doing on size now?
way to not read my comment #28 right above yours robbat about pciutils
Re comment #29 Most of that comes from having the USE=pic for glibc which is used by prelink. If these are moved to ${D}/usr will prelinking still function as expected? if [ "`use pic`" ] then find ${S}/${buildtarget}/ -name "soinit.os" -exec cp {} ${D}/lib/soinit.o \; find ${S}/${buildtarget}/ -name "sofini.os" -exec cp {} ${D}/lib/sofini.o \; find ${S}/${buildtarget}/ -name "*_pic.a" -exec cp {} ${D}/lib \; find ${S}/${buildtarget}/ -name "*.map" -exec cp {} ${D}/lib \; for i in ${D}/lib/*.map do mv ${i} ${i%.map}_pic.map done fi
well, the question i've had is, are .a files need to prelink ? i thought the idea behind pic/prelink was to move code around on the fly but .a files are static libs which are linked into binaries themselves ...
Wow, and I thought I got it bad - all those *_pic.a files together need more space then all of /lib and /lib/security together! Anyone know what they're for? Debian has 2 or 3 of them in X11R6 but doesn't say why. On Gentoo I don't have a single one but prelinking still works(?).
does anything more need to be done here?
Yes :) Still way too big and things are already getting worse again ;( Biggest offenders are still coreutils and pam. pam 0.77: pam_console now is linked to static glib and more than doubles in size. pam_cracklib is now linked to static cracklib and is more than 3 times as big. (no real point here bc until /usr is mounted pam is pretty much useless and not really expected to work. It also needs some more files still in /usr. All other dists link dynamically also) Don't even want to talk about pam_radius (6K -> 20K) and pam_pwdb (36K -> 153K) coreutils: How do I put this best... Most of the time I'm against any sort of bureaucracy as it tends to slow things down but coreutils being such a essential package could definately use some more coordiating (not that I think Gentoo is uncoordinated or everything, that's not what I'm saying, it's just that after some root bloat was eliminated, a large amount of programs usually found in /usr/bin are already moving back to /bin in coreutils-5.2.0, trend continuing programs usually found in /usr/bin + possible substitutes: [ in /usr/bin always, built into every bourne compatible shell basename use ${var##*/} chroot no idea what this is doing here (belongs in /usr/sbin) cksum comm not used in bootscripts here cut dunno about this one dircolors no idea why this is here, if /usr is broken there's bigger things to worry about than coloured ls dirname see basename, plus not used in any bootscript here du env expr head hostid id not used in bootscripts here install designed to install software, use mkdir to make directories link logname not used in bootscripts here mkfifo not used in bootscripts here, superceded by mknod nice nohup printenv ptx what are these doing here seq seems to be in newer boot scripts but I was told same thing is do-able w/o it split stat tee tr tty not used in bootscripts here uniq only used like so "sort | uniq" use "sort -u" instead unlink wc who whoami not used in bootscripts here --
Martin, ok, now that you've pointed out specifics, I'll tweak coreutils-5.2.0-r1 to do as you say. The only thing is that install is still used in initscripts, so it will still be in /bin until the scripts are fixed. Note to Azarah: can you use mkdir & cp instead of install then for the next baselayout release?
remove azarah, vapier and myself from the cc list as we're all on base-system (and some of us at least are on embedded as well)
any update on this?
> mkdir & cp instead of install then for the next baselayout release? where is 'install' used in the baselayout scripts ? i grepped for it and didnt find any matches ... if someone points them out to me, i can fix them i changed the 'uniq' stuff to 'sort -u' ... seemant, can you finish moving the programs listed to /usr/bin ? i just looked at my coreutils-5.2.1-r2 and many of those are still in /bin
ping any update on this. is the root partition still really bad?
need info. Please provide current size and suggestion for improvement.
