Issue #19421 has been updated by jeremyevans0 (Jeremy Evans). ioquatix (Samuel Williams) wrote:
the best practice for building source packages. The documentation I wrote from this was removed as "out of scope" but I disagree with that (https://github.com/ruby/ruby/commit/c35ebed895e1a3f7bced3db50ea0db8f284744e8). I don't have a strong opinion about what it should look like, but I think we should give a clear example of how to build source packages like what I wrote.
As the maintainer of the Ruby port for OpenBSD, here's what I think. The general build instructions should work: ``` configure # with appropriate options if needed make make install # as superuser if needed ``` Anything more than that should probably be handled in a per-operating system manner.
- Related to the above, what is the official location for source tarballs?
`https://cache.ruby-lang.org/pub/ruby/MAJOR.MINOR/`
- What optional dependencies are required for building vs distributing Ruby. Arch Linux currently lists: `doxygen gdbm graphviz libffi libyaml openssl ttf-dejavu tk` as dependencies but it's not clear if this list is up to date, or what the expectations are. When someone installs Ruby (e.g. `apt-get install ruby`) what dependencies should be installed? I think it would be helpful to list expected dependencies (from a system package POV), etc.
These libraries are needed for a full Ruby install: * `libffi`: used for fiddle * `libyaml`: used for psych * `libssl`/`libcrypto`: used for openssl (provided by OpenSSL or LibreSSL) * `libreadline`: use for readline (not really required anymore with reline) * `libgmp`: used for faster Bignum calculations (maybe Rational as well) * `libz`: used for zlib For each, you should have both the headers and the shared/static libraries, if the operating system packages them separately. `gdbm` and `tk` were removed as included extensions a while back. Not sure why `ttf-dejavu` would be needed, that looks like a font. `doxygen` and `graphviz` are looked for in the configure script, but I'm not sure to what extent they are used. They aren't needed for a normal Ruby install AFAIK. I think this is more fully covered at https://docs.ruby-lang.org/en/master/contributing/building_ruby_md.html
- Is Ruby needed for building Ruby? Should source packages install Ruby before building from source? If so, what versions are supported?
Not when building from a tarball, unless the tarball has a bug (I think 3.2.0-preview2 did). Ruby is needed for building Ruby from the git repository, but that probably isn't something operating system packagers should be doing.
- Clear guidance on gems that are distributed an alongside Ruby, and how security changes to gems are managed.
All bundled and standard gems are included in the distribution tarball. How security changes to gems are managed seems a different discussion than how distribution should be handled, but it is related. In general, with either standard or bundled gems, you can `gem install` to get updated versions. However, for standard gems, the updated versions won't be used unless loaded via the `gem` method or when included in a `Gemfile`.
Even if we have more detailed documentation elsewhere, let's summarise it and then cross-reference it. People who build packages to distribute and install Ruby should feel supported, they are very important to our community. To this end, I established `#distribution` channel on Slack for discussion. We should listen to the questions being asked and use those questions to drive improvements to documentation.
From my experience, packaging differs widely across operating systems. The job of an operating system packager is to make the package integrate better into the operating system, and how that is done can vary widely across operating systems. I think it's great to provide more support as needed, but we should make sure the documentation is helpful without being authoritarian. The documentation should answer questions that packagers may have, but it should not state definitively how something should be done by packagers. ---------------------------------------- Misc #19421: Distribution documentation https://bugs.ruby-lang.org/issues/19421#change-101674 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- I use Ruby a lot, on a lot of different systems, and help people and companies use it, including developers who install it on their systems. Over time, I found that installing Ruby isn't always easy. Part of this is due to package management. There are many systems, and Ruby has had some tricky migrations (e.g. OpenSSL is probably one of the most painful ones that lots of developers have trouble with). Arch Linux has been stuck on Ruby 3.0 for a long time, which could be considered surprising given that Arch Linux is often on the bleeding edge of releases. I personally use Arch too. So I decided to ask, what is holding them up from making a release? I found out they had many questions about how to distribute Ruby correctly. When I listened to those questions I felt that there are many ambiguities in how we build and package Ruby for operating system packages. This isn't to say that there isn't a good way to do it, just that we as a core team might be able to improve our communication about how Ruby is evolving and the implications for package managers (if any). I've introduced `doc/distribution.md` as an effort to start having better documentation for people distributing Ruby. There are many ways which people distribute Ruby, and many "partial" documentation or assumptions being made about how to distribute Ruby and I'd like to provide a convenient standard location that can help people build package for Ruby distribution. Ultimately this makes my job easier because the latest versions of Ruby will be easier to install, so that's what I care about, but I don't care about what specifically is in the document, except that I think we should listen to the kinds of questions being asked and, in the best interest of Ruby, provide guidance. There was a lot of good discussion on the PR, but my goal is not to make a finished document, but instead plant the seed so it can grow. https://github.com/ruby/ruby/pull/6856 Some follow up discussion is required: - What is the best practice for building source packages. The documentation I wrote from this was removed as "out of scope" but I disagree with that (https://github.com/ruby/ruby/commit/c35ebed895e1a3f7bced3db50ea0db8f284744e8). I don't have a strong opinion about what it should look like, but I think we should give a clear example of how to build source packages like what I wrote. - Related to the above, what is the official location for source tarballs? - What optional dependencies are required for building vs distributing Ruby. Arch Linux currently lists: `doxygen gdbm graphviz libffi libyaml openssl ttf-dejavu tk` as dependencies but it's not clear if this list is up to date, or what the expectations are. When someone installs Ruby (e.g. `apt-get install ruby`) what dependencies should be installed? I think it would be helpful to list expected dependencies (from a system package POV), etc. - Is Ruby needed for building Ruby? Should source packages install Ruby before building from source? If so, what versions are supported? - Clear guidance on gems that are distributed an alongside Ruby, and how security changes to gems are managed. Even if we have more detailed documentation elsewhere, let's summarise it and then cross-reference it. People who build packages to distribute and install Ruby should feel supported, they are very important to our community. To this end, I established `#distribution` channel on Slack for discussion. We should listen to the questions being asked and use those questions to drive improvements to documentation. -- https://bugs.ruby-lang.org/