[DRE-maint] Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

[Maximilian Stein]

Package: gitlab
Version: 13.9.6+ds1-1~fto10+1
Severity: important

Dear Maintainer,

unfortunately, I have repeatedly issues when upgrading gitlab to a new
version. My system is basically as recommended in the Debian Wiki with
Buster as basis plus Backports and Fasttrack. However, I am often
running in a situation that packages are actually *too new* and Gitlab
fails configuring because it expects a certain version of a package in
its Gemfile.

E.g., to upgrade to Gitlab version 13.9.6+ds1-1~fto10+1 today, I
iteratively *downgraded* ruby packages, re-run the Gitlab
installation, which then failed because another package was too new,
and so on. Finally, for 13.9.6+ds1-1~fto10+1, I needed to downgrade
these packages:

* ruby-autoprefixer-rails=10.2.4.0+dfsg1+~cs14.2.17-1
* ruby-devise-two-factor=3.1.0-2~bpo10+1
* ruby-fog-google=1.12.1-1~fto10+1
* ruby-discordrb-webhooks=3.3.0-1
* ruby-ruby-magic-static=0.3.5-1
* ruby-gitlab-labkit=0.15.0-1~fto10+2
* ruby-batch-loader=1.4.1+dfsg.1-3
* ruby-gitlab-experiment=0.4.9-1~fto10+1
* ruby-lockbox=0.3.5-2~bpo10+1
* ruby-rotp=2.1.1+dfsg-1

Of course, I need to hold them all, since they'd be upgraded
automatically otherwise.

One solution I could think of would be to provide a dependency-package
with hard version requirements. So, in contrast to
gitlab-apt-pin-preferences, such a package would directly depend on
all Gitlab-dependencies in their correct version for a particular
version of Gitlab. That way, I'd only need to pin a single package and
get a reproducible working installation. What do you think about that?

Best,
Maximilian