From: centos-bounces@centos.org On Behalf Of Rodrigo Barbosa
On Wed, Jan 18, 2006 at 01:26:41PM -0500, Bowie Bailey wrote:
It is stock except for the csgfs packages from the CentOS-csgfs repository and one or two other rpm packages.
"It is stock except" = "not stock". Several packages interact with each other, including the kernel.
I want to keep the machine up to date, but I guess I'll have to be careful with the kernel updates. Any others that could cause problems?
Pretty much any package has dependencies and/or provides something used by others. You will have to do a complete dependency tracking to make certain what your non-stock packages can interact with, which is a very daunting task. Checking provides and requires on the rpmdb is just the first step, and things can get really ugly when the interaction is done using unix sockets or, god forbit, dbus.
I though dependency tracking was what yum and rpms were for? If I installed the cman-kernel package via yum, shouldn't I get a dependency warning if I try to install the new kernel? I know I would get one if I tried to install the current cman-kernel package on top of the new kernel.
I though dependency tracking was what yum and rpms were for? If I installed the cman-kernel package via yum, shouldn't I get a dependency warning if I try to install the new kernel? I know I would get one if I tried to install the current cman-kernel package on top of the new kernel.
You would if you tried to update the kernel (thus removing the old kernel which is a dependency of the cman-kernel packages). However, _normally_ you DO NOT want to upgrade a kernel - you instead install a new one, reboot into it at some time in the future - and only when everything is verified to be working do you uninstall the old one. You often have more than one kernel installed at once (I usually keep a UP kernel, an old verified working SMP kernel, and the newest SMP kernel which is currently being used). Furthermore not every module fits with every kernel so I can't imagine how this could be fixed automatically with the above notes... I guess having some sort of automagical build system in place could possibly work? To be executed at kernel install... But even that would not always be correct.
Cheers, MaZe.
On Thu, 2006-01-19 at 09:59 -0500, Bowie Bailey wrote:
From: centos-bounces@centos.org On Behalf Of Rodrigo Barbosa
On Wed, Jan 18, 2006 at 01:26:41PM -0500, Bowie Bailey wrote:
It is stock except for the csgfs packages from the CentOS-csgfs repository and one or two other rpm packages.
"It is stock except" = "not stock". Several packages interact with each other, including the kernel.
I want to keep the machine up to date, but I guess I'll have to be careful with the kernel updates. Any others that could cause problems?
Pretty much any package has dependencies and/or provides something used by others. You will have to do a complete dependency tracking to make certain what your non-stock packages can interact with, which is a very daunting task. Checking provides and requires on the rpmdb is just the first step, and things can get really ugly when the interaction is done using unix sockets or, god forbit, dbus.
I though dependency tracking was what yum and rpms were for? If I installed the cman-kernel package via yum, shouldn't I get a dependency warning if I try to install the new kernel? I know I would get one if I tried to install the current cman-kernel package on top of the new kernel.
If it were an upgrade/update and not an install ... that might work.
But since nothing is trying to remove the old kernel (just install a new one too), the install requirements remain meet.
IF then booting the new kernel, all hell breaks loose :)
IF booting the old kernel ... still good to go.
Johnny Hughes wrote: <snip>
I though dependency tracking was what yum and rpms were for? If I installed the cman-kernel package via yum, shouldn't I get a dependency warning if I try to install the new kernel? I know I would get one if I tried to install the current cman-kernel package on top of the new kernel.
If it were an upgrade/update and not an install ... that might work.
But since nothing is trying to remove the old kernel (just install a new one too), the install requirements remain meet.
IF then booting the new kernel, all hell breaks loose :)
IF booting the old kernel ... still good to go.
Is there a way to know if the new Kernel will work, in other words have Yum do its dependency checking as if it were an upgrade? My server is remote, so if the new kernel does not boot I am in trouble.
I am a noob (partial Windows convert) so I am not smart (or remember what I did) enough to know if it will work. In that regard, thank goodness for Yum otherwise.
On Thu, 2006-01-19 at 07:55 -0800, John Thomas wrote:
Johnny Hughes wrote:
<snip> >> I though dependency tracking was what yum and rpms were for? If I >> installed the cman-kernel package via yum, shouldn't I get a dependency >> warning if I try to install the new kernel? I know I would get one if I >> tried to install the current cman-kernel package on top of the new >> kernel. >> > If it were an upgrade/update and not an install ... that might work. > > But since nothing is trying to remove the old kernel (just install a new > one too), the install requirements remain meet. > > IF then booting the new kernel, all hell breaks loose :) > > IF booting the old kernel ... still good to go. >
Is there a way to know if the new Kernel will work, in other words have Yum do its dependency checking as if it were an upgrade? My server is remote, so if the new kernel does not boot I am in trouble.
Not that I know of ... short of trying to remove the old kernel (which I don't recommend).
It would be a 3rd party driver for a major item (like the disk driver for the root file system, a NIC driver for the main ethernet card, etc.) where this would be a problem.
Even then, the fix would be have someone select the old kernel on boot up, and boot back to that and build a new driver.
I am a noob (partial Windows convert) so I am not smart (or remember what I did) enough to know if it will work. In that regard, thank goodness for Yum otherwise.
If you have ever updated the kernel before, then it should not be an issue on future updates ... as the non-standard (aka, 3rd party) driver issue is something that would happen every new kernel.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, Jan 19, 2006 at 09:59:18AM -0500, Bowie Bailey wrote:
I though dependency tracking was what yum and rpms were for? If I installed the cman-kernel package via yum, shouldn't I get a dependency warning if I try to install the new kernel? I know I would get one if I tried to install the current cman-kernel package on top of the new kernel.
That is a common misconception. I mean, yes, rpm does dependency checking, but the dependency problem is greater than that.
You see, think about licq (ICQ client). It doesn't depend on dbus to work. But it CAN use dbus. So, if you are using that feature, and change dbus, you will get no dependency link, and licq can still break.
The issue is a little different regarding kernel. You can have several different kernels installed. If you module depend on a given kernel version, and that version is installed, you will have no dependency problem. But if you boot using a different kernel, your module won't work.
Best Regards,
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-
Bowie Bailey -
John Thomas -
Johnny Hughes -
Maciej Żenczykowski -
Rodrigo Barbosa