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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to