RHEL / CentOS - In need of clarifications on various aspects
Red HatThis forum is for the discussion of Red Hat Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
I am in need of some clarifications regarding Red Hat Enterprise Linux and/or CentOS
Ah, you mean clarification the extensive documentation couldn't provide you with? Alright...
Quote:
Originally Posted by noctilucent
- Are the distributions suitable for command-line centric systems?
Yes.
Quote:
Originally Posted by noctilucent
Do RHEL/CentOS make the assumption that
No. Machines don't make assumptions. Humans do.
Quote:
Originally Posted by noctilucent
to remove P, remove RNotInstalled, keep RAlreadyInstalled, keep RManuallyInstalled?
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
Quote:
Originally Posted by noctilucent
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?
Yes, file hashes are stored for verification purposes.
Ah, you mean clarification the extensive documentation couldn't provide you with? Alright...
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].
Quote:
Originally Posted by unSpawn
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.
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' :-)
Quote:
Originally Posted by unSpawn
Yes, file hashes are stored for verification purposes.
Exactly the kind of thing I was looking for.
Quote:
Originally Posted by unSpawn
And welcome to LQ.
Thank you, unSpawn. And thank you for your time & clarifications.
Last edited by noctilucent; 06-03-2009 at 01:29 PM.
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]?
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.
Last edited by billymayday; 06-03-2009 at 08:37 PM.
Reason: Typos
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.