Clean up and clarify how de-vendoring works
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 inupdvars.sh
, to keep the existing values of the variables).
Edited by Luke Shumaker