Date: Fri, 13 Apr 2018 11:55:13 +0200 From: Matthias Fechner <idefix@fechner.net> To: Sunpoet Po-Chuan Hsieh <sunpoet@freebsd.org> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r467193 - in head/www/gitlab: . files Message-ID: <431aaec9-51c2-c0c9-7a1f-2f29f79edb5d@fechner.net> In-Reply-To: <CAMHz58RD9rtyqBLV6nsZ2naOvGRiO7PDPAGWZ8Vemnz-g1J6cw@mail.gmail.com> References: <201804121833.w3CIXtgW077267@repo.freebsd.org> <e1a55c7b-1ad1-36c8-ec3d-f806702feed5@fechner.net> <CAMHz58RD9rtyqBLV6nsZ2naOvGRiO7PDPAGWZ8Vemnz-g1J6cw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 13.04.2018 um 10:41 schrieb Sunpoet Po-Chuan Hsieh: > > I think that=C2=A0default_value_for 3.0.4 update is a different case. > gitlab wats=C2=A0default_value_for ~> 3.0.0 and it fits the rule. > > I would like to keep less number of gems with multiple versions in the > ports tree. > It will sometimes make the dependency tree complex. > Therefore,=C2=A0I would not copy the old version unless it's necessary.= > > In this case, the only change between default_value_for=C2=A03.0.5 and > 3.1.0 is Rails 5.2 support [1]. > I don't think it breaks gitlab. > Can you please confirm if it really breaks gitlab? > If so, I'll revert it as soon as possible. I spent already days to find out why gitlab does not work or better that some features are not working. An it most of the cases it was the last feature I tested that failed. All these problems are related to the fact that the Gemfile that is delivered by gitlab was patched to use a newer version. And please believe me, that is not fun. This is the reason why I removed nearly all patches from the Gemfile. I include only patches that are absolutely necessary to get the gitlab port install-able with FreeBSD ports (e.g. sentry-raven, httparty, sanitize and some more). To make tests for all features in Gitlab you will require many hours and I'm not willing to do the work the gitlab team is doing already for us. They provide us with clear instructions what version are tested and should work. To be 100% save we should use what is in the Gemfile.lock, but this would really a major effort and I think to use what is in Gemfile defined is relatively safe. I remember only 2 cases where even the definition in the Gemfiles cause gitlab to break. One was the upgrade of default_value_for from 3.0.3 to 3.0.4. So please stop to modify the Gemfile that comes with gitlab. Please create a new port rubygem-default_value_for30 which is copied from version 3.0.5. If you like you can also fix the dep in the gitlab port to point to this rubygem-default_value_for30 or I do not have a problem to do it by myself= =2E If ports are not required by gitlab anymore, I will mark them as expired to clean up obsolete ports. Thanks a lot Sunpoet for you support i really appreciate. Gru=C3=9F Matthias --=20 "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?431aaec9-51c2-c0c9-7a1f-2f29f79edb5d>