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

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20071218/95371e38/attachment.bin