svn commit: r467193 - in head/www/gitlab: . files

[Joseph Mingrone]

Matthias Fechner <idefix at fechner.net> writes:
> Dear sunpoet,

> Am 12.04.2018 um 20:33 schrieb Sunpoet Po-Chuan Hsieh:
>> Log:
>>   Fix Gemfile for rubygem-default_value_for 3.1.0 update

>>   - Bump PORTREVISION for package change

>> Modified:
>>   head/www/gitlab/Makefile
>>   head/www/gitlab/files/patch-Gemfile
> I really enjoy your work and it is totally fine for me, if you upgrade a
> gem that you copy the old one and make sure that gitlab uses the old.
> (like you did with r467106, thanks a lot for this!)

> But please do not start to patch the Gemfile!
> This will break gitlab. Have you tested gitlab with this modification?
> (for sure not, I reported exactly that version of default_value_for
> upstream and they rolled back the change as it broke gitlab, they broke
> 3.0.4 and rolled back the modification with 3.0.5, now you changed
> gitlab to use the version that for sure will not work!)

> Please revert this modification and ask me (the maintainer) before you
> start to modify the port I maintain.
> Thanks a lot that you understand this.

> Gruß
> Matthias

I relate.  Sunpoet, I also appreciate your work, but this type of
breakage can be frustrating.  We need to figure out a solution.

> On 13.04.2018 12:07, Alexey Dokuchaev wrote:
>> I don't quite understand how/why would anyone in their right mind write
>> software than breaks when one of its dependencies have *minor* version
>> bump?  Is this specific to Gitlab, or the nature of Gemfiles is really
>> that broken?

This practice seems to be more common and in the extreme case, exact
versions of all components are specified.  A few examples that come to
mind other than Ruby Gems (with Bundler) are node and Haskell's stack.

To match what upstream is requesting, I have wondered if the ability to
specify maximum versions would be useful.

RUN_DEPENDS=
rubygem-default_value_for>=3.0.1<3.1:devel/rubygem-default_value_for

The added complexity is probably not worth it for the ability to run
this sort of test.

devel/rubygem-default_value_for % check_update_breaks_something
*** DANGER, DANGER *** www/gitlab requires devel/rubygem-default_value_for < 3.1 !

A less drastic approach would be to add PORTSCOUT entries to prevent
premature Gem port updates.  In this case

PORTSCOUT=  limit:^3\.0

in devel/rubygem-default_value_for/Makefile

Could this work for everyone?

J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20180413/3078f519/attachment.sig>