You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The package versions of e.g. fullstaq-ruby-3.3-jemalloc seem not to follow any Ruby version, which makes it impossible to use these for dpkg dependencies and still profit from automatic upgrades.
For example, we install our applications as Debian packages, and they have a dependency on a ruby interpreter, such as:
Depends: fullstaq-ruby-3.3-jemalloc
In some case, such as with the bootsnap bug in Ruby 3.3.1, would have a version constraint there, to limit ruby to known good versions, but since the fullstaq packages have versions such as 2-ubuntu-22.04, this does not work.
Describe the solution you'd like
Best would be if the package version would follow the ruby version, since we could have a constraint such as this:
The package must be built with a version like this: 3.3.2-2-ubuntu-22.04.
Additional context
This does make package versions much more consistent with how package versions usually work and would help in many possible scenarios, such as APT pinning, update scanning, or repo mirroring.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The package versions of e.g.
fullstaq-ruby-3.3-jemalloc
seem not to follow any Ruby version, which makes it impossible to use these for dpkg dependencies and still profit from automatic upgrades.For example, we install our applications as Debian packages, and they have a dependency on a ruby interpreter, such as:
In some case, such as with the bootsnap bug in Ruby 3.3.1, would have a version constraint there, to limit ruby to known good versions, but since the fullstaq packages have versions such as
2-ubuntu-22.04
, this does not work.Describe the solution you'd like
Best would be if the package version would follow the ruby version, since we could have a constraint such as this:
The package must be built with a version like this:
3.3.2-2-ubuntu-22.04
.Additional context
This does make package versions much more consistent with how package versions usually work and would help in many possible scenarios, such as APT pinning, update scanning, or repo mirroring.
The text was updated successfully, but these errors were encountered: