Hi! On Thu, Dec 25, 2003 at 01:29:16AM +0100, Spider wrote: > > Some other software which may be removed from 'system' is: > > 1) gawk - there is a lot of different 'awk' realizations which user > > may want instead of gawk (I prefer 'mawk') > This may not be direct in system, check virtuals/ support ( a list of > packages that provide the same functionality )
Ok, thanks, I will check it.
> > 2) sysklogd - for example, I prefer 'multilog t /var/log/kernel
> > </proc/kmsg' instead of 'klogd', and 'read_syslog' instead of
> > 'syslogd'.
> its not. virtual/logger is. if you don't supply a logger yourself, it
> will use sysklogd because its "default"
Yeah, you right.
> > 3) xfree - I don't know why xfree is in 'system' - I think this is
> > bad idea to have 'xfree' always installed, even on servers.
> USE flag +X +gtk +qt +kde +tcltk may any and all of those bring in
> xfree as a dependency. I'd suggest reading some more on USE flags too
> ;).
Hmm.. So, if I set USE="-X" then xfree will not be compiled by `emerge
system`? As far as I understand USE - it affect only "optional package
dependency", not "packages to install": I can `emerge xfree` with USE="-X"
without prob, but all software with optional XFree support will be
compiled without it.
Ohh, sorry!!! I've just rechecked /etc/make.profile/packages and noticed
what there is no 'star' at line '>=x11-base/xfree-4.1.0-r12', so it
shouldn't be installed by `emerge system` at all, right?
> > 4) dhcpd - it's small, but probably not 'system' because it isn't used
> > at all in many networks
> its a hard package cause there were too many users who forgot to
> install it and ended up with nonworking machines. :)
Ok, let it be there... ;-))
> > 5) debianutils
> Needed for "readlink" , and only that afaik.
Hmm. I think it's simple enough to realize 'readlink' as bash-function
using 'ls -l'... but this isn't really important.
> > 7) bc
> Common unix standard tool, used by a lot of buildscripts.
I don't know such buildscripts... Really:
home root # qpkg --installed --query-deps bc
sys-devel/bc-1.06-r5 *
DEPENDED ON BY:
sys-libs/glibc-2.3.2-r3 *
DEPENDED ON BY:
gcc-3.2.3-r3
but I 100% sure what gcc will compile without 'bc' just because I've
compiled it (many versions from 3.0 to 3.2.3) a lot of times for my
distribution, and I've no 'bc' in my distribution. (I've about 200
packages in my distribution, and no one of them need 'bc'.)
For me, 'bc' is too strange thing, I prefer to use 'expr' from sh-utils
for simple calculations in bash scripts and 'perl' in complex cases.
> > 8) ... and some other utilities, which may or may not be useful, but
> > which are not required, so they shouldn't be in 'system' - user can
> > install 'fbset' or 'bc' or other such utils later at any time...
> System provides a set of decent defaults for a user, making it simple to
> redo.
> if you wish to roll your own profile its dead simple actually, just
> check the /etc/make.profile, move it from a link to a directory and then
> do the changes.. (or simply relink it to another place ;)
I've now checked /etc/make.profile/packages again, and all my questions
about it content disappear: bc, dhcpd, debianutils, etc. is mostly small
harmless things. Only question left is my initial question: do you
really think what PAM support is 100% required for anyone and should be
in 'system'? Is it safe to just unmerge pam and pam-login (I've USE="-pam")?
... From my point of view, PAM is very good idea with very bad realization -
there a number of bugs and security holes found from time to time in PAM,
so it's safer to not use PAM if you don't need some PAM's features.
--
WBR, Alex.
pgp00000.pgp
Description: PGP signature
