Date: Sat, 14 Apr 2018 03:33:35 +0800 From: Sunpoet Po-Chuan Hsieh <sunpoet@freebsd.org> To: Matthias Fechner <idefix@fechner.net> 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: <CAMHz58R7x5QtDFW2a_jT8DKR18AoJw72TDgb1LgPUHYZna1G9g@mail.gmail.com> In-Reply-To: <431aaec9-51c2-c0c9-7a1f-2f29f79edb5d@fechner.net> References: <201804121833.w3CIXtgW077267@repo.freebsd.org> <e1a55c7b-1ad1-36c8-ec3d-f806702feed5@fechner.net> <CAMHz58RD9rtyqBLV6nsZ2naOvGRiO7PDPAGWZ8Vemnz-g1J6cw@mail.gmail.com> <431aaec9-51c2-c0c9-7a1f-2f29f79edb5d@fechner.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 13, 2018 at 5:55 PM, Matthias Fechner <idefix@fechner.net> wrote: > Am 13.04.2018 um 10:41 schrieb Sunpoet Po-Chuan Hsieh: > > > I think that default_value_for 3.0.4 update is a different case. > gitlab wats default_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, I would not copy the old version unless it's necessary. > > In this case, the only change between default_value_for 3.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, saniti= ze > 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 shoul= d > 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= . > OK, I understand your point of view. You want to be 100% safe by keeping Gemfile unchanged. When I notice an update may not fit the version in Gemfile, - If the version requirement can be relaxed, I patch the Gemfile. (I still think default_value_for 3.1.0 which only adds Rails 5.2 support is acceptable.) - otherwise, I'll svn keep a copy of the old version and update RUN_DEPENDS . That'll be fine if you want me to choose the second one unconditionally. I'll add rubygem-default_value_for30 and revert previous change of Gemfile. Regards, sunpoet > 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 > > -- > > "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?CAMHz58R7x5QtDFW2a_jT8DKR18AoJw72TDgb1LgPUHYZna1G9g>