Dne 23.11.2016 v 03:53 Joe Rafaniello
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.
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.
The (1) and (3) should be covered now by the newly introduced
gemspec_add_dep and gemspec_remove_dep macros . 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.
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 ....