Date: Fri, 13 Nov 2020 08:47:48 +1100 From: Dewayne Geraghty <dewayne@heuristicsystems.com.au> To: freebsd-ports@freebsd.org Subject: Re: STOP rust! Message-ID: <ea24fe70-6401-e86f-fa58-dbd4b43fc9e0@heuristicsystems.com.au> In-Reply-To: <20201110162440.0f8991a8@rimwks.local> References: <20201110162440.0f8991a8@rimwks.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/11/2020 12:24 am, Rozhuk Ivan wrote: > Hi all! > > With latest ports tree librsvg2-rust-2.50.0 is required to some ports. > It want replace librsvg2-2.40.21. > > I do not want build ugly rust during hours to build small lib in less than minute. > > > Same with polkit & spidermonkey. > https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35 > > I remove polkit where it is possible. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > Good question Rozhuk, I've had a similar "problem" elsewhere. The workaround is to force your applications to break from the normal maintenance/updating process. There are two methods: 1. Lets say the upstream port that now wants to use librsvg2-rust-2.50.0 is /usr/ports/risky/business You'll need to modify /usr/ports/risky/business/Makefile to depend on librsvg2 and not librsvg2-rust OR 2. You'll need to revert the port risky/business, everytime you perform a /usr/ports update. (Lookup svnlite help, or use something like svnlite update /usr/ports svnlite update -r '{2020-11-01}' /usr/ports/risky/business the order is important) Keep a record of which option you've chosen because you'll eventually want to return to the normal way of doing things, because port maintainers track the status of their ports - for security, feature and bug updates and generously do the work for you. (svnlite diff /usr/ports may be helpful, unless you accidentally accept differences ;) ) The more promising approach is, as Yuri suggests, take up the issue with the librsvg2 team. However I've observed that when a downstream project team invest in migrating to new tools, they're unlikely to rescind that decision. You'll also need to track the interaction of up/downstream tools because eventually something will require a new feature in librsvg2 2.50+ Tough call, but the flexibility of the ports system helps.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ea24fe70-6401-e86f-fa58-dbd4b43fc9e0>