comps' "standard" group spring cleaning?

[Bill Nottingham]

(mashing together a few replies. Sorry about the delay.)

Michael Scherer (misc at zarb.org) said: 
> Le vendredi 11 janvier 2013 à 08:05 -0600, Chris Adams a écrit :
> > Once upon a time, Bill Nottingham <notting at redhat.com> said:
> > >
> > > -      <packagereq>ed</packagereq>
> > 
> > I don't know how widely it is used, but ed is also part of POSIX/SUS.
> 
> based on my understanding, POSIX do not mandate them to be there by
> default, just to support them :
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html
> 
> so not installing them by default will not change much, given that we
> already do not support several command :
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html
...

> A separate group would be better because :
> - this is easier to audit ( especially if the norm is updated )
> - this doesn't force to install a compiler by default ( fort77 )

Things like ed & bc are required by redhat-lsb-core. (You can repoquery
it for its full list). Would it be worth it to just list that, and not
worry about the smaller things? Biggest size downfall to this is that
it drags cups into the system. :/


Chris Adams (cmadams at hiwaay.net) said: 
> > -      <packagereq>ftp</packagereq>
> 
> Either ftp or lftp should still be in the standard install (command line
> FTP is sometimes essential, especially when trying to add to a minimal
> install).  lftp is bigger than ftp (because lftp does more, such as sftp
> and http).

If you're adding to an install, and you already have curl, rsync, and sftp,
how much do you need an interactive ftp client itself?

> > -      <packagereq>btrfs-progs</packagereq>
> > 
> > Will be installed by anaconda if you install on btrfs; can move
> > to @core if it becomes the default FS.
> 
> There are several common things that you list as installed by anaconda
> if needed; that can give you problems if you install in one system or
> setup and then move the drive, add other drives, etc.

Sure, but I would assume that if you're doing that, you know what you're
doing.

> > -      <packagereq>lftp</packagereq>
> > 
> > Removed; ftp is in legacy-unix.
> 
> If legacy-unix is not part of standard install, that is a poor
> justification ("we removed one FTP client, so better remove the other as
> well").

The idea is that if the functionality is provided elsewhere, all uses
of it should go there; splitting the functionality between groups doesn't
make much sense.

> I guess my comments get back to: is there a defined goal, other than
> "remove things Bill doesn't use" (not trying to pick on you Bill, but
> you did make this list)?  Are we trying to shrink the installed disk
> footprint (none of the these are very big)?  Does removing these reduce
> install time significantly?

This came up in the bugzilla ticket as well, and it's probably a better
place to start.

So, first principles of the group, IMO:

'Standard' would be 'tools and utilities you expect to be on a standard
Linux install, but that aren't needed in a minimal install'. It's included
in every non-minimal install. (In general, that means all the desktops;
people who install servers usually start at minimal and work their way up.)

This then brings up the following discussion points:

* bc, ed, talk, etc.

Should we just list redhat-lsb-core?

* ftp vs lftp, info vs pinfo, traceroute vs mtr

If we're talking about a 'standard' group of things that people would expect
to be there, then perhaps we drop all the newer, "better" version of things.
Sure, people still can install and use pinfo or mtr. But is that the
standard that people expect to be there every time? 

* ftp, finger, etc.

Are these things that are still expected in a 'standard' Linux install?

Bill