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?

[nmburgan]

Unless anyone feels strongly, let's remove the versioning. I think let's also remove provides. For now, you could mix, say, puppetserver and openvox-agent (puppetserver/puppetdb require puppet-agent), but this may not always be the case and we wouldn't want to set up the package metadata to do that.

[tskirvin]

Done.

[nmburgan]

Sorry, I just realized this is set on the Puppet component. This probably still works because Vanagon seems to let you put it wherever, but it probably belongs at the project level (configs/projects/openvox-agent.rb, using proj.replaces and proj.conflicts) since it's metadata on the whole package itself.

I tested this on Debian 12, and it seems to work as expected. If you try to install openvox-agent when puppet-agent is already installed, it uninstalls puppet-agent and installs openvox-agent, and vice versa.

[nmburgan]

Could you also open a PR to apply this to the 7.x branch as well?

[tskirvin]

I've pushed your requested change for this branch first; I can make a PR against 7.x if this works the way we expect?