Issue #19421 has been updated by rubyFeedback (mark potter). I don't think the ruby core team can decide for distributions what they want to enable. I remember how debian used to remove mkmf which caused issues for those who wanted to install some gems that were not available in the debian repositories. They then thought it was the ruby core team's fault that debian removed mkmf. None from the core team told debian to do so. ---------------------------------------- Misc #19421: Distribution documentation https://bugs.ruby-lang.org/issues/19421#change-101807 * 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/