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.