puppet.rb - trying to add Replaces:, Conflicts:, and Provides: to spe…

[tskirvin]

…c file

[binford2k]

From @evgeni

[10:46:22] but with all my RPM-based hats on: you usually do not want to do non-versioned obsoletes
[10:47:13] one often does Obsoletes: <oldname> < %{version}-%{release} so that you end up with openvox-agent-8.1.1-1 having an "Obsoletes: puppet-agent < 8.1.1-1"
[10:47:26] whether this is correct in this case, no idea

[tskirvin]

Fair. But not knowing vanagon well enough, and knowing that the same vanagon config is being used to build a variety of versions of openvox-agent, how do you get it to obsolete <= the current version being built?

[silug]

From @evgeni

[10:46:22] but with all my RPM-based hats on: you usually do not want to do non-versioned obsoletes
[10:47:13] one often does Obsoletes: <oldname> < %{version}-%{release} so that you end up with openvox-agent-8.1.1-1 having an "Obsoletes: puppet-agent < 8.1.1-1"
[10:47:26] whether this is correct in this case, no idea

Documentation on the topic: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

[stahnma]

Agree that you should use versioned obsoletes, but if you're using replaces does it matter?

[nmburgan]

I think you can pass the version as a second argument
https://github.com/OpenVoxProject/vanagon/blob/f5aff30dad07fe374f133b1d9d94122af7d5913c/lib/vanagon/component/dsl.rb#L139-L163
pkg.replaces 'puppet-agent', '< 8.1.1'

[tskirvin]

I am dubious that I have the syntax right, but:

pkg.replaces 'puppet-agent', '<' + pkg.version + '-' pkg.release

[binford2k]

We could probably go back in time to see what we did when puppet-agent replaced puppet

[nmburgan]

I think that's the right syntax @tskirvin . But our version/release isn't going to match puppet-agent's. In fact, I wonder if we just leave it as the last official OSP puppet-agent release number. I wonder if Puppet Core ™️ packages will still be called "puppet-agent".

I'm not really familiar with best practices here. Do we need all 3 of these?

[tskirvin]

I think that Replaces and Conflicts are required to get the point across; and Provides may be optional at best. But really I want to get something in place and an rpm built so I can try to iterate through my upgrade process to make sure rpms upgrade properly in place.

I was inclined to not include version numbers here for exactly the reason that @nmburgan states - we don't know for sure what the versions upstream will be long-term.

And as for @binford2k's comment re: doing what puppet-agent vs puppet did, that was a really long time ago and definitely didn't involve vanagon. Otherwise there might well still be artifacts out there in the spec file about that.

[nmburgan]

Yeah. I think in this case, we don't want any puppet package to coexist with openvox packages for now, so I think we can probably leave it unversioned.

[nmburgan]

I will try building this next week and make sure it works like we think. Also want to figure out how to do this with ezbake.

[tskirvin]

Do you want me to bother changing the commit again, or do you want to hack on it for a while and figure out what the actual final state is going to be?