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 #1

Updated by Janos Mattyasovszky about 8 years ago

PS: This quote from SUSE came regarding a different RPM, but has the same Problem.

Actions #2

Updated by Jonathan CLARKE about 8 years ago

  • Related to Bug #5059: rudder-agent rpm is obsoleted by rudder-agent-thin and therefore cannot be installed added
Actions #3

Updated by Jonathan CLARKE about 8 years ago

  • Target version set to 2.11.18

That is indeed poor packaging. I don't know how that slipped in, but we should indeed not "provide" the same name as the package itself.

We need both rudder-agent and rudder-agent-thin to "provide" an identical string, so that other packages (rudder-server-root, rudder-server-relay) can depend on it.

Actions #4

Updated by Jonathan CLARKE about 8 years ago

  • Status changed from New to In progress
  • Assignee set to Jonathan CLARKE
Actions #5

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 2.11.18 to 2.11.19
Actions #6

Updated by Janos Mattyasovszky about 8 years ago

This would be a quick win ;-)

Actions #7

Updated by Jonathan CLARKE about 8 years ago

  • Translation missing: en.field_tag_list set to Quick and important

Janos Mattyasovszky wrote:

This would be a quick win ;-)

Oops, apparently I forgot all about this! Thanks for the reminder, Janos.

Actions #8

Updated by Nicolas CHARLES about 8 years ago

  • Translation missing: en.field_tag_list changed from Quick and important to Quick and important, sponsored

This issue is really important

Actions #9

Updated by Janos Mattyasovszky about 8 years ago

  • Pull Request set to https://github.com/Normation/rudder-packages/pull/891
Actions #10

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 2.11.19 to 2.11.20
Actions #11

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 2.11.20 to 2.11.21
Actions #12

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 2.11.21 to 2.11.22
Actions #13

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 2.11.22 to 2.11.23
Actions #14

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 2.11.23 to 2.11.24
Actions #15

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 2.11.24 to 308
Actions #16

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 308 to 3.1.14
Actions #17

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #18

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #19

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #20

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #21

Updated by Nicolas CHARLES about 7 years ago

  • Assignee changed from Jonathan CLARKE to Alexis Mousset

Alexis, you have insight on this one, especially on why it works on some sles and not on others
Could you list here on which versions of SLES it is supposed to work as it is now, and where we need to use something else, so that we can decide of a proper course of action ?

Thank you

Actions #22

Updated by Janos Mattyasovszky about 7 years ago

yaaay, we just had 1 year's anniversary a couple of days ago... Any ideas? I mean, the problem is known, the solution might be pretty easy...

Actions #23

Updated by Florian Heigl about 7 years ago

Yeah, like bump
This just ruined my night.

Had forgotten there was an issue.
What I can recap:
- The epoch is 2014... that seems just totally wrong.
- The epoch is used to compare versions IF RPM was unable to find the version.

So that means the base thing is wrong, and the fallback is wrong, too.

My suggestion would be

1) fix the epoch, it needs to be updated if you bump version. This is not some optional thing to just do when the time is right
2) add this

Obsoletes: %{name} <= %{version}
Provides: %{name} = %{version}

> You can test with any SUSE version except ancient on SUSE Studio
> It's definitely not OK rpm-wise
> I don't think it's really important which versions are more accepting of this
> Best path is to fix it - then it'll be accepted by any version
-> You can offload testing for us, but please in a defined way so we can complete fully cooperate and track / cover cases.

TL;DR
Please, could you deliver packages of Rudder for SLES that can be updated using Rudder, on SLES, using the most basic means of Rudder... :-)

Actions #24

Updated by Florian Heigl about 7 years ago

And yeah, I know. Enterprise distros and their old RPM / libzypp.

But we discussed this internally and due to 3rd party support issues, especially Rudder, and certification issues, especially Oracle and just about everything else in the world, we won't be able to switch to AlpineLinux in Q1, to my big sad disappointment :)

Actions #25

Updated by Vincent MEMBRÉ about 7 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #26

Updated by Alexis Mousset about 7 years ago

  • Status changed from In progress to New
Actions #27

Updated by Jonathan CLARKE almost 7 years ago

  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Operational - other Techniques | Technique editor | Rudder settings
Actions #28

Updated by Benoît PECCATTE almost 7 years ago

  • Priority set to 51
Actions #29

Updated by Vincent MEMBRÉ almost 7 years ago

  • Target version changed from 3.1.19 to 3.1.20
