#205 Ruby - drop "archive" in Rubygems source guideline
Closed: Invalid None Opened 11 years ago by vondruch.

Currently, the Ruby guidelines contains following point:

{{{
The Source of the package must be the full URL to the released Gem archive; the version of the package must be the Gem's version.
}}}

Although the .gem is archive, it is completely irrelevant in the context and in the light of this review [1], I have the feeling that it might be misleading. Could you please drop the "archive" word from that sentence, replace it with with "file" world or come up with other better wording?

Thank you.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=845107#c14


A question that arises from the bugzilla is, why do you think the tarball is inappropriate?

Still not seeing the rationale for why tarballs are wrong.

Also, I noticed in one of your emails

{{{

%prep
gem unpack %{SOURCE0}
%setup -q -D -T -n %{gem_name}-%{version}
gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec
%patch0 -p1

%build
...
gem build %{gem_name}.gemspec

This is mandatory only for gems with binary extension and just a few
gems are using this approach.
}}}

This is incorrect advice. That approach is what the guidelines require in every case, not just binary extensions.

The only relevant and trusted source of gems is rubygems.org. Since rubygems.org can serve just .gem files and not tarballs, it is natural to use gems and not tarballs as a source. I also requested them to provide the gems on rubygems.org, which they don't do at the moment for various reasons. However, they provide .gem as well as tarball, an in that case, usage of .gem is closer to common practice in the Ruby world.

Moreover, as I explained in the [1], there are higher chances to do successful build of Gem with .gemspec file obtained from "gem spec" command then using upstream .gemspec file and it is more secure for similar reasons.

Yes, I acknowledge that there might be cases, when there is no gem file available, but with the respect of Ruby community, these should be just exceptions.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=839395#c20

If upstream is providing a gemspec file that is out-of-date and includes or does not include things and we notice it, then that gemspec should be patched and the patch sent upstream. I have to do something similar with python packages from time to time when I have to build from a snapshot. If upstream is providing the source as both tarball and gem it does not seem that there is a compelling reason to make the packager use only the gem.

It also seems that the word archive is exactly what we're trying to express in the Guidelines so I think using a more generic term would be an obfuscation rather than a clarification.

Toshio, once more in different words: The .gemspec, which is upstream using to create .gem is different than the one you get using "gem spec" command. This is diff between these two .gemspecs for this particular case, just for illustration [1]. And there is nothing wrong with it, nothing to report anywhere, except the assumption that using "gem spec" is good practice. Please don't try to find parallels where there are non.

I asked you for dropping the archive or providing better formulation. Since you don't want to drop it, here is something which might be more acceptable:

{{{
The Source of the package must be the full URL to the released Gem file, which should be available on rubygems.org; the version of the package must be the Gem's version. If Gem file is not available, you can use tarball as well.
}}}

The last sentence is not perfect, but something we could work on. It tries to endorse usage of Gem files why not prohibit other formats.

[1] https://gist.github.com/3413411

If it creates a different .gem, why is it not wrong?

Because it creates gem in different environment from different input.

After much discussion, the FPC did not agree to any of the proposals (drop "archive", replace with "file").

Closing as WONTFIX.

Login to comment on this ticket.

Metadata