Feature-Request: pessimistic operator in ports-tree

[Torsten Zuehlsdorff]

Aloha,

>> i'm working quite a while on the ruby-ports and it is often annoying.
>> Even after excessive testing and some more real-world testing (thanks to
>> all helpers!) its totally normal, that thinks break.
>>
>> I found one of the main problems is the pessimistic operator in the
>> gemspecs/Gemfiles. Buildtests of all dependencies run fine, we commit
>> the update and than some Gem break, because it defined ~> 1.5.2 and you
>> just updated to 1.6. In the Makefile >= 1.5.2 says everything is fine.
>
> To me it seem rather that the problem is gemspecs over-using or
> mis-using the pessimistic operator. If the gemspec correctly specified
> what actually worked, this wouldn't be an issue.

That is, of course, correct. ;) But we have more than 1.000 
rubygem-ports and it isn't going to happen that all of them teaches the 
gemfiles the correct version. This isn't even needed since gem files are 
designed to work right this way. Its more a problem on our site than on 
the ruby-site.

>> I personally think most of the rubygem breakage can be prevented by
>> teaching the ports-tree about the pessimistic operator. It is far easier
>> to build-test 300 dependencies than to really check if they are able to
>> start. Or even if they run correctly.
>
> How would this help exactly? It seems to me it would make it easier to
> figure out where the mismatch is but wouldn't actually solve the
> problem. And this isn't even the hard part, building all the packages
> doesn't really take much time. But you would still have to correct the
> gemspec or create multiple ports/pkgs for each version needed. What am I
> missing?

The part with breaking everything after an successful build. For GitLab 
i build around 300+ Packages. Every time all packages were build 
correctly, but only one time an update did not break something.

A correct build nearly means nothing for rubygems. If the Gemfile uses 
the pessimistic operator and forbid using the version just updated, 
nothing will happen. It builds fine. You have to runtime-check every 
version depending on that. And sometimes this are many (multiple 
hundreds yesterday).

An pessimistic operator support would ease the detection part. The 
buildtest can fail and you know where to look at. This would be a great 
option added.

Also: even if we patch the gemspec to the use of the newer version, this 
is also error prone. I saw this for GitLab. A specific Gem just runs 
fine the complete time, except one user wanted one option, which is no 
longer supported by the gem in this syntax. So GitLab fails because of 
the update, but only if this option is used. All other parts of GitLab 
using the exact same (but wrong) version of the Gem works fine.

>> What do you think about this?
>>
>> Also i believe its not a rubygem only feature. I stumbled across
>> multiple software which expect an explicit version or an version range
>> or even disallow a single version and accept all other.
>
> I think a patch would help discussion. I'm not unsympathetic, it is a
> pain. But I just don't understand how this would fix anything. Perhaps
> some sort of tool that would check these things would be helpful?

It would not fix anything, it would just ease the detection of such an 
error vector. Rubygem dependencies were designed in a very specific way 
and we currently just ignore this and came up with various problems 
around this.

Yes, some sort of tool could do this also. I experimented a little and 
its a great help, but it is one more tool to use. I think every 
ruby-committer will use it, but for example every new external user 
sending patches need to learn it. Integrated in core there is no need 
for user learning this behavior and therefore one more error possibility 
gone.

After some more thinking i doubt its easy to realize, especially the 
part were more than 1.000 ports need a update to benefit from the 
change. Mh, i add the idea to my port-rewrite-project.

Greetings,
Torsten