Actions #30

Updated by Jonathan CLARKE almost 7 years ago

  • Assignee deleted (Alexis Mousset)
Actions #31

Updated by Vincent MEMBRÉ almost 7 years ago

  • Target version changed from 3.1.20 to 3.1.21
Actions #32

Updated by Benoît PECCATTE almost 7 years ago

  • Translation missing: en.field_tag_list changed from Quick and important, Sponsored to Sponsored
Actions #33

Updated by Vincent MEMBRÉ almost 7 years ago

  • Target version changed from 3.1.21 to 3.1.22
Actions #34

Updated by Benoît PECCATTE over 6 years ago

  • Priority changed from 51 to 64
Actions #35

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.22 to 3.1.23
Actions #36

Updated by François ARMAND over 6 years ago

  • Related to Bug #8914: Broken dependencies in 4.0 RPM because of epoch added
Actions #37

Updated by François ARMAND over 6 years ago

  • Related to Bug #3535: RPM packages: upgrades from one major branch to another don't always work because of the Epoch field added
Actions #38

Updated by Janos Mattyasovszky over 6 years ago

Please note, that the line

Provides: %{name} = %{version}

is automatically included by the rpmbuild process. You can check it with rpm -q --provides -p <rpm_package_name> for any RPM you have built.

Actions #39

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.23 to 3.1.24
Actions #40

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.24 to 3.1.25
Actions #41

Updated by François ARMAND over 6 years ago

  • User visibility changed from Operational - other Techniques | Technique editor | Rudder settings to Infrequent - complex configurations | third party integrations
  • Priority changed from 64 to 55

After more test&try, it was found that the problem only happen when rudder-agent is part of a zypper "pattern" and is used like that:
(say we have a rudder agent 4.1.6 installed):

This will find the newer version:

zypper install rudder-agent=4.1.7

But that won't:

zypper install --type=pattern Rudder-Server=4.1.7

Actions #42

Updated by Vincent MEMBRÉ over 6 years ago

  • Target version changed from 3.1.25 to 387
  • Priority changed from 55 to 61
Actions #43

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 387 to 4.1.10
Actions #44

Updated by Vincent MEMBRÉ about 6 years ago

  • Target version changed from 4.1.10 to 4.1.11
Actions #45

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 4.1.11 to 4.1.12
Actions #46

Updated by Vincent MEMBRÉ almost 6 years ago

  • Target version changed from 4.1.12 to 4.1.13
Actions #47

Updated by Alexis Mousset over 5 years ago

I think I just reproduced the problem:

zypper install rudder-agent=4.56.3
Loading repository data...
Reading installed packages...
'rudder-agent=4.56.3' not found in package names. Trying capabilities.
Resolving package dependencies...

The following NEW package is going to be installed:
  rudder-agent 

The problem is that the capabilities resolution ignores other parameters if a capability matches the name of the required package.

Actions #48

Updated by Alexis Mousset over 5 years ago

  • Status changed from New to In progress
  • Assignee set to Alexis Mousset

I'm taking over this issue!

Actions #49

Updated by Alexis Mousset over 5 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Alexis Mousset to Jonathan CLARKE
Actions #50

Updated by Alexis Mousset over 5 years ago

  • Status changed from Pending technical review to In progress
  • Assignee changed from Jonathan CLARKE to Alexis Mousset
  • Pull Request changed from https://github.com/Normation/rudder-packages/pull/891 to https://github.com/Normation/rudder-packages/pull/1607
Actions #51

Updated by Alexis Mousset over 5 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Alexis Mousset to Jonathan CLARKE
Actions #52

Updated by Alexis Mousset over 5 years ago

  • Status changed from Pending technical review to Pending release
Actions #53

Updated by Janos Mattyasovszky over 5 years ago

I suggest you keep an eye on this, as adding a Provides line with the same version that's added by rpmbuild itself is... well... something worth to have a look on :-)

Actions #54

Updated by Vincent MEMBRÉ over 5 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 4.1.13, 4.2.7 and 4.3.3 which were released today.

Actions #55

Updated by Alexis Mousset about 5 years ago

  • Related to Bug #14415: Command to upgrade server from old 4.1/4.2/4.3 to 5.0 does not upgrade rudder-agent, breaking everything added
Actions #56

Updated by Alexis Mousset almost 2 years ago

  • Priority changed from 61 to 73
Actions

Also available in: Atom PDF