[ATrpms-users] Conflict between fedora and atrpms version of lm_sensors

[Jeffrey J. Kosowsky]

Axel Thimm wrote at about 18:28:21 +0200 on Tuesday, December 18, 2007:
 > On Mon, Dec 17, 2007 at 03:18:33PM -0500, Jeffrey J. Kosowsky wrote:
 > > Axel Thimm wrote at about 21:20:46 +0200 on Sunday, December 16, 2007:
 > >  > On Sun, Dec 16, 2007 at 04:43:06AM -0500, Jeffrey J. Kosowsky wrote:
 > >  > > While I use atrpms for a lot of extras not found in fedora proper,
 > >  > > I prefer to stick with the fedora version when atrpms has a parallel
 > >  > > version of an existing rpm.
 > >  > > 
 > >  > > An example is lm_sensors and sensord.
 > >  > > However, with the fedora version of lm_sensors
 > >  > > (lm_sensors-2.10.5-1.fc8.i386.rpm) and sensord
 > >  > > (lm_sensors-sensord-2.10.5-1.fc8.i386.rpm) installed, I get the
 > >  > > following error when running 'yum update':
 > >  > > 
 > >  > > Error: Missing Dependency: lm_sensors = 2.10.5-52.fc8 is needed by
 > >  > > package sensord
 > >  > 
 > >  > Probably a side-effect (bug) of the protectbase plugin or similar. If
 > >  > some filtering decides to remove something from the pool of available
 > >  > packages it should do so with the depending on it packages as well. If
 > >  > this si not done you get the bug you observe.
 > >  > 
 > >  > Not that even a perfect implementation of a filtering mechanism (like
 > >  > smart has) would really solve partial/selective enabling of repos. But
 > >  > that's another story.
 > >  > 
 > >  > > The problem seems to be that yum is trying to upgrade me to the atrpms
 > >  > > version of lm_sensors and sensord. Probably, compounding this is that
 > >  > > fedora calls the sensord package "lm_sensors-sensord" while atrpms
 > >  > > calls it "sensord".
 > >  > > 
 > >  > > So, basically, I have the following three questions:
 > >  > > 1. How do I get yum to allow upgrades of lm_sensors when the upgrade
 > >  > >    comes from the same repo as the original (i.e., fedora) but not if it
 > >  > >    comes from a different repo (e.g., atrpms)?
 > >  > > 
 > >  > > 2. Why does atrpms have a different name for the essentially
 > >  > >    equivalent sensord package from what fedora now calls it?
 > >  > 
 > >  > Because ATrpms has been shipping sensord since more than 5 years and
 > >  > the Fedora maintainer only did so some few days or weeks ago w/o
 > >  > checking for existing implementations. :(
 > >  > 
 > >  > > 3. What is causing the specific error and how do I prevent it? (other
 > >  > >    than manually uninstalling lm_sensors/lm_sensors-sensord and then
 > >  > >    installing the atrpms version?
 > >  > 
 > >  > I'd file a bug against bugzilla.redhat.com. The maintainer is not
 > >  > forced to use any given conventions (although that would had been
 > >  > nice), but at least he/she could Provide/Obsolete the sensord package
 > >  > in a versioned way to avoind a choking yum.
 > > 
 > > I filed the bug as you suggested and have had several exchanges with
 > > the maintainer (which I hope you have been copied on).
 > 
 > Actually I haven't noticed yet, as my bugzilla mbox is quite piled up,
 > but I'll check.
 > 
 > > I have discovered that this is (unfortunately) complicated by
 > > "political" issue between Fedora and ATrpms philosophies regarding
 > > naming conventions, numbering conventions, and the pros/cons of
 > > duplicating fedora system rpms functionality.
 > 
 > Ahem, I think this looks a bit off-topic. Turning this into a
 > political issue is bad.
 > 
 > > The bottom line though seems to be that the ATrpms sensord has a line
 > > in its spec file OBSOLETING lm_sensors-sensord which IMHO is not
 > > playing nicely.
 > 
 > OK, let me check ...
 > 
 > ATrpms has been shipping lm_sensors with sensord since 2002. Until
 > 2.8.0-1_13 the subpackage was named lm_sensors-sensord. Beginning with
 > 2.8.0-1_14 (Aug 7th 2003) it dropped the prefix on users' or upstream
 > request, I can't remember (I'm only reading through my "VCS"). As a
 > consequence there was a *versioned* Obsolete since.
 > 
 > So there is no "not playing nicely" is the Obsoletes is 4.5 years
 > older than the to be obsoleted package. :)
 > 
 > > The net effect of this line seems to be that anyone who wants to use
 > > sensord functionality and has the ATrpms repo enabled is more-or-less
 > > forced to either use the ATrpms version or manually "exclude" sensord
 > > every time yum is run.
 > > 
 > > So in terms of the principle of "first do no harm", it would seem that
 > > the fairest approach would be to remove the line 
 > > "Obsoletes: lm_sensors-sensord" from the sensord spec file."
 > > 
 > > Of course, I am equally open to other suggestions but it seems like
 > > the Fedora maintainer feels pretty strongly that this is an ATrpms
 > > issue to fix.
 > 
 > I think the maintainer may have misunderstood the history behind the
 > Obsoletes: line which was an ATrpms internal compatibility
 > thing. Still it was even chosen versioned in case some else ever wants
 > to reintroduce it, so newer versions will not be obsoleted.
 > 
 > The sane thing to do (in general) is to have a "new" package entering
 > the field to check for existing implementations and obsolete them in a
 > versioned way in order to keep the dependencies and (sub)package
 > structure proper in every scenario, e.g. the Fedora maintainer could
 > add something like
 > 
 > Obsoletes: sensord <= %{version}-%{release}
 > 
 > Still this is not a political issue, at least not from ATrpms' side.
 > -- 
 > Axel.Thimm at ATrpms.net
 > 
 > [GNUPG:] ERRSIG 401552D4639A99F1 17 2 01 1197995295 9
 > [GNUPG:] NO_PUBKEY 401552D4639A99F1

Axel,
What I meant by "political issue" is that the Fedora maintainer is
adamant about this being an ATrpm problem/issue while you would like
it to be solved by having the Fedora maintainer introduce an Obsoletes
line that he refuses.

The bottom line is still that as things stand (irrespective of
who-came-first), your sensord package is obsoleting a current Fedora
core package. So even though you may be right in principle, I think it
is a BAD thing for a 3rd party repository to muck up a legitimately
installed package from the current Fedora release. You can imagine
many innocent users being tricked up and confused by this.

I would think that the best thing to do would be to go back to the
lm_sensors-sensord naming convention for long-term consistency.

Barring that, it would seem that your Obsoletes line is probably no
longer even necessary since it is rather unlikely that someone would
upgrade a 4.5 year old system and run into obsolescence issues. 

If you still want the Obsoletes line, couldn't you change the line to:
   Obsoletes: lm_sensors-sensord <= [version number from 4.5 years ago]

This should work fine since you haven't released any new version of
lm_sensors-sensord in 4.5 years while as you rightly mention the
Fedora version of lm_sensors-sensord only started recently -- this way
there will be no collisions!!!!

Thanks