When i upgrade a kernel on my system, i have to install manually (nothing available as yum update) the kernel module ? At least it is what i need to do with spca5xx-kmdl-2.6.17-1.2157_FC5.i686. Why this is not do by yum update ? Eric
On 7/17/06, Eric Tanguy eric.tanguy@univ-nantes.fr wrote:
When i upgrade a kernel on my system, i have to install manually (nothing available as yum update) the kernel module ? At least it is what i need to do with spca5xx-kmdl-2.6.17-1.2157_FC5.i686. Why this is not do by yum update ? Eric
Have you emailed Axel with this question?
On Mon, Jul 17, 2006 at 11:42:46PM +0200, Eric Tanguy wrote:
When i upgrade a kernel on my system, i have to install manually (nothing available as yum update) the kernel module ? At least it is what i need to do with spca5xx-kmdl-2.6.17-1.2157_FC5.i686. Why this is not do by yum update ?
Because such packages have a two-dimensional evr (one for the kernel and one for the module itself) and neither rpm, nor any higher depsolver supports this (other than apt & lua).
But it's not a real problem, on ATrpms' archives you'll find three-line recipes that effectively do what you want it to do.
On Tue, 2006-07-18 at 03:24 +0200, Axel Thimm wrote:
On Mon, Jul 17, 2006 at 11:42:46PM +0200, Eric Tanguy wrote:
When i upgrade a kernel on my system, i have to install manually (nothing available as yum update) the kernel module ? At least it is what i need to do with spca5xx-kmdl-2.6.17-1.2157_FC5.i686. Why this is not do by yum update ?
Because such packages have a two-dimensional evr (one for the kernel and one for the module itself) and neither rpm, nor any higher depsolver supports this (other than apt & lua).
Funny... Livna doesn't seem to have this problem.
But it's not a real problem, on ATrpms' archives you'll find three-line recipes that effectively do what you want it to do.
Ok... You got some URL's or even some search terms or are we just suppose to spider the archives? I just spent some time on your site (having just gone through this nightmare with the Zaptel lkms package) and I can't find it. I could definitely use a three-line recipe that will update chunks from ATrpms which catch the kernel modules and DON'T attempt to dick with the rest of my system.
Funny... I don't have this problem with Livna and I'm downloading more kernel modules from Livna than ATrpms. And I can't just do a general "update" from ATrpms either since it tries to update half the known universe when everything is already up to date and I've only installed Asterisk/Zaptel and MythTV from ATrpms.
With Livna and Extras enabled, everything on my system is up to date. Enable ATrpms and do an update, and half the time it tells me it wants to update dozens of packages that I never installed from ATrpms in the first place and I don't WANT updated from ATrpms. The rest of the time I get some failure like I see now...
: - several cycles of dependency resolution and transaction checking...
--> Running transaction check --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Finished Dependency Resolution Error: Missing Dependency: ocaml = 3.09.2-1.fc5 is needed by package labltk Error: Missing Dependency: lame = 3.96.1-6.lvn5 is needed by package lame-mp3x
(I'm looking at most of what it wanted to update and I'm coming to the conclusion that ATrpms and Livna have never learned to play nicey nicey in the same sandbox).
None of this stuff was part of anything I ever installed from ATrpms. I have to be real careful and selective about anything I install from that repository. I've been in dependency hell too often after making that mistake and the above is an illustration why.
If I am totally up to date with the other repositories, why in the name of Budda does ATrpm try to update stuff that was never installed from ATrpms in the first place and then dick up the dependencies????
This is all I have installed from ATrpms...
[root@mtking ~]# rpm -qa | grep at$ spandsp-devel-0.0.2-3_pre26.rhfc5.at zaptel-kmdl-2.6.17-1.2157_FC5-1.2.7-16.fc5.at mythtv-0.19-129.rhfc5.at libpri-devel-1.2.3-8.rhfc5.at zaptel-1.2.7-16.fc5.at libpri1-1.2.3-8.rhfc5.at mythtv-backend-0.19-129.rhfc5.at asterisk-1.2.10-26.fc5.at mythtv-frontend-0.19-129.rhfc5.at spandsp-0.0.2-3_pre26.rhfc5.at libpri-1.2.3-8.rhfc5.at asterisk-sounds-1.2.1-7.at mythtv-themes-0.19-128.rhfc5.at zaptel-kmdl-2.6.17-1.2157_FC5xen0-1.2.7-16.fc5.at zaptel-devel-1.2.7-16.fc5.at libmyth-0.19-128.rhfc5.at mythtv-setup-0.19-129.rhfc5.at asterisk-devel-1.2.10-26.fc5.at
Why does it insist on updating anything else? On top of all that, it didn't even properly update one of the packages (spandsp) based on, what should have been, a dependency from asterisk. I had to go back and manually update that to correct for some problems with the recent Asterisk update.
I need a KYFHO option for yum and ATrpms to only update packages installed from ATrpms and KYFHO any packages which were NOT installed from ATrpms. Maybe one of your "three line scripts" has a qualifier to only update packages from ATrpms that ends with .at$ on the installed system? Now that would be nice.
Mike
Le mardi 18 juillet 2006 à 03:24 +0200, Axel Thimm a écrit :
On Mon, Jul 17, 2006 at 11:42:46PM +0200, Eric Tanguy wrote:
When i upgrade a kernel on my system, i have to install manually (nothing available as yum update) the kernel module ? At least it is what i need to do with spca5xx-kmdl-2.6.17-1.2157_FC5.i686. Why this is not do by yum update ?
Because such packages have a two-dimensional evr (one for the kernel and one for the module itself) and neither rpm, nor any higher depsolver supports this (other than apt & lua).
But it's not a real problem, on ATrpms' archives you'll find three-line recipes that effectively do what you want it to do.
I don't have this problem with kernel module from livna but it does not matter. If there is a recipe to do this, can you please give me a more precise pointer and maybe this recipe need to be somewhere on your website. Eric
On Mon, Jul 17, 2006 at 10:57:28PM -0400, Michael H. Warfield wrote:
On Tue, 2006-07-18 at 03:24 +0200, Axel Thimm wrote:
But it's not a real problem, on ATrpms' archives you'll find three-line recipes that effectively do what you want it to do.
Funny... Livna doesn't seem to have this problem.
Ok... You got some URL's or even some search terms or are we just suppose to spider the archives?
On Tue, Jul 18, 2006 at 09:10:20AM +0200, Eric Tanguy wrote:
I don't have this problem with kernel module from livna but it does not matter. If there is a recipe to do this, can you please give me a more precise pointer and maybe this recipe need to be somewhere on your website. Eric
The issues are with upgrading within a kernel and coinstalling for different kernels. If you merge the two different versions then the system can never know whether the packages are to be coinstalled or replaced and upgraded. *Both* operations are required. ATrpms solves this by requiring one to be done manually. If you merge the versions you either sacrifice upgrades within a kernel line or supporting concurrently installed kernels.
Here is a more elaborate script ripped out of my own anaconda/reinstall system:
kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-(.*)$,\1,'` for kmdl in `rpm -qa *kmdl* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; do for uname_r in $uname_rs; do package=${kmdl}-$uname_r rpm -q $package > /dev/null 2>&1 || echo $package done done | xargs -r smart install -y
It will coinstall kmdls for any newly installed kernel, even an older one.
On Mon, Jul 17, 2006 at 10:57:28PM -0400, Michael H. Warfield wrote:
--> Running transaction check --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Finished Dependency Resolution Error: Missing Dependency: ocaml = 3.09.2-1.fc5 is needed by package labltk Error: Missing Dependency: lame = 3.96.1-6.lvn5 is needed by package lame-mp3x
(I'm looking at most of what it wanted to update and I'm coming to the conclusion that ATrpms and Livna have never learned to play nicey nicey in the same sandbox).
I think this conclusion is wrong. In your example above there isn't any ATrpms package. Also livna and ATrpms are at good terms, even though incompatibilites between different repos may always arise. But even here the maintainers are thinking of better solutions. Still the above example has no ATrpms in it, so it is not from the incompatibilities category.
I've been in dependency hell too often after making that mistake and the above is an illustration why.
You should perhaps try using smart instead of yum. At the very least it will not bail out and you will get a better understanding of which package was trying to block the upgrade process.
If I am totally up to date with the other repositories, why in the name of Budda does ATrpm try to update stuff that was never installed from ATrpms in the first place and then dick up the dependencies????
Sorry, see above, there is nothing from ATrpms trying to install.
Le mardi 18 juillet 2006 à 10:41 +0200, Axel Thimm a écrit :
On Mon, Jul 17, 2006 at 10:57:28PM -0400, Michael H. Warfield wrote:
On Tue, 2006-07-18 at 03:24 +0200, Axel Thimm wrote:
But it's not a real problem, on ATrpms' archives you'll find three-line recipes that effectively do what you want it to do.
Funny... Livna doesn't seem to have this problem.
Ok... You got some URL's or even some search terms or are we just suppose to spider the archives?
On Tue, Jul 18, 2006 at 09:10:20AM +0200, Eric Tanguy wrote:
I don't have this problem with kernel module from livna but it does not matter. If there is a recipe to do this, can you please give me a more precise pointer and maybe this recipe need to be somewhere on your website. Eric
The issues are with upgrading within a kernel and coinstalling for different kernels. If you merge the two different versions then the system can never know whether the packages are to be coinstalled or replaced and upgraded. *Both* operations are required. ATrpms solves this by requiring one to be done manually. If you merge the versions you either sacrifice upgrades within a kernel line or supporting concurrently installed kernels.
Here is a more elaborate script ripped out of my own anaconda/reinstall system:
kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-(.*)$,\1,'` for kmdl in `rpm -qa *kmdl* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; do for uname_r in $uname_rs; do package=${kmdl}-$uname_r rpm -q $package > /dev/null 2>&1 || echo $package done done | xargs -r smart install -y
Ok this script seems to use smart. is it working with yum ? How is this problem handled by livna because it works fine using this repo : the kernel modules are installed and not updated when i install a new kernel and are removed when the kernel is removed. Why the same system is not used on atrpms ?
It will coinstall kmdls for any newly installed kernel, even an older one.
On Mon, Jul 17, 2006 at 10:57:28PM -0400, Michael H. Warfield wrote:
--> Running transaction check --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Finished Dependency Resolution Error: Missing Dependency: ocaml = 3.09.2-1.fc5 is needed by package labltk Error: Missing Dependency: lame = 3.96.1-6.lvn5 is needed by package lame-mp3x
(I'm looking at most of what it wanted to update and I'm coming to the conclusion that ATrpms and Livna have never learned to play nicey nicey in the same sandbox).
I think this conclusion is wrong. In your example above there isn't any ATrpms package. Also livna and ATrpms are at good terms, even though incompatibilites between different repos may always arise. But even here the maintainers are thinking of better solutions. Still the above example has no ATrpms in it, so it is not from the incompatibilities category.
I've been in dependency hell too often after making that mistake and the above is an illustration why.
You should perhaps try using smart instead of yum. At the very least it will not bail out and you will get a better understanding of which package was trying to block the upgrade process.
If I am totally up to date with the other repositories, why in the name of Budda does ATrpm try to update stuff that was never installed from ATrpms in the first place and then dick up the dependencies????
Sorry, see above, there is nothing from ATrpms trying to install.
Eric
On Tue, 2006-07-18 at 10:41 +0200, Axel Thimm wrote:
On Mon, Jul 17, 2006 at 10:57:28PM -0400, Michael H. Warfield wrote:
On Tue, 2006-07-18 at 03:24 +0200, Axel Thimm wrote:
But it's not a real problem, on ATrpms' archives you'll find three-line recipes that effectively do what you want it to do.
Funny... Livna doesn't seem to have this problem.
Ok... You got some URL's or even some search terms or are we just suppose to spider the archives?
On Tue, Jul 18, 2006 at 09:10:20AM +0200, Eric Tanguy wrote:
I don't have this problem with kernel module from livna but it does not matter. If there is a recipe to do this, can you please give me a more precise pointer and maybe this recipe need to be somewhere on your website. Eric
The issues are with upgrading within a kernel and coinstalling for different kernels. If you merge the two different versions then the system can never know whether the packages are to be coinstalled or replaced and upgraded. *Both* operations are required. ATrpms solves this by requiring one to be done manually. If you merge the versions you either sacrifice upgrades within a kernel line or supporting concurrently installed kernels.
Which is exactly what I think I saw with the recent Zaptel release and the conflicts between the kmdl zaptel modules for the 2145 and 2157 kernels. They can't coexexist because of the conflicting requirements for zaptel and it requires manual intervention to clean it up. I've never had that happen with Livna and ntfs or ndiswrapper. Maybe they didn't do what they appeared to do and maybe there would be some operational problems if I dropped back to an earlier kernel, but it routinely installs the new modules and new common code and the current build ends up updated and operational without manual intervention.
Here is a more elaborate script ripped out of my own anaconda/reinstall system:
kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-(.*)$,\1,'` for kmdl in `rpm -qa *kmdl* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; do for uname_r in $uname_rs; do package=${kmdl}-$uname_r rpm -q $package > /dev/null 2>&1 || echo $package done done | xargs -r smart install -y
It will coinstall kmdls for any newly installed kernel, even an older one.
Ok... Very cool! That will definitely come in very handy. Thx!
On Mon, Jul 17, 2006 at 10:57:28PM -0400, Michael H. Warfield wrote:
--> Running transaction check --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Finished Dependency Resolution Error: Missing Dependency: ocaml = 3.09.2-1.fc5 is needed by package labltk Error: Missing Dependency: lame = 3.96.1-6.lvn5 is needed by package lame-mp3x
(I'm looking at most of what it wanted to update and I'm coming to the conclusion that ATrpms and Livna have never learned to play nicey nicey in the same sandbox).
I think this conclusion is wrong. In your example above there isn't any ATrpms package. Also livna and ATrpms are at good terms, even though incompatibilites between different repos may always arise. But even here the maintainers are thinking of better solutions. Still the above example has no ATrpms in it, so it is not from the incompatibilities category.
Ok... I didn't want to post the "full" example because it's pretty big. So, I freshened things up a bit to make sure all packages are correctly up to date and reran. Forgive the length.
First is a simple run with yum update
[root@mtking ~]# yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories livna [1/4] updates [2/4] core [3/4] extras [4/4] Reading repository metadata in from local files No Packages marked for Update/Obsoletion
You will noticed that there are only 4 repos. Livna, Updates, Core, and Extras.
Now... I'll simply enable ATrpms and nothing else and rerun that same update (all the packages from ATrpms I have installed on this system are up to date, so this should, in theory, result in the same thing)...
[root@mtking ~]# yum --enablerepo=atrpms update Loading "installonlyn" plugin Setting up Update Process Setting up repositories atrpms [1/5] livna [2/5] updates [3/5] core [4/5] extras [5/5] Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package lm_sensors.i386 0:2.10.0-43.rhfc5.at set to be updated ---> Package libsndfile.i386 0:1.0.16-8.fc5.at set to be updated ---> Package libmad.i386 0:0.15.1b-2.rhfc5.at set to be updated ---> Package lame.i386 0:3.96.1-10.rhfc5.at set to be updated ---> Package libmyth.i386 0:0.19-129.rhfc5.at set to be updated ---> Package libgcrypt.i386 0:1.2.2-12.fc5.at set to be updated ---> Package mplayerplug-in.i386 0:3.25-28.rhfc5.at set to be updated ---> Package clamav.i386 0:0.88.3-19.rhfc5.at set to be updated ---> Package mplayer-fonts.noarch 4:1.0-6.at set to be updated ---> Package xvidcore.i386 0:1.1.0-8.rhfc5.at set to be updated ---> Package libmad-devel.i386 0:0.15.1b-2.rhfc5.at set to be updated ---> Package ffmpeg.i386 0:0.4.9-14_cvs20060301.rhfc5.at set to be updated ---> Package xml-common.noarch 0:0.6.3-17_11.at set to be updated ---> Package pm-utils.i386 0:0.15-1.4cubbi_suspend2 set to be updated ---> Package ocaml.i386 1:3.09.2-14.rhfc5.at set to be updated ---> Package sgml-common.noarch 0:0.6.3-17_11.at set to be updated ---> Package mplayer.i386 4:1.0-54_pre8.fc5.at set to be updated ---> Package lirc.i386 0:0.8.1-cvs20060628_60.rhfc5.at set to be updated ---> Package directfb.i386 0:0.9.25.1-9.rhfc5.at set to be updated ---> Package mplayer-skins.noarch 4:1.0-pre3_12.at set to be updated ---> Package mythtv-themes.i386 0:0.19-129.rhfc5.at set to be updated ---> Package libgpg-error.i386 0:1.3-0_8.rhfc5.at set to be updated ---> Package spamassassin.i386 0:3.1.3-1_31.rhfc5.at set to be updated ---> Package imlib2.i386 0:1.2.1-5.rhfc5.at set to be updated ---> Package lame-devel.i386 0:3.96.1-10.rhfc5.at set to be updated --> Running transaction check --> Processing Dependency: libsndfile.so.1 for package: libsndfile --> Processing Dependency: perl(IO::Zlib) for package: spamassassin --> Processing Dependency: libavcodec51 = 0.4.9-14_cvs20060301.rhfc5.at for package: ffmpeg --> Processing Dependency: /usr/bin/pyzor for package: spamassassin --> Processing Dependency: libavutil.so.49 for package: ffmpeg --> Processing Dependency: libavcodec.so.51 for package: ffmpeg --> Processing Dependency: libavformat.so.50 for package: ffmpeg --> Processing Dependency: libmad.so.0 for package: audacity --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: libavcodec.so.51 for package: xine-lib --> Processing Dependency: atrpms-perl-module-helper for package: spamassassin --> Processing Dependency: libavutil49 = 0.4.9-14_cvs20060301.rhfc5.at for package: ffmpeg --> Processing Dependency: libpostproc.so.51 for package: xine-lib --> Processing Dependency: libdc1394_control.so.13 for package: ffmpeg --> Processing Dependency: perl(Mail::SPF::Query) for package: spamassassin --> Processing Dependency: liblirc_client.so.0 for package: mplayer --> Processing Dependency: libgcrypt.so.11 for package: NetworkManager --> Processing Dependency: liblirc_client.so.0 for package: lirc --> Processing Dependency: libdirect-0.9.so.25 for package: mplayer --> Processing Dependency: perl(Mail::DomainKeys) for package: spamassassin --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: libsndfile --> Processing Dependency: mplayer-skin-mini for package: mplayerplug-in --> Processing Dependency: libgcrypt.so.11(GCRYPT_1.2) for package: NetworkManager --> Processing Dependency: libsndfile.so.1 for package: audacity --> Processing Dependency: lirc-lib = 0.8.1 for package: lirc --> Processing Dependency: libmad.so.0 for package: mpg321 --> Processing Dependency: libmad0 = 0.15.1b-2.rhfc5.at for package: libmad --> Processing Dependency: libgcrypt.so.11 for package: yelp --> Processing Dependency: libgcrypt.so.11 for package: NetworkManager-gnome --> Processing Dependency: libgcrypt.so.11 for package: libxslt --> Processing Dependency: libfusion-0.9.so.25 for package: directfb --> Processing Dependency: libmad.so.0 for package: mplayer --> Processing Dependency: /usr/bin/dccproc for package: spamassassin --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: libsamplerate --> Processing Dependency: liblirc_client.so.0 for package: xine --> Processing Dependency: libxvidcore.so.4 for package: ffmpeg --> Processing Dependency: libgcrypt.so.11 for package: gnutls --> Processing Dependency: libgcrypt.so.11(GCRYPT_1.2) for package: vino --> Processing Dependency: liblirc_client.so.0 for package: libmyth --> Processing Dependency: libpostproc51 = 0.4.9-14_cvs20060301.rhfc5.at for package: ffmpeg --> Processing Dependency: perl(IO::Socket::SSL) for package: spamassassin --> Processing Dependency: libgcrypt.so.11(GCRYPT_1.2) for package: gnutls --> Processing Dependency: perl(Archive::Tar) for package: spamassassin --> Processing Dependency: libsndfile.so.1(libsndfile.so.1.0) for package: audacity --> Processing Dependency: libxvidcore4 = 1.1.0-8.rhfc5.at for package: xvidcore --> Processing Dependency: libmad.so.0 for package: madplay --> Processing Dependency: libmad0 = 0.15.1b-2.rhfc5.at for package: libmad-devel --> Processing Dependency: libdirect-0.9.so.25 for package: directfb --> Processing Dependency: libgcrypt.so.11(GCRYPT_1.2) for package: libxslt --> Processing Dependency: libfusion-0.9.so.25 for package: mplayer --> Processing Dependency: libxvidcore.so.4 for package: mplayer --> Processing Dependency: libgcrypt.so.11 for package: vino --> Processing Dependency: perl(Razor2::Client::Version) >= 2.61 for package: spamassassin --> Processing Dependency: libavformat50 = 0.4.9-14_cvs20060301.rhfc5.at for package: ffmpeg --> Processing Dependency: libsndfile.so.1 for package: libsamplerate --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package libpostproc51.i386 0:0.4.9-14_cvs20060301.rhfc5.at set to be updated ---> Package mplayer-skin-mini.noarch 4:0.1-11.1.at set to be updated ---> Package DCC.i386 0:1.3.37-14.rhfc5.at set to be updated ---> Package libavformat50.i386 0:0.4.9-14_cvs20060301.rhfc5.at set to be updated ---> Package libavcodec51.i386 0:0.4.9-14_cvs20060301.rhfc5.at set to be updated ---> Package libdc1394_control13.i386 0:1.1.0-5.rhfc5.at set to be updated ---> Package libavutil49.i386 0:0.4.9-14_cvs20060301.rhfc5.at set to be updated ---> Package razor-agents.i386 0:2.82-14.rhfc5.at set to be updated ---> Package libfusion-0.9_25.i386 0:0.9.25.1-9.rhfc5.at set to be updated ---> Package pyzor.noarch 0:0.4.0-9.fc4 set to be updated ---> Package perl-Mail-SPF-Query.noarch 0:1.999.1-1.fc5 set to be updated ---> Package atrpms.noarch 0:67-1.at set to be updated ---> Package lirc-lib.i386 0:0.8.1-cvs20060628_60.rhfc5.at set to be updated ---> Package libgcrypt11.i386 0:1.2.2-12.fc5.at set to be updated ---> Package perl-IO-Socket-SSL.noarch 0:0.97-5.fc5.at set to be updated ---> Package perl-Mail-DomainKeys.noarch 0:0.21-2.fc5.at set to be updated ---> Package libdirect-0.9_25.i386 0:0.9.25.1-9.rhfc5.at set to be updated ---> Package libsndfile1.i386 0:1.0.16-8.fc5.at set to be updated ---> Package libmad0.i386 0:0.15.1b-2.rhfc5.at set to be updated ---> Package perl-Archive-Tar.noarch 0:1.29-1 set to be updated ---> Package perl-IO-Zlib.noarch 0:1.04-4.2 set to be updated ---> Package libxvidcore4.i386 0:1.1.0-8.rhfc5.at set to be updated --> Running transaction check --> Processing Dependency: perl(Mail::Address) for package: perl-Mail-DomainKeys --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: perl(Net::CIDR::Lite) >= 0.15 for package: perl-Mail-SPF-Query --> Processing Dependency: perl(Net::CIDR::Lite) for package: perl-Mail-SPF-Query --> Processing Dependency: perl(Crypt::OpenSSL::RSA) for package: perl-Mail-DomainKeys --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package perl-Crypt-OpenSSL-RSA.i386 0:0.22-3.fc5.at set to be updated ---> Package perl-Net-CIDR-Lite.noarch 0:0.20-1.fc5 set to be updated ---> Package perl-MailTools.noarch 0:1.74-1.fc5 set to be updated --> Running transaction check --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: perl(Date::Parse) for package: perl-MailTools --> Processing Dependency: perl(Crypt::OpenSSL::Bignum) for package: perl-Crypt-OpenSSL-RSA --> Processing Dependency: perl(Date::Format) for package: perl-MailTools --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package perl-Crypt-OpenSSL-Bignum.i386 0:0.03-3.fc5.at set to be updated ---> Package perl-TimeDate.noarch 1:1.16-3.2 set to be updated --> Running transaction check --> Processing Dependency: ocaml = 3.09.2-1.fc5 for package: labltk --> Processing Dependency: lame = 3.96.1-6.lvn5 for package: lame-mp3x --> Finished Dependency Resolution Error: Missing Dependency: ocaml = 3.09.2-1.fc5 is needed by package labltk Error: Missing Dependency: lame = 3.96.1-6.lvn5 is needed by package lame-mp3x
Ok... The only difference is that I enabled ATrpms. I don't know what it's trying to install, but the list at the very beginning is NOT very encouraging. It looks like it's trying to update a bunch of sound and multimedia packages that I think originally came from Livna (hence my earlier comment about Livna and ATrpms not cooperating)! None of those packages that are selected to be "updated" to a .at rpm came from ATrpms originally.
This is all I have installed from ATrpms:
[root@mtking ~]# rpm -qa | grep '.at$' spandsp-devel-0.0.2-3_pre26.rhfc5.at zaptel-kmdl-2.6.17-1.2157_FC5-1.2.7-16.fc5.at mythtv-0.19-129.rhfc5.at libpri-devel-1.2.3-8.rhfc5.at zaptel-1.2.7-16.fc5.at libpri1-1.2.3-8.rhfc5.at mythtv-backend-0.19-129.rhfc5.at asterisk-1.2.10-26.fc5.at mythtv-frontend-0.19-129.rhfc5.at spandsp-0.0.2-3_pre26.rhfc5.at libpri-1.2.3-8.rhfc5.at asterisk-sounds-1.2.1-7.at mythtv-themes-0.19-128.rhfc5.at zaptel-kmdl-2.6.17-1.2157_FC5xen0-1.2.7-16.fc5.at zaptel-devel-1.2.7-16.fc5.at libmyth-0.19-128.rhfc5.at mythtv-setup-0.19-129.rhfc5.at asterisk-devel-1.2.10-26.fc5.at
None of that shows up in the original "to be updated" pile before the first transaction check.
I've been in dependency hell too often after making that mistake and the above is an illustration why.
You should perhaps try using smart instead of yum. At the very least it will not bail out and you will get a better understanding of which package was trying to block the upgrade process.
I'll give smart a look.
If I am totally up to date with the other repositories, why in the name of Budda does ATrpm try to update stuff that was never installed from ATrpms in the first place and then dick up the dependencies????
Sorry, see above, there is nothing from ATrpms trying to install.
Then what's with that second yum update? What's it trying to do? Sorry I didn't include more of the update output in the earlier message. The first part of the update is much clearer on what it's trying to do and would have answered that question.
Regards, Mike
Michael H. Warfield wrote:
Ok... I didn't want to post the "full" example because it's pretty big. So, I freshened things up a bit to make sure all packages are correctly up to date and reran. Forgive the length.
First is a simple run with yum update
[root@mtking ~]# yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories livna [1/4] updates [2/4] core [3/4] extras [4/4] Reading repository metadata in from local files No Packages marked for Update/Obsoletion
You will noticed that there are only 4 repos. Livna, Updates, Core, and Extras.
Now... I'll simply enable ATrpms and nothing else and rerun that same update (all the packages from ATrpms I have installed on this system are up to date, so this should, in theory, result in the same thing)...
[root@mtking ~]# yum --enablerepo=atrpms update Loading "installonlyn" plugin Setting up Update Process Setting up repositories atrpms [1/5] livna [2/5] updates [3/5] core [4/5] extras [5/5] Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package lm_sensors.i386 0:2.10.0-43.rhfc5.at set to be updated ---> Package libsndfile.i386 0:1.0.16-8.fc5.at set to be updated
(lots of output snipped)
Ok... The only difference is that I enabled ATrpms. I don't know what it's trying to install, but the list at the very beginning is NOT very encouraging. It looks like it's trying to update a bunch of sound and multimedia packages that I think originally came from Livna (hence my earlier comment about Livna and ATrpms not cooperating)! None of those packages that are selected to be "updated" to a .at rpm came from ATrpms originally.
This is all I have installed from ATrpms:
[root@mtking ~]# rpm -qa | grep '.at$' spandsp-devel-0.0.2-3_pre26.rhfc5.at zaptel-kmdl-2.6.17-1.2157_FC5-1.2.7-16.fc5.at mythtv-0.19-129.rhfc5.at libpri-devel-1.2.3-8.rhfc5.at zaptel-1.2.7-16.fc5.at libpri1-1.2.3-8.rhfc5.at mythtv-backend-0.19-129.rhfc5.at asterisk-1.2.10-26.fc5.at mythtv-frontend-0.19-129.rhfc5.at spandsp-0.0.2-3_pre26.rhfc5.at libpri-1.2.3-8.rhfc5.at asterisk-sounds-1.2.1-7.at mythtv-themes-0.19-128.rhfc5.at zaptel-kmdl-2.6.17-1.2157_FC5xen0-1.2.7-16.fc5.at zaptel-devel-1.2.7-16.fc5.at libmyth-0.19-128.rhfc5.at mythtv-setup-0.19-129.rhfc5.at asterisk-devel-1.2.10-26.fc5.at
None of that shows up in the original "to be updated" pile before the first transaction check.
Neither yum nor rpm know which packages you want to get from which repo unless you explictly tell them. The big list of packages you get are packages (or their dependencies) that you already have on your system (from some repo other than ATrpms) that have "later" versions in ATrpms. Since you told yum that you wanted to update all of the packages on your system to the latest versions, and to get packages from ATrpms, it tried to do what it was told and you got the big list.
If you don't want that to happen, you could use an "includepkgs" entry in your ATrpms repo file to list only those packages you want to pull from ATrpms.
Paul.
On Tue, 2006-07-18 at 14:41 +0100, Paul Howarth wrote:
Neither yum nor rpm know which packages you want to get from which repo unless you explictly tell them. The big list of packages you get are packages (or their dependencies) that you already have on your system (from some repo other than ATrpms) that have "later" versions in ATrpms. Since you told yum that you wanted to update all of the packages on your system to the latest versions, and to get packages from ATrpms, it tried to do what it was told and you got the big list.
Yes, and agreed and understood. But also one that lead smack into a critical dependency failure that killed the update cold. A dependency failure that only occurs when ATrpms is included.
If you don't want that to happen, you could use an "includepkgs" entry in your ATrpms repo file to list only those packages you want to pull from ATrpms.
Does that allow for "wildcarding". IOW, can I do an includepkgs for zaptel-kmdl-*_FC5xen0-*.fc5.at ? If not, that's not going to work for the kmdl packages because that versioning is included in the package names (which doesn't work for updates anyways, which we've already established).
Definitely sounds like I do need to use the includepkgs option. I hadn't thought of that one before. That will definitely help cut down on the random acts of terrorism, even if it doesn't solve the kernel modules problems.
That's the second chunk of good advice, along with Axel's script, I've gotten out of this thread. Excellent. Many thanks.
Paul.
Mike
Michael H. Warfield wrote:
On Tue, 2006-07-18 at 14:41 +0100, Paul Howarth wrote:
Neither yum nor rpm know which packages you want to get from which repo unless you explictly tell them. The big list of packages you get are packages (or their dependencies) that you already have on your system (from some repo other than ATrpms) that have "later" versions in ATrpms. Since you told yum that you wanted to update all of the packages on your system to the latest versions, and to get packages from ATrpms, it tried to do what it was told and you got the big list.
Yes, and agreed and understood. But also one that lead smack into a critical dependency failure that killed the update cold. A dependency failure that only occurs when ATrpms is included.
To be fair, this could happen when any two repos are used that have packages with the same names (or having the same "Provides" as far as RPM is concerned). It's not specific to ATrpms.
If you don't want that to happen, you could use an "includepkgs" entry in your ATrpms repo file to list only those packages you want to pull from ATrpms.
Does that allow for "wildcarding". IOW, can I do an includepkgs for zaptel-kmdl-*_FC5xen0-*.fc5.at ? If not, that's not going to work for the kmdl packages because that versioning is included in the package names (which doesn't work for updates anyways, which we've already established).
I know the "excludepkgs" option supports some glob-style wildcards so I'd guess that "includepkgs" did too. Not sure how good the wildcard support is though, e.g. if it handles "*" in the middle of a name. Try it and see :-)
Paul.
On Tue, 2006-07-18 at 15:35 +0100, Paul Howarth wrote:
Does that allow for "wildcarding". IOW, can I do an includepkgs for zaptel-kmdl-*_FC5xen0-*.fc5.at ? If not, that's not going to work for the kmdl packages because that versioning is included in the package names (which doesn't work for updates anyways, which we've already established).
I know the "excludepkgs" option supports some glob-style wildcards so I'd guess that "includepkgs" did too. Not sure how good the wildcard support is though, e.g. if it handles "*" in the middle of a name. Try it and see :-)
Actually, looks like zaptel-* is sufficient and I don't need it in the middle of a name (which should work, IAC, now that I've read the documentation - RTFM...) so I'm covered.
Seems to work just fine. Your's wins the prize at the best advice. That seems to have solved a lot of problems as long as I don't run a foul of a dependency like asterisk and spandsp that I did a couple of days ago (broke Asterisk when Spandsp wasn't updated but that wasn't this problem). But it looks like it's got all my bases covered now.
Many thanks!
Paul.
Mike
On Tue, Jul 18, 2006 at 01:59:34PM +0200, Eric Tanguy wrote:
kernels=`rpm -qf /boot/vmlinuz-* | grep -v "^file .* is not owned by any package"` uname_rs=`rpm -ql $kernels | grep ^/boot/vmlinuz- | sed -e's,^/boot/vmlinuz-(.*)$,\1,'` for kmdl in `rpm -qa *kmdl* | sed -e's,-kmdl-.*,-kmdl,' | sort -u`; do for uname_r in $uname_rs; do package=${kmdl}-$uname_r rpm -q $package > /dev/null 2>&1 || echo $package done done | xargs -r smart install -y
Ok this script seems to use smart. is it working with yum ?
Yes, I think "smart install -y" -> "yum -y install" is the only change needed. And for apt it would be "apt-get -y install".
How is this problem handled by livna because it works fine using this repo : the kernel modules are installed and not updated
It's known that there are issues with this scheme, or any scheme that will merge module and kernel versions.
rpm for one can't cope with it. Suppose you have two active kernels (say 2.6.16 and 2.6.17 or xen0 and non-xen0 etc.) and already have foo-kmdl for both in version 1. Now foo-kmdl in version 2 is released. Both rpm -i (coinstall, no replacement of of foo-kmdl for the same kernel) and rpm -U (remove all foo-kmdl but the highest one, e.g. at least one kernel stay w/o any kmdl) won't work.
yum/smart/apt can be tought to be more clever than rpm and try to do the proper thing, which they will only be able to do if the merged versions are distangled again, e.g. hidden in Provides: and the like.
So in order for a merged-version scheme to work there is special handling neccessary (and for atrpms' system, too, but read on). I prefer to have rpm itself already do something sensible and since it can only upgrade one versioning system (e.g. either the kernel's or the module's) it's preferable to allow it to upgrade the module within the same kernel and not touch the cross-kernel boundaries. "No harm done" like accidentially removing kmdls for other kernels or coinstalling several kmdls for the same kernel. You "only" need to reinstall the missing kmdl upon each kernel upgrade.
It's far easier to get this into the brains of yum/smart/apt (e.g. translate the 9 lines of bash above into plugings/hooks for these depsolvers) or simply use the 9liner above than have a scheme which is broken at the level of rpm.
Incidentially one on my personal targets is to get thie discussed in the fedora packaging group and review the currently scheme. Of course, I'm proposing adoption of ATrpms' kmdl scheme :)
http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
when i install a new kernel and are removed when the kernel is removed.
How the dependencies to the kernel are installed (which is responsible for having an automatic removal on kernel removal) is a different story, which the version merging does not break. The issue is with the system (system=rpm and(or any higher depsolver tool, e.g. yum/smart/apt) being able to distinguish different foo-kmdls as _upgrades_ vs _coinstalls_.
On Tue, Jul 18, 2006 at 09:22:57AM -0400, Michael H. Warfield wrote:
On Tue, 2006-07-18 at 10:41 +0200, Axel Thimm wrote:
The issues are with upgrading within a kernel and coinstalling for different kernels. If you merge the two different versions then the system can never know whether the packages are to be coinstalled or replaced and upgraded. *Both* operations are required. ATrpms solves this by requiring one to be done manually. If you merge the versions you either sacrifice upgrades within a kernel line or supporting concurrently installed kernels.
Which is exactly what I think I saw with the recent Zaptel release and the conflicts between the kmdl zaptel modules for the 2145 and 2157 kernels. They can't coexexist because of the conflicting requirements for zaptel and it requires manual intervention to clean it up.
Well, you did sent me a bug report in private which showed that your system had several rpm inconsistencies like asterisk not finding spansp libs although the packaging dependencies are in place, and since you didn't reply to my diagnosis I can only assume that it's a local problem on your system. kmdls are in the field for several years and their "drawback" is that they don't interact cross-kernel wise, so it's unlikely that installing zaptel-kmdl for a new kernel would be blocked by the old kmdls. There is (was) something else amiss on your system.
zaptel packages are also very well consumed, so if it really were an issue it would bring in a second report by now.
(I'm looking at most of what it wanted to update and I'm coming to the conclusion that ATrpms and Livna have never learned to play nicey nicey in the same sandbox).
I think this conclusion is wrong. In your example above there isn't any ATrpms package. Also livna and ATrpms are at good terms, even though incompatibilites between different repos may always arise. But even here the maintainers are thinking of better solutions. Still the above example has no ATrpms in it, so it is not from the incompatibilities category.
Ok... I didn't want to post the "full" example because it's pretty big. So, I freshened things up a bit to make sure all packages are correctly up to date and reran. Forgive the length. [... very big output ...]
I've been in dependency hell too often after making that mistake and the above is an illustration why.
You should perhaps try using smart instead of yum. At the very least it will not bail out and you will get a better understanding of which package was trying to block the upgrade process.
I'll give smart a look.
Please give that first a try before we diagnose a possible yum failure over several mails focusing on the wrong bits.
Also have a check on your rpm database. the zaptel and asterisk to spandsp dependencies seem to have failed on your system, if the rpm database is corrupted we may be hunting ghosts.
rpm -V package
is your friend and
rpm --rebuilddb
will try to fix the database, but corner the issue first to that by for instance hunting down the asterisk/spandsp/ldd issue.
On Tue, Jul 18, 2006 at 03:35:28PM +0100, Paul Howarth wrote:
Michael H. Warfield wrote:
On Tue, 2006-07-18 at 14:41 +0100, Paul Howarth wrote:
Neither yum nor rpm know which packages you want to get from which repo unless you explictly tell them. The big list of packages you get are packages (or their dependencies) that you already have on your system (from some repo other than ATrpms) that have "later" versions in ATrpms. Since you told yum that you wanted to update all of the packages on your system to the latest versions, and to get packages from ATrpms, it tried to do what it was told and you got the big list.
Yes, and agreed and understood. But also one that lead smack into a critical dependency failure that killed the update cold. A dependency failure that only occurs when ATrpms is included.
To be fair, this could happen when any two repos are used that have packages with the same names (or having the same "Provides" as far as RPM is concerned). It's not specific to ATrpms.
To me it really looks like a yum bug. Especially when ocaml is verbosely set to be updated to some version and suddenly ocaml at the end is said to be not available.
So my recommendation (to Michael) is: (after making sure that your system is not having a brokeeeen rpm database) try using smart and see what this will suggest to do. It should at least offer a better result than bailing out.
smart at ATrpms and the atrpms-package-config and medley-package-config contain livna smart channels, but also a bit more, so if you use that you will have to deactivate some repo to really test the only livna&atrpms activated setup. Or you can install smart from extras and add livna&atrpms channels to it.
On Tue, 2006-07-18 at 19:07 +0200, Axel Thimm wrote:
On Tue, Jul 18, 2006 at 03:35:28PM +0100, Paul Howarth wrote:
Michael H. Warfield wrote:
On Tue, 2006-07-18 at 14:41 +0100, Paul Howarth wrote:
Neither yum nor rpm know which packages you want to get from which repo unless you explictly tell them. The big list of packages you get are packages (or their dependencies) that you already have on your system (from some repo other than ATrpms) that have "later" versions in ATrpms. Since you told yum that you wanted to update all of the packages on your system to the latest versions, and to get packages from ATrpms, it tried to do what it was told and you got the big list.
Yes, and agreed and understood. But also one that lead smack into a critical dependency failure that killed the update cold. A dependency failure that only occurs when ATrpms is included.
To be fair, this could happen when any two repos are used that have packages with the same names (or having the same "Provides" as far as RPM is concerned). It's not specific to ATrpms.
To me it really looks like a yum bug. Especially when ocaml is verbosely set to be updated to some version and suddenly ocaml at the end is said to be not available.
Interesting. Yup... Got it. It's not with ocaml per se. It's with a package, labltk, that depends on the installed version of ocaml that is flagged to be updated.
So my recommendation (to Michael) is: (after making sure that your system is not having a brokeeeen rpm database) try using smart and see what this will suggest to do. It should at least offer a better result than bailing out.
Nope. Just check and rpm -V comes back clean for all the ATrpm packages installed (and others I checked) beyond some device file permissions and some permissions on asterisk-sounds. Running --rebuilddbm has no effect either.
smart at ATrpms and the atrpms-package-config and medley-package-config contain livna smart channels, but also a bit more, so if you use that you will have to deactivate some repo to really test the only livna&atrpms activated setup. Or you can install smart from extras and add livna&atrpms channels to it.
Yeah, well...
Running smart seem to nail it. Smart wanted to just remove a couple of packages that were blowing the dependency errors.
The problem seem to be that ATrpms wants to upgrade ocaml and that conflicts with an explicit labltk dependency match from extras. It also wants to upgrade lame which conflicts with a lame-mp3x dependency from Livna. In each case, yum doesn't know (can't figure out) that it needs to remove those two packages (should it?) but smart has labltk and lame-mp3x marked for removal. That would appear to be the source of the conflict. Manually running "yum erase labltk lame-mp3x" also takes out lablgl, also from extras, (which smart also marked for removal) but nothing else. Once I do that, then "yum update" no longer blows a hissy fit about a dependency problem and claims it wants to install 35 packages and update 34 (none of which I wanted to do - I'll just drop back to the other excellent suggestion of restricting ATrpms to only those packages I explicitly want from ATrpms). So smart figures out that those three packages need to be removed but yum doesn't and then complains because some of their dependencies are being invalidated. That nails down the immediate source of the dependency errors. Is that a bug in yum, or is it a bug in the "obsoletes" with some of the other packages, or is it in a too strict dependency in those other packages, or none of the above? I have no idea what those three packages do and nothing seems to depend on them, so removing them seems perfectly reasonable. They also only show up on the one system where I have Asterisk and MythTV, which are the only things I install from ATrpms. Strange... I wonder why they got installed on that system in the first place.
I wonder if smart would have done better with the kmdl modules for zaptel as well. No way of knowing now, since the manual upgrade on that succeeded and I've got no way to fall back and retest that package.
Oh well... Got several interesting toys (thank you for that script) out of this and a couple of approaches to managing things better plus explanations for the errors I was seeing. Much good. Many thanks.
Mike
On Mon, Jul 17, 2006 at 11:42:46PM +0200, Eric Tanguy wrote:
When i upgrade a kernel on my system, i have to install manually (nothing available as yum update) the kernel module ? At least it is what i need to do with spca5xx-kmdl-2.6.17-1.2157_FC5.i686. Why this is not do by yum update ?
Update: There is now a yum plugin that takes care of that as part of an ongoing process to get kmdls into Fedora proper:
o Whenever a new kernel is yum-installed it checks whether kmdls for that kernel already exist.
Since there is always a <= 1 day delay between the kernel package release and the kmdls shipped from ATrpms (I don't get any early access, so I learn about new kernels just like everyone else when they hit the main repos) chances are that upon installation of a new kernel kmdls will not yet be available, so there is another async mode:
o whenever a yum update is issued the plugin checks whether any kernel is missing kmdls that now appeared in some repo.
The necessity upon which kmdls to install is derived from installed kmdls in the system. E.g. if an old kernel had a kmdl for foo installed the plugin will try to get that for newer kernels, too. It would be nicer to have this configurable, but that left for the next version of the plugin (if there is demand for such a feature at all).
The plugin is currently packaged as yum-plugin-kmdl at ATrpms and was submitted to become part of yum-utils. ATrpms users using atrpms-package-config will get that plugin installed automatically.
Any feedback please to the ATrpms' lists or ATrpms' bugzilla for now, thanks!
-
Axel Thimm -
Eric Tanguy -
Kam Leo -
Michael H. Warfield -
Paul Howarth