Date: Thu, 29 Sep 2016 08:56:45 +0200 From: Torsten Zuehlsdorff <tz@FreeBSD.org> To: Steve Wills <swills@FreeBSD.org>, ruby@FreeBSD.org Subject: Re: Feature-Request: pessimistic operator in ports-tree Message-ID: <ac8db37c-18a8-9bb3-132f-0a01e538fbe6@FreeBSD.org> In-Reply-To: <24d2a341-88a7-c99e-1058-6d351014930e@FreeBSD.org> References: <3434c19e-59b3-261a-ef18-6911bba0e072@FreeBSD.org> <24d2a341-88a7-c99e-1058-6d351014930e@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac8db37c-18a8-9bb3-132f-0a01e538fbe6>