JFTR the changes were made into a PR
https://src.fedoraproject.org/rpms/ruby/pull-request/158
On 8/16/23 19:34, Vít Ondruch wrote:
Hi and very much thank you for looking into this issue.
Dne 10. 08. 23 v 18:24 Jarek Prokop napsal(a):
..snip..
So the pros / cons of this approach currently seem:
+ we'd unbundle default gems away
+ no more symlinks.
+ closer to upstream behavior for the users
- We'd have to retain the structure and provide each "fake" path to a
file.
* Though we are doing something a small bit similar with the symlinks.
- added complexity of writing correct paths into the files on their
correct places.
One cons is that still, the `$LOAD_PATH` with this approach will be
different to what would be the default.
Right, that is surely a deviation. How much that matters is another
question.
Alternatively, this is just an academic idea, populate the default
load path with default gems.
I, however, do not know where would the right place for that be, or
what would be the cons of this approach
(apart from potentially breaking expectations set accross the whole
Ruby environment for loadables).
Not sure about this. We would need to ensure that the paths has lower
priority in `$LOAD_PATH`.
With more uncovered facts as to the env modification, I am not even sure
if this would properly survive bundler's extensive ENV modification...
But I have quickly dismissed these as I have high doubts such patches
would ever be accepted upstream and maintainability of such
approaches is quetionable at best.
Additionally, I am not sure what should be the behaviour with the
plain rdoc executable and bundler executed like this: `bundle exec rdoc`
From the `env` output you can see, that at minimum, Bundler preserves
some of the original env variables, such as `BUNDLER_ORIG_PATH`,
because it obviously can modify `$PATH` env variable. It can also
influence `MANPATH`:
https://github.com/rubygems/rubygems/blob/556349fd863ba586930804140fbcdd66fe786c0d/bundler/lib/bundler/runtime.rb#L33
I was not aware of this behavior and it seems to complicate the matter :/
Huh, I wasn't even aware there are gems distributing proper manpages, or
that rubygems is capable of installing them.
Well, what's more of a concern that I was hitting is the executable
generated by Rubygems, especially this line: `load
Gem.activate_bin_path('rdoc', 'rdoc', version)`, that one is the reason
the gemspec even need to be in the special directory...
BTW you are using `find` and what not to create the stubs, but it
could be possible to use the already built Ruby and use them to e.g.
evaluate the .gemspec files to get the list of gem files. Or even try
to identify the unbundled default gems.
I am not a fan of using the contents of the package for modifying the
package contents (to not rely on it, Ruby changes more than coreutils...).
We can use Ruby for a smarter way later, current way is OK for
demonstration of the concept.
Thinking about the conflict concern (
https://src.fedoraproject.org/rpms/ruby/pull-request/158#comment-154397
) of regular `rubygem-rdoc` and the default gem bundled with Ruby
sources gem `rubygem-rdoc`, where the gemspec would be gone from the
defaults/ directory this if the standalone gem RPM was to replace the
default gem from the Ruby upstream sources
We'd have to have a different RPM naming for these default gems. There
is not just RDoc in this case but also rubygem-json, rubygem-racc and
perhaps a few more that are also present in Fedora as standalone gems
and are defined as default gems as well.
IOW a default gem should not conflict with the same library installed as
a regular gem.
The 3.3.0 preview
https://github.com/ruby/ruby/blob/v3_3_0_preview1/doc/standard_library.rdoc#label-Default+gems
specifies the behavior as "default gems can be updated used by rubygems"
and `gem update` is mentioned, The translation to RPM would be simple
`dnf update rubygem-some_default_gem`, but when I try `gem update` with
rbenv's ruby 3.2.0, and the URI gem (to "fix" the recent cve), I get
something that might not be clear to people, and let's skip for the
moment the fact that people might not even care about fixing such CVEs.
```
$ ruby -ruri -e 'p URI::VERSION'
"0.12.0"
$ gem update uri -N
Updating installed gems
Updating uri
Fetching uri-0.12.2.gem
Successfully installed uri-0.12.2
Gems updated: uri
$ ruby -ruri -e 'p URI::VERSION'
"0.12.2"
$ cat Gemfile
# frozen_string_literal: true
source "https://rubygems.org";
$ bundle exec ruby -ruri -e 'p URI::VERSION'
"0.12.0"
```
For bundler environment this gem update seems to be essentially a no-op.
Which makes sense, it does not replace the default files in the
/usr/share/ruby, that seem to have priority.
We can, instead of moving them away from the /usr/share/ruby, let the
files be on their place and create subpackages made in a way that does
not conflict with stand-alone gems/RPMified gems.
This would kind of retain the upstream behavior, but will generate a new
RPM, let's say names like `rubygem-default-rdoc`, `rubygem-default-json`
etc... It will provide the rubygem(rdoc) rubygem(json),
perhaps rubygem(default-rdoc), but I don't see the use of the latter, I
don't think we expect usage of bundler in any place of the Fedora Ruby
RPM ecosystem. This will allow for parallel installation of both the
default and regular gem. Minus of this approach is that updating
rubygem-rdoc will not fix problems present in rubygem-default-rdoc, but
neither will `gem update rdoc` when we are speaking in terms of the
bundler's environment. If the version will be higher I expect regular
Rubygem's resolver to resolve to the latest, I can validate that claim
later (next week probably, when I get enough sleep on this).
Thinking about it, default gems are a special case on their own.
A set of base libraries that people should be able to rely upon and it
might not necessarily be expected that an update to that gem would in
any way break API by replacing default gem. Therefore default gems are
different from their regular libraries solely based on their location
and the expectation placed on them by upstream.
I think we should keep splitting the default gems out (Why would I need
rubygem-typeprof on a prod system...), but provide them with a file
layout similar to upstream, that would be somewhat of a compromise I can
also see working.
As mentioned, if this sounds like a venue fit for investigation, I'll
inspect it next week.
Regards,
Jarek
Vít
_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
