Bug #6885


[Deployment] Add meaningful package versions to distro packages

Added by Brett Smith over 8 years ago. Updated over 7 years ago.

Assigned To:
Target version:
Story points:


As we improve our deployment infrastructure, it's happening more and more that we make improvements to our packages that don't change the underlying code: more accurate dependencies, changes in support scripts like, etc.

Right now these changes don't trigger a new package build. We always use fpm's default iteration setting of 1, and fpm doesn't rebuild packages when it sees a destination package with the correct software version+iteration already on disk.

We need at least a manual process to be able to increment/set the iteration. Engineering to spec a solution.

Actions #1

Updated by Brett Smith over 8 years ago

  • Subject changed from [Deployment] Add meaningful package verisons to distro packages to [Deployment] Add meaningful package versions to distro packages
Actions #2

Updated by Brett Smith over 8 years ago

Current expected solution: arvados-dev includes a configuration file that includes triples of (source package name, source version, package version). Whenever builds source package name+package version, it should set the increment to package version. For any other build, it should not set the increment, or set it to 1 (the default).

Actions #3

Updated by Brett Smith over 8 years ago

  • Description updated (diff)

The mechanism recently added to arvados-dev gives us another channel to do this. For packages with source outside the Arvados tree, you can have the corresponding say:

fpm_args+=(--iteration 2)

You could also do this with our own Arvados packages… except, of course, that will bump the software version as well. So maybe we want to use empty commits as our package rebuild trigger?

Actions #4

Updated by Brett Smith over 8 years ago

  • Story points set to 1.0

Empty commits don't work to trigger new package builds for our own packages, since they look for commits that affect the specific component. So we still need an out of band mechanism to specify package iterations for those.

We're still agreed on the concept of maintaining a file of triples with package name, source version, and package iteration. Do that.

Actions #5

Updated by Brett Smith over 8 years ago

  • Target version changed from Arvados Future Sprints to Kanban
Actions #6

Updated by Ward Vandewege over 7 years ago

  • Status changed from New to Resolved
  • Assigned To set to Ward Vandewege
  • Target version changed from Kanban to 2017-01-18 sprint

This was fixed as part of #10858


Also available in: Atom PDF