Re: rubgem update to 3.2.7
On Mon, Jul 9, 2018 at 1:13 AM Stefan Esser wrote:
>
> Am 09.07.18 um 05:04 schrieb Koichiro Iwao:
> > On Mon, Jul 09, 2018 at 12:02:22AM +0200, Walter Schwarzenfeld via
> > freebsd-ports wrote:
> >> Portmaster tries to build the update in the wrong order.
> >>
> >> Right order for me was (depend on which packages are installed):
> >>
> >> rubygem-glib2
> >> rubygem-gobject-introspection
> >> rubygem-gio2
> >> rubygem-gdk_pixbuf2
> >> rubygem-pango
> >> rubygem-gdk3
> >>
> >> rubygem-gtk3
> >>
> >> rubygem-atk
> >
> > I can also confirm the issue. I always perform portmaster in order that
> > you shown by hand when rubygem-gtk ports updated. portmaster needs to be
> > fixed.
>
> A quick check shows that this is a problem with the port, which obviously
> declares actual build dependencies as run dependencies.
>
> Please open a PR and let the ruby maintainers fix this issue.
>
> E.g. in x11-toolkits/rubygem-gtk3/Makefile:
>
> RUN_DEPENDS=rubygem-atk>=${PORTVERSION}:accessibility/rubygem-atk \
> rubygem-gdk3>=${PORTVERSION}:x11-toolkits/rubygem-gdk3 \
>
> rubygem-gdk_pixbuf2>=${PORTVERSION}:graphics/rubygem-gdk_pixbuf2 \
> rubygem-gio2>=${PORTVERSION}:devel/rubygem-gio2 \
> rubygem-glib2>=${PORTVERSION}:devel/rubygem-glib2 \
>
> rubygem-gobject-introspection>=${PORTVERSION}:devel/rubygem-gobject-introspection
> \
> rubygem-pango>=${PORTVERSION}:x11-toolkits/rubygem-pango
>
> Run dependencies are generally built after the port that needs them, since
> they may themselves depend on resources provided by the respective port.
That doesn't seem right. That is the reverse of a run dependency. If
vim/Makefile: RUN_DEPENDS= ncurses
then ncurses cannot possibly depend on vim as a BUILD_DEPENDS. poudriere
builds RUN_DEPENDS in advance, and RUN_DEPENDS should be rebuilt
in advance as well.
> Build dependencies OTOH provide those files that need to be updated before
> building a port. They may also be run dependencies (and often are), and in
> that case they need to be in both the BUILD_DEPENDS and RUND_DEPENDS lists.
This doesn't seem right either. Unless a ruby gem is compiling C or C++
modules, its dependencies are only needed at runtime.
> I cannot modify the behavior of portmaster (i.e. build run dependencies
> before the port that needs them, since this would break quite a number of
> other ports with correct dependency specifications: Then portmaster would
> try to build run dependencies before their prerequisites are available).
>
> So, I'm sorry, but portmaster will not be able to upgrade the rubygem ports
> in the correct order, unless the port dependencies are fixed.
I suspect this might actually be a portmaster issue.
# Adam
--
Adam Weinberger
ad...@adamw.org
https://www.adamw.org
___
freebsd-ruby@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ruby
To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Fri, Sep 13, 2019 at 3:06 AM Koichiro Iwao wrote: > > On Fri, Sep 13, 2019 at 10:00:19AM +0200, Antoine Brodin wrote: > > On Fri, Sep 13, 2019 at 9:45 AM Koichiro Iwao wrote: > > > Hi, > > > > > > I would like to suggest introducing FLAVOR to Ruby ports. > > > > > > AFAIK multiple version of Ruby ports (lang/ruby??) can be installed at > > > the same time. One of these ruby ports will be *default* installed as > > > PREFIX/bin/ruby. In contrast of Ruby lang, rubygem ports cannot be > > > installed for multiple Ruby version at the same time. > > > > > > I would say Ruby and rubygem ports needs FLAVORS like Python ports. > > > In Python ports, the same origin py- ports can be installed for multiple > > > versions such as py27, py35, py36. If the same thing can be done with > > > Ruby ports, FreeBSD Ruby ports will be much improved. > > > > > > I would appreciate if you Ruby folks bounce some ideas off each other. > > > Let me know if someone's already working on FLAVORS on Ruby. Is there > > > something that I can help you with? > > > > Please no. I don't see valid reasons. > > Why? I don't see invalid reasons. Had Ruby FLAVORS already denied in the > past? What's the difference between Rython and Ruby? py- ports can be > installed for py35 and py36 at the same time. Why not for Ruby? > > I'm just brainstorming Ruby FLAVORS. Both positive opinions and negative > opinions are welcome. Systems MUST be able to support concurrent installations of python2.7 and actual python. What is your use case for concurrent ruby? # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
> On Sep 13, 2019, at 22:27, Koichiro Iwao wrote: > >> On Fri, Sep 13, 2019 at 09:33:43AM -0600, Adam Weinberger wrote: >> Systems MUST be able to support concurrent installations of python2.7 >> and actual python. What is your use case for concurrent ruby? > > I know the importance of Python 2. Even if it is EoL-ed, it will be > required over the next a few years because not a few applications don't > migrate to Python 3. So that's true and reasonable. > > Excuse me that I'm answering your question with a question. What about > PHP? Concurrent installation is a MUST? > > FreeBSD ports allows concurrent installations of multiple Ruby versions > however doesn't allow concurrent installations of rubygems for multiple > Ruby versions. This inconsistency is the issue for me. The issue is that FLAVORS has added a substantial (and painful) complexity to python ports and python.mk. It means that a number of people have had to be hyper-vigilant and watch commits closely to catch errors introduced when people utilize the paradigm incorrectly. It’s a bitter pill, but it’s accepted because the use-case for multiple concurrent python versions is essential. As Antoine said, inconsistency isn’t a strong enough use case. Which brings us back to the original question: is there a specific use-case for concurrent ruby that makes the substantial increase in cognitive load, complexity, and monitoring worth it? # Adam — Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: FLAVORS for Ruby
On Mon, Sep 16, 2019 at 8:39 AM Koichiro Iwao wrote: > > On Sat, Sep 14, 2019 at 10:52:45AM -0600, Adam Weinberger wrote: > > The issue is that FLAVORS has added a substantial (and painful) complexity > > to python ports and python.mk. It means that a number of people have had to > > be hyper-vigilant and watch commits closely to catch errors introduced when > > people utilize the paradigm incorrectly. It’s a bitter pill, but it’s > > accepted because the use-case for multiple concurrent python versions is > > essential. > > > > As Antoine said, inconsistency isn’t a strong enough use case. Which brings > > us back to the original question: is there a specific use-case for > > concurrent ruby that makes the substantial increase in cognitive load, > > complexity, and monitoring worth it? > > PHP also have FLAVORS. What about PHP? Multiple concurrent PHP versions > is essential? We're going in circles here. I've for the third time now that what we'd need to get on board is a use case, a description of the end-user problem that we're trying to solve. What you've provided (for the fourth time in this thread) is a straw man argument. What other languages have is irrelevant. We are much less concerned with "consistency" than with solving end-user problems in a way that fits the specific use case. Steve seemed interested in the idea. I'd explore it with him, and I hope you are able to make it happen. I'm done here. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
