Add doc/distribution.md to help reduce some of the confusion.
#6856
Conversation
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
ioquatix
force-pushed
the
doc-distribution
branch
from
ff28b79
to
104aa1d
Compare
| ```bash | ||
| $ ./autogen.sh | ||
| $ ./configure -C | ||
| $ make |
There was a problem hiding this comment.
Building ruby from the source itself is not necessary, if ruby is available already.
Simply ruby ./tool/make-snapshot tmp can work.
There was a problem hiding this comment.
But most distributions build ruby in an environment where ruby is not yet available.
There was a problem hiding this comment.
Why needs to make tarballs in such environment, instead of installing?
There was a problem hiding this comment.
First of all, working ruby (currently >= 2.2) is required to build ruby from a git-cloned source tree, and tool/make-snapshot works only on a git-cloned source tree.
Although this sounds like chicken-and-egg, make dist is not intended for all Ruby developers, but for only the Ruby release managers.
There was a problem hiding this comment.
We use https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.4.tar.xz to build ruby from and it doesn't like like we need ruby for that.
There was a problem hiding this comment.
Actually, this section is useful for building snapshot packages. And I am using tool/make-snapshot for that.
There was a problem hiding this comment.
No, we don't. For official Fedora releases, we always use official tarballs. I don't remember any exception for past decade.
However, I am using self prepared tarballs for test builds, especially closer to the major upstream releases. I could use a nightly snapshots, but if there is some fast turnaround with fixes, the nightly snapshots are not flexible enough. And since I already have script which prepares the tarball as well as adjusts patches we are carrying around and updates part of the .spec file, I am using them always.
There was a problem hiding this comment.
This was very confusing, the first section of this document was basically something package managers should rarely if ever do (they should use release tarballs for packaging). I fixed it in 826067b.
| ### Releasing an Updated Ruby Gem | ||
|
|
||
| Normally, the Ruby gem maintainer will release an updated gem. This gem can be installed alongside the default gem. This allows the user to update the gem without having to update Ruby. | ||
|
|
There was a problem hiding this comment.
Unfortunately, this suggestion would not work in practice. If distribution wanted to fix some issue, then it would be fixed by applying patch. Because as it is stated above "The standard way to build a package for distribution is to build a tarball." If there was a way to modify the tarball or override parts of the expanded tarball, then this could be different discussion.
There was a problem hiding this comment.
We should try to get clarity on this because IIUC, if a vulnerability is found in a gem, this is the current process. If the process does not work well, let's propose a better way.
There was a problem hiding this comment.
From distro POV, the vulnerable code needs to be fixed. And the fix does not mean shipping the fixed gem but keeping the vulnerable version around. Distro also promises that security fixes won't break the user code. This is hard to achieve with dependencies locked in Gemfile (or possibly not locked, because who would specify e.g. dependency on cgi gem, when it is part of StdLib and this causes various other issues). All in all, patching is the way to go. The vulnerability is fixed, the vulnerable code is not shipped anymore, the Gemfile.lock files are still valid.
Now, of course I could imagine some improvements. E.g. one problem is, that the default gems are not kept as a gems in the StdLib. This basically disallows to remove the vulnerable code. Quite some time ago, I have proposed this change:
|
|
||
| ### Releasing a New Ruby Version | ||
|
|
||
| If the update is critical, then the Ruby maintainers may decide to release a new version of Ruby. This new version will include the updated standard library. |
There was a problem hiding this comment.
Who is the target audience of this paragraph? The Ruby maintainers od the distribution package maintainers? This kind of speaks to the former, while it should provide explanations to latter.
There was a problem hiding this comment.
Maybe the question about the target audience should be generalized to the whole document, because it is not clear anymore, after re-reading this document
There was a problem hiding this comment.
The target audience is downstream maintainers, but it's explaining the process by which they would receive or need to make changes.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
This document is by no means perfect, but it's a good step in the right direction. Please feel free to create more PRs to improve it. |
|
@voxik @Segaja I wrote my thoughts here: https://bugs.ruby-lang.org/issues/19421 It would be great to have you, and other package maintainers, involved in that discussion. |
https://bugs.ruby-lang.org/issues/19178
To clarify, I think this document should be an overview of the entire process, from source code to package installed on the user computer. However, we should emphasize and clarify the process for downstream maintainers.