Dne 23.11.2016 v 03:53 Joe Rafaniello napsal(a):
On Tue, Nov 22, 2016 at 6:57 AM, Vít Ondruch <vondruch(a)redhat.com
<mailto: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?i...