In updating to the latest Redmine (6.0.3) which is compatible with Rails 7 a problem has manifested with the Gemfile.lock file during configuration.
Errno::ENOENT: No such file or directory @ rb_sysopen - /usr/share/redmine/Gemfile.lock https://salsa.debian.org/ruby-team/redmine/-/jobs/7217536#L7520 Reading through the changelog, the way Redmine has handled the Gemfile.lock has changed significantly over time (at one time it just pointed to /dev/null). Currently, the following is done. 1. Gemfile.lock is deleted as part of override_dh_auto_configure. override_dh_auto_configure: ./debian/check-locales bundle install --local --quiet rm -f Gemfile.lock https://salsa.debian.org/ruby-team/redmine/-/blob/master/debian/rules? ref_type=heads#L20 2. Gemfile.lock is generated during postinst in /var/lib/redmine/. ################################################################# ###### # update Gemfile.lock, always ################################################################# ###### rm -f /var/lib/redmine/Gemfile.lock cd /usr/share/redmine if ! bundle install --local --quiet; then if [ "$1" = "triggered" ]; then # probably triggered in the middle of an system upgrade; ignore failure # but abort here echo "################################################################# ########" echo "# Failed to detect redmine dependencies; if you are in the middle of an #" echo "# upgrade, this is probably fine, there will be another attempt later. #" echo "# #" echo "# If you are NOT in the middle of an upgrade, there is probably a real #" echo "# issue. Please report a bug. #" echo "################################################################# ########" exit 0 else # something is really broken exit 1 fi fi cd - >/dev/null chown www-data:www-data /var/lib/redmine/Gemfile.lock https://salsa.debian.org/ruby-team/redmine/-/blob/master/debian/postinst? ref_type=heads#L13 3. A link is installed from /var/lib/redmine/Gemfile.lock to /usr/share/redmine/ Gemfile.lock. https://salsa.debian.org/ruby-team/redmine/-/blob/master/debian/redmine.links? ref_type=heads#L3 It appears that somehow Rails 7 (or some other aspect of the system that has been updated recently) is looking for Gemfile.lock at a stage where it has not yet been generated, causing the failure. Based on the changelog, it look like most of this design was put in place before /usr/ share/rubygems-integration was added to redmine.triggers, which possibly makes some or all of it an obsolete design. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909661 I don’t know very much about how Gemfile.lock files are supposed to work, so I thought I would ask here before doing something that might cause unintended consequences. 1. Is there any good reason why we shouldn’t just ship the Gemfile.lock that is generated at build time instead of deleting it? 2. Is there any good reason for placing Gemfile.lock in /var/lib/redmine/Gemfile.lock instead of /usr/share/redmine/Gemfile.lock? 3. Is there any good reason to continue generating the Gemfile.lock in postinst instead of just letting the /usr/share/rubygems-integration trigger handle it (I assume that trigger with update Gemfile.lock)? -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.