Description of problem: I have lm_sensors and lm_sensors-sensord 2.10.5-1 installed. However, this is causing conflicts with an equivalent but differently named module (sensord) from atrpms that causes yum to crash.\ Specifically, every time I run yum (with ATrpms repo enabled), I get the following error message: Error: Missing Dependency: lm_sensors = 2.10.5-52.fc8 is needed by package sensord I'm not an rpm expert and don't fully understand what is happening here but Axel Thimm (from ATrpms) suggested that one solution might be to "Provide/Obsolete" the sensord package from ATrpms Even better, might be to coordinate with Axel on using a similar naming convention, especially since he has been providing the sensord functionality for a lot longer than Fedora :) Thanks!
Erm, We (Axel versus other Fedora contributers) have been over this a zillion times, atrpms should not replace nor provide core packages! I agree that in the case of sensord this is special as our lm_sensors package did not provide sensorsd, however atrpms should not have build its own lm_sensors base package too, it should have used the one in Fedora. sensorsd can be build fine against the system lm_sensors, and then automatic rpm dependencies on the soname of libsensors would have done the rest. By explicitly requiring lm_sensors = 2.10.5-52.fc8 instead of a soname, a package which was never provided by Fedora proper and one which clearly conflicts with a Fedora proper package, things have been messed up. Combine this with the atrpms release field inflation (atrpms is AFAIK the only one not to reset the release field when a new version gets released) and I cannot do something like: Provides: sensord = %{version}-%{release} Obsoletes: sensord < %{version}-%{release} As atrpms' %{version}-%{release} > Fedora's %{version}-%{release}, I could use an unversioned Obsoletes, buts just plain wrong, as that completely clobbers the namespace. Or I could hardcode the version to Obsolete, which is slightly better but still ugly. So that leaves me with the choice of adding ugliness to work around a problem in an unsupported 3th party repo, or not to fix this bug, I'm choosing not to fix this bug atm, but I'm open for further discussion. As a workaround, a simpel "rpm -e sensord lm_sensors-sensord", followed by a "yum install lm_sensors-sensord" should fix this.
I'm trying to stay away from the politics and just get my system working properly. But unfortunately, the workaround you suggest (which I had tried before) didn't work. When I try: yum install lm_sensors-sensord, after removing lm_sensors-sensord (note sensord was already no longer installed) I still get: Resolving Dependencies --> Running transaction check ---> Package sensord.i386 0:2.10.5-52.fc8 set to be updated --> Processing Dependency: lm_sensors = 2.10.5-52.fc8 for package: sensord --> Finished Dependency Resolution Error: Missing Dependency: lm_sensors = 2.10.5-52.fc8 is needed by package sensord I also tried rebuilding the rpm database (rm /var/lib/rpm/__db.00[1-3] ; rpm -vv --rebuilddb) but that didn't help either. I even tried removin lm_sensors itself. So, I'm not really sure what is going on here and why. The only way I can get lm_sensors-sensord to install now is to add "disablerepo ATrpms". So, again putting the politics and blame aside, from the user perspective this is still broken since unless each time I disable the entire ATrpms repo or exclude "lm_sensors*", I am unable to use yum at all!!
Resolving Dependencies --> Running transaction check ---> Package sensord.i386 0:2.10.5-52.fc8 set to be updated ^^^ The big question is why does it say this if you do not have sensord installed, are you sure you do not have sensord installed? Perhaps the sensord package from atrpms obsoletes lm_sensors-sensord? Ah, yes it does, see: http://dl.atrpms.net/all/lm_sensors.spec So the question then becomes why yum doesn't update lm_sensors itself to lm_sensors-2.10.5-52.fc8, as that clearly has a higher evr then the main Fedora lm_sensors, and one can still wonder why atrpm feels the need to override the perfectly fine Fedora proper lm_sensors package at all. Either way its an atrpms problem, not a Fedora one.
Yes I'm sure I don't have sensord installed but I did before (I think). I agree that this seems like an atrpms problem and I will follow up with Axel. However, in the meantime, what can I DO to "unobsolete" lm_sensors-sensord or is there nothing that can be done until the spec is changed/fixed by atrpms?
Just to clarify, short of Axel agreeing to remove the Obsoletes line from the sensord spec, do I have any alternatives other than to always run yum with the option "--exclude sensord"? (assuming that I still want to use ATrpms for other rpms)
(In reply to comment #5) > Just to clarify, short of Axel agreeing to remove the Obsoletes line from the > sensord spec, do I have any alternatives other than to always run yum with the > option "--exclude sensord"? (assuming that I still want to use ATrpms for other > rpms) Well, not only does atrpm' sensord obsoletes Fedora's lm_sensors-sensord, but atrpms lm_sensors (base) package has an evr which is higher then Fedora's lm_sensors (base) package, so if you do yum update with atrpms repo enabled you should get both lm_sensors and sensord from atrpms and thus no broken deps, so there are 3 possibilities: 1 atrpms repodata is busted and for some reason does not contain info on atrpms base lm_sensors package 2 yum is busted and not behaving as it should 3 You've some non standard yum plugin installed (protect base for example) causing this behaviour
And the answer is..... #3 (I had forgotten about that -- in fact, now that I recall, I specifically installed yum-protectbase several years ago just to "protect" me from such situations :) Of course protectbase would also have helped me with sensord except for the fact that fedora and atrpms use DIFFERENT names for the rpm :(
Sounds like a protectbase bug to me, it should protect the base from updates through obsoletes too, go file a bug there. I would close this one, but its already closed :)
Yes - you are right. Protectbase should prevent an rpm from another repo obsoleting one from a protected repo. I will file a bugzilla report under yum.
Just for the record and to remove the blame from ATrpms: o ATrpms started shipping lm_sensors 5 years ago in a time where the lm_sensors package in Fedora (or its predecessor) was far from being up to date (not blaming anyone, RHL was more like RHEL than Fedora) o sensord was being shipped for almost as long o at the beginning it was named lm_sensors-sensord o mid 2003 the name was changed to sensord upon external request o the Obsoletes: is 4 years older than the package that entered Fedora So there is no aggressive Obsolete politics in ATrpms against a current Fedora package, and the fact that protectbase is more broken than functional as it doesn't take any dependent packages into its dependency calculation into account is also not ATrpms' fault. Furthermore the lack of support in RHEL/RHL/Fedora world made lm_sensors and support by ATrpms quite popular (and even today RHEL5 users report that they need to switch to ATrpms' version), even as much that lm-sensors.org itself is hosted by ATrpms! Just as a counterargument to "3rd party repos replacing old and stale base packages is bad". The situation has improved in Fedora a lot (not only concerning lm_sensors), but that doesn't mean that we should stampede on anything else, call 3rd party repos unsupported and ignore what users may have installed on their system the past 5 years and today. Also if it is ugly to provide a Provides/Obsoletes against an external package to keep compatibility and proper dependency relationships, then it is even uglier to build different src.rpms out of the same tarball as suggested in having sensord build on lm_sensors-devel from a different src.rpm (and maybe differently patched etc.) Last but not least the "inflation" of release tags is something the core Fedora package provided until recently itself: the kernel rpm. It is easier for me to check history and change rate of the specfile that way. Just liek the kernel did with the RCS revision number. I'd like to close that irrespective of any technical details I don't find it fair that sometimes people just need to see a 3rd party repo, or maybe ATrpms more specifically, and blindly start pushing the blame. Given the history of lm_sensors and ATrpms one would at least expect that even an ATrpms hater would check to see what conventions exist and how to smoothly apply any changes for users of ATrpms' version to any other - maybe even contact the packae maintainer of the affected package and coordinate/sync such changes. Instead there are no compatibility hooks anywhere and once ATrpms is mentioned the bug is closed with less than nice words for your friendly third party repo ;) Anyway no hard feelings and let's not off-topicalize this bugzilla report even more. I just replied to the lot of blaming done here as I was being Cc'd and therefore perhaps someone expected some reply.