Suggestion to remove libyaml-dev from suggested build dependencies on Wiki

[colszowka]

Steps to reproduce the behavior

• The wiki lists libyaml-dev as a recommended package: https://github.com/rbenv/ruby-build/wiki#ubuntudebianmint
• However, the libyaml-dev version present in the packages for Ubuntu 20.04, 21.10 and potentially more contains a bug ( https://github.com/yaml/libyaml/pull/186 )

# On Ubuntu, when libyaml-dev was present at ruby install
$ ruby -ryaml -e 'puts YAML.dump(["a", "b", nil]).inspect'
"---\\n- a\\n- b\\n- \\n"

# expected, i.e. on MacOS
$ ruby -ryaml -e 'puts YAML.dump(["a", "b", nil]).inspect'
"---\n- a\n- b\n-\n"

Note that an additional space char is inserted for the dumped nil array value.

There are related issues on psych and libyaml itself:

• https://github.com/ruby/psych/issues/535
• https://github.com/yaml/libyaml/pull/186

Expected vs. actual behavior

This issue can be fixed by uninstalling the libyaml-dev package and re-installing ruby.

Since psych bundles libyaml in a newer version, but uses the system one if present, I would like to suggest that libyaml-dev be removed from the corresponding wiki.

I am aware that I could just edit the wiki page myself, but I wanted to first provide context for this and also maybe discuss if this is a sane change, since I'm probably not fully aware of any undesired side effects. I can say though that it works on my machine without libyaml-dev now :)

[mislav]

Thanks for raising this issue. If libyaml-dev is installed on the system, then Psych does not use its bundled libyaml? I would have thought it would use its bundled library in any case, but from what you've shown it looks like that's not the case.

[colszowka]

Hey @mislav 👋

Correct, basically that's the case I ran into (using asdf-ruby and by consequence ruby-build):

• Installed ruby build suggested dependencies
• Installed ruby
• Problem

Uninstalled libyaml-dev, reinstalled ruby, works fine. We spotted this as my colleagues didn't have this issue on their systems.

I also got in touch now with psych team since actually they seem to aim to remove bundled libyaml 😱 https://github.com/ruby/psych/pull/541

[hsbt]

I'm also maintain psych. I understand your problem. But It's hard to maintain bundled source code and handle security vulnerability.

[colszowka]

Hey @hsbt :wave:

I totally understand that, thanks for all your work!

I wonder if there is maybe some suitable workaround for Debian/Ubuntu based systems to provide a more recent libyaml myself when building ruby or installing psych itself? I looked around on the psych and ruby-build readmes but couldn't find anything on the spot

[hsbt]

We may add the specific version of libyaml into ruby-build definitions like https://github.com/rbenv/ruby-build/blob/500863c23dbc536025bbd42f7cb3beeebddb2d7a/share/ruby-build/2.1.1#L1 after removing the bundled source of psych.

and I will add the feature of flexible detection of libyaml source to psych. Like gem install psych -- --with-libyaml-source-dir=/tmp/libyaml-0.2.5.

[mislav]

@hsbt Do you have a recommendation what should ruby-build do with libyaml going forward— should we recommend installing it in our docs or not? I'm not familiar with how psych works

[hsbt]

We should recommend using Ubuntu version in the future. If users have specific problem like @colszowka 's report, They can use specific version of libyaml like https://github.com/rbenv/ruby-build/issues/1950#issuecomment-1072009108.

And ruby-build shouldn't enforce to use libyaml as little of it as possible.

@colszowka Can we close this? Do you have another concerns?

[colszowka]

@hsbt Yeah, I think we can close it, gonna do this now. I guess my main problem was that I was on Ubuntu 20.04 LTS on that machine and that just happened to have this outdated libyaml version. As a user for me it's usually kinda convenient to have the library bundled alongside the gem so it's the same across my team, but on the one hand this seemed like a rather uncommon edge case I ran into and also I understand that from the gem maintainer side of things this adds a lot of additional overhead and responsibility, so I understand that you'd rather get rid of it.

Thanks for the feedback!