Skip to content

Change default downstream packaging suffix to `+apertisX`

Emanuele Aina requested to merge wip/em/change-packaging-suffix into apertis/v2022dev2

We moved from coX to apertisX as the packaging suffix but unfortunately it turned out to interact badly with the build suffix on OBS in some scenarios:

  1. bluez in Debian has the 5.55-3 version
  2. it gets uploaded to OBS with no changes, forgetting to add the apertisX suffix
  3. OBS appends the build suffix, generating binaries with version 5.55-3bv2022dev2b1
  4. we update bluez appending the apertisX suffix, yielding 5.55-3apertis1
  5. OBS appends the build suffix, generating binaries with version 5.55-3apertis1bv2022dev2b1
  6. reprepro gets the new binaries from OBS but the ordering is now wrong since 5.55-3apertis1bv2022dev2b1 < 5.55-3bv2022dev2b1 and will refuse to publish the newly built binaries

Switching to +apertisX has the following advantages:

  • it can be rolled out progressively using the standard workflow
  • no need to change the build suffix
    • no need to rebuild everything on OBS
    • no need to manually delete entries from reprepro
  • backports work correctly, +apertisX sorts newer than coX and the OBS suffixes
  • mixing releases like v2021 and v2022 should not produce surprising effects like v2021 builds sorting newer than v2022

The drawbacks are:

  • every non-Apertis-specific package needs to be tweaked
  • if Debian package maintainer releases a new version by appending a suffix there are higher chances that the +apertisX suffix will sort newer (we already have this issue, but this increases the chances to hit it)

Task: T7906

Merge request reports

Loading