Alon and I had an extensive discussion on this recently and we have agreed that despite our mutual reservations, TurnKey (both internally and end users) would be best served by moving to an Omnibus install.
So the next TurnKey GitLab appliance release will switch from the current source install (using MySQL as backend DB) to an Omnibus install (using Postgres - as included in the monolithic Omnibus package).
The change will likely be a pain for existing users, but we should be able to leverage the "Export/Import" functionality of GitLab to allow existing users to migrate their data (TKLBAM will not be a realistic option). And moving forward, they should be able to leverage the ease of upgrade that you describe.
Whilst in many respects, the Debian backports package avoids many of the concerns we have, it doesn't eliminate all our concerns. Concerns remaining with that path include no guarantees of timely security updates to backports, we can't use auto security updates for GitLab (and backported dependencies) there either and backports are not part of LTS (so once the Debian base moves to LTS, the only support path is to upgrade/migrate to newer TurnKey). Also, even then, we can't really guarantee what will happen with that in the longer term future. With all that in mind, Omnibus install seems the most sensible.
We did also consider hacking the Omnibus install to allow us to use as many default Debian packages as possible (rather than all the applications bundled within the monolithic Omnibus package). But we decided against that too in the end because of 2 major reasons. Firstly there may be subtle incompatibilities that may not be immediately obvious (but users may encounter). Even if that isn't the case immediately, it may well develop in the future. Plus it may make future upgrades problematic too.
So despite all our reservations (as noted previously) we've agreed that the best of all the unappealing options is a "default" Omnibus install. I'm not sure when that will be ready, but soon I'm hoping.
Update: Next GitLab release will be Omnibus install...
Alon and I had an extensive discussion on this recently and we have agreed that despite our mutual reservations, TurnKey (both internally and end users) would be best served by moving to an Omnibus install.
So the next TurnKey GitLab appliance release will switch from the current source install (using MySQL as backend DB) to an Omnibus install (using Postgres - as included in the monolithic Omnibus package).
The change will likely be a pain for existing users, but we should be able to leverage the "Export/Import" functionality of GitLab to allow existing users to migrate their data (TKLBAM will not be a realistic option). And moving forward, they should be able to leverage the ease of upgrade that you describe.
Whilst in many respects, the Debian backports package avoids many of the concerns we have, it doesn't eliminate all our concerns. Concerns remaining with that path include no guarantees of timely security updates to backports, we can't use auto security updates for GitLab (and backported dependencies) there either and backports are not part of LTS (so once the Debian base moves to LTS, the only support path is to upgrade/migrate to newer TurnKey). Also, even then, we can't really guarantee what will happen with that in the longer term future. With all that in mind, Omnibus install seems the most sensible.
We did also consider hacking the Omnibus install to allow us to use as many default Debian packages as possible (rather than all the applications bundled within the monolithic Omnibus package). But we decided against that too in the end because of 2 major reasons. Firstly there may be subtle incompatibilities that may not be immediately obvious (but users may encounter). Even if that isn't the case immediately, it may well develop in the future. Plus it may make future upgrades problematic too.
So despite all our reservations (as noted previously) we've agreed that the best of all the unappealing options is a "default" Omnibus install. I'm not sure when that will be ready, but soon I'm hoping.