Project

General

Profile

Actions

Bug #7777

closed

Rudder-agent provides rudder-agent without a version

Added by Janos Mattyasovszky about 8 years ago. Updated almost 2 years ago.

Status:
Released
Priority:
N/A
Category:
Packaging
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Infrequent - complex configurations | third party integrations
Effort required:
Priority:
73
Name check:
Fix check:
Regression:

Description

Currently there is a problem, that the rudder-agent rpm is not updated on SLES to the latest version by 'zypper up rudder-agent', even if available in the repository. (Fails on SLES11 SP1, works on SP2 and SP3)

Consulted SUSE, and apparently it is not good to provide the package name without a version by hand:

1) The packages self provides without version; i.e. 'in any version'

This is a time bomb. The package claims to provide a property which it does not
posses. It does not provide every version of custom-dnsmasq; only one specific.
Though the self-provides without version is obviously wrong, it's impossible to
tell whether the imposture will be detected or leads to trouble.

Even in an update scenario, where the package claims to be able to provide
versions higher than any other, this malformed provides is not the only
constraint. But it bears the risk that the package is elected and later not
able to keep its promise.

2) The way zypper translates the CLI arg 'custom-dnsmasq=2.0-2_g5e58fdc' into a
package.

Zypper looks for a package resolving the requirement
'custom-dnsmasq=2.0-2_g5e58fdc'. All packages proving 'custom-dnsmasq'
unversioned claim to be valid candidates.

The difference between SP1 and SP3 is just the way zypper elects a candidate.
SP3 has faster indices so it exploits the fact that every package provides
'name=version' and
does a quick check for package 'name' and' version' first.

If the quick check would not deliver a hit, SP3 would continue checking the
provides of all packages like SP1 does. SP3 seems to deliver what you expect,
but in fact the quick check just disguises the actual problem.

# rpm -q --provides -p 3.1.5/SLES_11_SP1/x86_64/rudder-agent-3.1.5.release-1.SLES.11.x86_64.rpm
warning: 3.1.5/SLES_11_SP1/x86_64/rudder-agent-3.1.5.release-1.SLES.11.x86_64.rpm: Header V3 RSA/SHA1 signature: NOKEY, key ID 6f07d355
rudder-agent
rudder-cfengine-community
rudder-agent = 1398866025:3.1.5.release-1.SLES.11

This was introduced by #5059, and the idea is also not bad, the problem is, this Provides: tag should be used to provide "virtual" packages, and not one, that actually exists in the repository as an RPM package by the same name...

I'd recommend to change the Provides to something more abstract, like "Rudder(agent)" or Rudder::Agent", otherwise the regular update mechanism will not work (at least on SLES11 SP1)...

Even if fixed, every current RPM installed on SP1, still containing the "Provides: rudder-agent" feature will have to be updated by hand by rpm -Uvh, since zypper will not find the update in this means...


Related issues 4 (0 open4 closed)

Related to Rudder - Bug #5059: rudder-agent rpm is obsoleted by rudder-agent-thin and therefore cannot be installedReleasedJonathan CLARKE2014-06-18Actions
Related to Rudder - Bug #8914: Broken dependencies in 4.0 RPM because of epochReleasedBenoît PECCATTE2016-09-05Actions
Related to Rudder - Bug #3535: RPM packages: upgrades from one major branch to another don't always work because of the Epoch fieldReleasedJonathan CLARKE2013-04-25Actions
Related to Rudder - Bug #14415: Command to upgrade server from old 4.1/4.2/4.3 to 5.0 does not upgrade rudder-agent, breaking everythingReleasedBenoît PECCATTEActions
Actions

Also available in: Atom PDF