Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add replacement rule for gazebo11 (classic) to allow overwriting of gz CLI executable #4

Merged
merged 1 commit into from
Jun 21, 2022

Conversation

methylDragon
Copy link
Collaborator

Part of: gazebo-tooling/release-tools#698

This install rule targets gazebo.install file for gazebo11, which installs the gz executable. Using the overwriting rules.

I am unsure if we should have a corresponding line on gazebo11-release to allow Gazebo Classic to be installed on top of the pre-existing (garden) gz executable (overwriting the gz executable then.)

@methylDragon methylDragon changed the title Add replacement rule for gazebo11 to allow overwriting of gz Add replacement rule for gazebo11 (classic) to allow overwriting of gz CLI executable Jun 9, 2022
@@ -22,8 +22,10 @@ Pre-Depends: ${misc:Pre-Depends}
XB-Ruby-Versions: ${ruby:Versions}
Depends: ruby | ruby-interpreter,
${misc:Depends}
Breaks: ignition-tools
Replaces: ignition-tools
Breaks: ignition-tools,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we'd remove the breakage of ignition-tools, that was done just so we could iterate faster while both were still installing ign.

My initial inclination would be to:

  1. User tries to install gz-tools2
  2. If ignition-tools is installed, don't install the ign symlink to gz
  3. If ignition-tools isn't installed, install the symlink - but then if the user tries to install ignition-tools afterwards, it would be nice to remove that symlink and let the user know

Copy link
Collaborator Author

@methylDragon methylDragon Jun 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, I think it'll need a companion set of PRs for ignition-tools and the corresponding release repo

There are some small complications:

  • The flow for deb install is:
    • CMake install() -> file gets put into the CMake install space -> deb packaging takes the install space file and packages it into the debian file according to the .install rules
  • As I understand it, debian package management control gives us the tools to specify that it's ok to overwrite files, but not to fail gracefully if files aren't installed on the CMake side.
    • i.e. Files MUST be installed on the CMake side in order to be packaged in the deb. If they're not and they're specified for inclusion, things break (I guess unless we use a regex match somehow..?)

I think there's a way to achieve what we want, but it'll be a bit janky.

Flow

User tries to install gz-tools2

If ignition-tools is installed, don't install the ign symlink to gz

  • If we don't install() the symlink, we can't put the install directive into the debian package using .install, causing an error.
  • So most likely what I will do, is try to copy paste the ignition-tools ign executable to the ignition-tools2 CMake install space and package that (instead of creating, installing, and packaging the symlink when ignition-tools_FOUND)

If ignition-tools isn't installed, install the symlink

  • This is fine

but then if the user tries to install ignition-tools afterwards, it would be nice to remove that symlink and let the user know

  • This will be achieved by installing the symlink in the ignition-tools2 install space, and overwriting the pre-existing one as specified in the debian control file

Control File Reqs

This will need:

  • Breaks and Replaces directives on control to allow overwriting files for:
    • on ignition-tools: ignition-tools2
    • on ignition-tools2: ignition-tools

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for documenting all this, let's go with the current implementation for now and revisit later.

@chapulina chapulina merged commit fa8f8a2 into main Jun 21, 2022
@chapulina chapulina deleted the ch3/deconflict_gz branch June 21, 2022 17:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants