Dne 23.11.2016 v 03:53 Joe Rafaniello napsal(a):


On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch <vondruch@redhat.com> wrote:
Not mentioning that this wording was introduced quite recently [1] and
from the commit, there is no obvious that it would be meant as "the
ouput is just informative, don't use it for anything".


You probably have been inspecting gemspec contents before 2013 but this change is over 3 years old and has shipped with ruby since ruby 2.1 so it's not quite recent.

My point was that somebody even prior my time explored this way and started to use it. There were no comments about "examination". Once they were used, there was no reason to re-evaluate if the method is sound or not, until it broke.



 
Just for your information, we are modifying .gemspec files for as long
as I remember. This [2] is for example one of my first commit to
ActionPack and you'll see that we were modifying .gemspec files at that
time. May be it is not nice, but unfortunately, we have to do it.


Maybe we had to modify gemspecs in 2011.  Is it possible to summarize what we need to modify gemspecs for?

There are three (at minimum) reasons why we need to modify the .gemspec and I assume every distribution is doing it:

1) Get rid of platform specific dependencies. E.g. rubygem-listen depends on Mac, Windows, BSD specific libraries and there is obviously no reason to ship them on Linux.

2) Sometimes we need to modify the file list. For example in the case of execjs, there is bundled some windows specific js script. Since it is "bundling" case and it is Windows specific, we decided that we won't ship the specific file and therefore we need to remove it from the file list.

3) Change the version dependencies. As we typically ship just one version of library, sometimes we are in hard position that we have version X, which is used by some library, while the other library depends on version Y. There is not always any reason behind it other then some of the libraries was not updated for some time.

Also please note that there are two places where these modifications might happen. Historically, we mostly modified just the .gemspec file from the specifications/ folder, but since there was introduced the gem repackaging step (which I hate from the very beginning, but I lost the battle), the modifications might happen earlier.

Since rubygems is telling us it's not a public API, even if we can't remove all of the gemspec modifications, it's probably best to try to remove the easier ones.

The (1) and (3) should be covered now by the newly introduced gemspec_add_dep and gemspec_remove_dep macros [1]. So it is probably good start to use them. But please note, that I introduced these macros in Rawhide one month ago and they will be part of 2.3.3 and 2.2.6 updates, which are in updatest-testing. It is unfortunate that this is not breaking just Rawhide, but also stable releases.


Note, we can continue to modify the gemspecs with the knowledge that any new rubygems version could break us.  That's a risk we can choose to accept.

Yes, this is expected and it won't happened for the fist time probably (there was introduce for example the Bundler stub line, for example). And I am fine if that happens in Rawhide.

But still, patch release of RubyGems is not "new" version for me. May be we need disagree on that.

Also please note that there is difference if the change is purely RubyGems change, but since this version of RubyGems was pulled into Ruby, it is much harder situation ....


Vít


[1] http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/commit/macros.rubygems?id=4fb1d9c02d92ae2f7ecaf1b644695ed94fc12978