RHEL / CentOS - In need of clarifications on various aspects
 

Hello.

I am in need of some clarifications regarding Red Hat Enterprise Linux and/or CentOS:

- Are the distributions suitable for command-line centric systems? Details: the machines are not servers but will rather be used either as development | "desktop" boxes. By looking at (least at) Fedora it would seem that there is a strong focus on GUI components. Do RHEL/CentOS make the assumption that non-server users will generally be operating from behind a graphical interface [and act in accordance to this assumption]? I am used to configuring the various tools I use by editing their.. configuration files [having first read the respective manpages, if needed]. Some machines are 100% command line [I insist: they are not used as servers] - we are talking 80x25 terminals.

- Assuming we install package P which requires R1 and R2. After a period of time T, we decide we no longer want P. Is there a way to instruct the package manager to "remove P and any of its requirements which are not needed by any other program, nor that were manually installed" [remove "leaf requirements" / "orphaned requirements" / etc. if you will]. Further attempt at an explanation:

Package P needs RNotInstalled, RAlreadyNeeded and RManuallyInstalled. RNotInstalled is not currently installed. RAlreadyNeeded is already installed because it is needed by another package currently installed on the system. RManuallyInstalled is installed because the administrator manually instructed the package manager to install it.

The installation of package P will thus also install package RNotInstalled. After time T [no other modifications have been made to the installed packages set], we decide to remove P -> can the package manager be "easily instructed" to remove P, remove RNotInstalled, keep RAlreadyInstalled, keep RManuallyInstalled?

If the package manager can not do this by default, do 3rd party tools/extensions exist that accomplish this particular task?

- Does the package management system allow the administrator to easily detect which configuration files [for example, stored in /etc] have been "modified", meaning: are currently different from the defaults shipped by Red Hat Enterprise Linux / CentOS?

Ah, you mean clarification the extensive documentation couldn't provide you with? Alright...


Yes.


No. Machines don't make assumptions. Humans do.


Packages are either known to the database (installed) or not. All installed packages are checked for dependencies. So a package being "installed manually" is not a valid criterium since the method (yum, rpm, autoupdate, rpm --justdb) doesn't matter (as long as it interfaces with RPMDB) so expecting a package management system to keep the package based on that makes no sense. So, yes, 'yum remove P' will keep "RAlreadyInstalled" if it is required by other packages and will remove "RManuallyInstalled" if it is not required by other packages. If at this point you get "outraged" or "astonished" things don't work as you think they should work you're free to supply upstream with the necessary patches ;-p


Yes, file hashes are stored for verification purposes.

And welcome to LQ.

Indeed. I appologise for being lazy in this.

By "installed manually" I meant a package which was explicitly installed by the system administrator via the package management system [I did not mean: installed via configure->make->etc.]. I was trying to make a distinction from those installed packages which are "installed automatically" [because they are required as dependencies].


That is what I wanted to know, the answer satisfies me. Because of this, at this point I am not outraged nor astonished and will happily not supply any patches to 'upstream' :-)

Exactly the kind of thing I was looking for.

Thank you, unSpawn. And thank you for your time & clarifications.

Forgot to address this one:

I see. Well then, since RHEL/CentOS are incapable of making assumptions [or perhaps are unwilling, it is not clear from your post], do the RHEL/CentOS developers make the assumption that non-server users will generally be operating from behind a graphical interface [and act in accordance to this assumption]?

It's not a question of making assumptions, hand-holding or willingness. I'd say the whole GUI thing is just perception: if you had used say Fedora only in CLI-only mode you wouldn't know any better. Like most GNU/Linux distributions you can install, configure and use whatever userland toolkit configuration you like. For me running a CLI install of base only, adding required packages, tending to the little collateral left and configuring by hand doesn't take much time.

I think in answer to one of your earlier questions, the package manager won't remove installed dependencies.

So for example, if "yum install P1" also installs P2, "yum remove P1" will only remove P1. "yum remove P2" will remove both P1 and P2 since P1 requires P2. Note that if P1 requires P2 and P3, removing P2 will leave P3 on the system, but still remove P1.

Where I've installed a package plus dependencies and no longer require a package, I simple pick the installed packages from the log and uninstall them all. This is usually pretty straightforward since I tend to do this pretty soon after the fact, but would be rather more problematic 6 months later.

Does it really matter that much if you have orphan packages on the system? It's potentially a bit of a minefield, since there may be co-dependencies (ie dependencies required by other packages), so you can't simply remove all dependencies necessarily.

Yeah, you're absolutely right, I should have checked that more carefully.

Thank you, billymayday. Yes, it matters quite much.

Then I suspect that you would need to run "yum deplist <package>" and manually remove any dependencies that are not required by other packages.

So in the example I gave earlier, "yum deplist P1" would list P2 and P3. You could then use "yum remove P2", and only select "yes" if nothing outside of the deplist or parent (ie P1 or P3) would be removed with it.