Skip to content

Clean up and clarify how de-vendoring works

Luke Shumaker requested to merge lukeshu/ruby:lukeshu/clearer-de-vendor into main

From 3.0 to 3.2 there was a big rework of how de-vendoring included gems works. As a packager in a downstream distro, this new world order was confusing to me; this MR attempts to clarify things by improving pkgdescs, improving comments, and other changes.

Notable non-pkgdesc non-comment changes:

  • Instead of 2 separate _bootstrap=1 and _bootstrap=0 builds, produce a split package with all of the things deleted during de-vendoring. Whether these files are deleted or not (and associated metadata) is the only difference between the two builds; this adds some transparency and will save CPU cycles from compiling the same binaries twice.
  • I added an updvars.sh script to manage *sums=() and _*_gems=() so that updating the list of default and bundled gems is less tedious.
  • ruby-bundled-gems now specifies a minimum pkgver for each gem.

I perhaps went a little overboard with "small, atomic commits"; I wanted to "show my work" to avoid as many questions, both during MR review and when other downstream packagers look at the changes.

Questions I have:

  • Why is it OK to de-vendor default gems that provide tools in /usr/bin/ but problematic to do so for most default gems?
  • Is it intentional that syntax_suggest is listed in _default_gems rather than _default_tool_gems, even though it includes /usr/bin/syntax_suggest? (I added a special-case for it in updvars.sh, to keep the existing values of the variables).
Edited by Luke Shumaker

Merge request reports

Loading