On 8/3/25 11:43 PM, Soren Stoutner wrote:
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
See gitlab's postinst, Gemfile.lock is generated early in postinst. We
also generate it in systemd service since we can't set dpkg trigger for
native packages.
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?
Yes, we need to be able to ship newer semver compatible versions of
dependencies. Matching Gemfile.lock exactly is almost impossible if
others want to update dependencies independent of redmine.
2. Is there any good reason for placing Gemfile.lock in
/var/lib/redmine/Gemfile.lock instead of /usr/share/redmine/Gemfile.lock?
Yes, we need to regenerate it when dependencies are updated. They change
in unstable and backports, even from the day of upload to actually
shipped in stable it changes.
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)?
Trigger is for dependency updates and it can't handle native
dependencies (path is dynamic depending on arch and dpkg don't support
regexp in trigger path). So additionally you need to generate it when
service is started.
Some postinst steps likely will need a Gemfile.lock
1. postinst Gemfile.lock generation for postinst itself
2. dpkg trigger Gemfile.lock regeneration for pure ruby gem updates
3. systemd service Gemfile.lock regeneration for cases dpkg trigger
don't support.
2 may be redundant if doing 3, but it does not hurt.
It'd be good to have it in ruby team wiki. If you found it useful,
consider adding it to wiki.
--
Soren Stoutner
so...@debian.org
