Date: Tue, 26 Sep 2023 18:21:32 +0200 From: Guido Falsi <madpilot@FreeBSD.org> To: Jose Quinteiro <freebsd@quinteiro.org>, ports@freebsd.org Subject: Re: dns/bind916 builds rust unexpectedly Message-ID: <9bdb3f9a-6591-d7ac-87d9-334b4595411c@FreeBSD.org> In-Reply-To: <646911f3-be02-c078-2833-f8af04299af3@quinteiro.org> References: <202309260653.38Q6rISB011933@nuc.oldach.net> <6d9121e9-87ac-1a2a-3cb8-b9bccaab4e96@FreeBSD.org> <646911f3-be02-c078-2833-f8af04299af3@quinteiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26/09/23 17:44, Jose Quinteiro wrote: > On 9/26/23 00:17, Guido Falsi wrote: >> On 26/09/23 08:53, Helge Oldach wrote: >>> Gareth de Vaux wrote on Mon, 25 Sep 2023 17:06:54 +0200 (CEST): >>>> Hi all, I've just upgraded bind916 which brought half my system down >>>> since >>>> it suddenly required a mountain of python packages and rust which needed >>>> around 13GB (and hours) to build - space which I didn't have nor have >>>> ever >>>> remotely expected to need for a ports build. >>>> >>>> My bind configuration options are basically the defaults: >>>> >>>> # grep OPTIONS_FILE_SET /var/db/ports/dns_bind916/options >>>> OPTIONS_FILE_SET+=IDN >>>> OPTIONS_FILE_SET+=JSON >>>> OPTIONS_FILE_SET+=LMDB >>>> OPTIONS_FILE_SET+=MANPAGES >>>> OPTIONS_FILE_SET+=TCP_FASTOPEN >>>> OPTIONS_FILE_SET+=GSSAPI_NONE >>>> OPTIONS_FILE_SET+=DLZ_FILESYSTEM >>>> >>>> These are the top level dependencies: >>>> >>>> # make -C /usr/ports/dns/bind916 build-depends-list >>>> /usr/ports/ports-mgmt/pkg >>>> /usr/ports/textproc/py-sphinx >>>> /usr/ports/devel/pkgconf >>>> /usr/ports/security/openssl >>>> /usr/ports/converters/libiconv >>>> /usr/ports/devel/libuv >>>> /usr/ports/textproc/libxml2 >>>> /usr/ports/dns/libidn2 >>>> /usr/ports/devel/json-c >>>> /usr/ports/databases/lmdb >>>> /usr/ports/devel/libedit >>>> >>>> Does anyone know which option/dependency is causing this? I suspect >>>> MANPAGES -> py-sphinx since it has 'py' but who knows. Which itself >>>> would >>>> be crazy that just a manpage would trigger this kind of intense build. >>>> >>> >>> Indeed, it's py-sphinx, requiring py-openssl at some stage, which is in >>> turn requiring py-cryptography which needs rust. >>> >>> DEFAULT_VERSIONS+=pycryptography=legacy >>> >>> in make.conf fixed this BS for me. Beware of the dogs, you might get >>> bitten by software that requires the new py-cryptography - I did stumble >>> over py-certbot and py-awscli for example. >> >> py-cryptography was kept at an old version for a long time, for various >> reasons, the new mandatory dependency on rust being the main one. >> >> But that old version does not work with OpenSSL 3, so the update of >> OpenSSL in FreeBSD 14 imposed the update of py-cryptography. >> > > And yet I remember a proposal that would have prevented this requirement > on one of these lists. Separate base SSL from ports SSL. Force ports to > use ports SSL and prune back base SSL to the bare minimum required for > base. This would have given FreeBSD the freedom to try alternative > things like LibreSSL. It was proposed when the "upgrade" to Openssl 3 > delayed the release of 14. > Great idea, we now only need to see the patches to base and ports allowing this to happen. Test them, commit them... 14.0 has already been delayed long enough. >> This is the perfect example of why I say: >> >> - there are external pressures we have little power on (keeping an old >> OpenSSL indefinitely is not an option) >> - keeping old version of software (to avoid heavy dependencies or >> whatever) is a landmine waiting to go off >> >> The problem showed up now because the landmine of keeping an old version >> of py-cryptography in the tree finally went off. >> >> I'm sure there are more similar landmines waiting to explode under our >> feet in the ports tree. >> > > The problem with bending over backwards to accommodate a project that > treats its users with contempt is that they'll overwhelm you eventually. > I'm willing to bet the Python community is at least an order of > magnitude larger than the FreeBSD community. Not sure what project you are talking about. Rust is just s programming language. I am neutral towards rust itself, although slightly annoyed by the time it takes to build it (on the other hand rust is not slow at building things, but most projects compiled in rust are big ones and would take long with any language compiler). That said what is the alternative? (shipping old software or custom versions stripped of rust when we do not have the manpower to actually maintain forks is not really an option) > > The creeping Rustification of open source projects is marginalizing > projects that are already marginal. The brunt of the damage caused by > these capricious changes is borne by communities that are already small. > Those communities have no chance to win if they fight back, but if they > work to adapt to the changes the larger projects are imposing on them > they only accelerate their demise and make hegemony more likely. > > The effort would be better spent in either exorcising the dependencies > that are causing breakage, or fork the projects involved. Yes, these are > work too, but there's a slim hope that if enough marginal communities do > this, the large projects will feel back pressure and become more > accommodating. Yes, it's a small chance. > > I know myself well enough in my advanced age to know I have a sometimes > unhealthy instinct to swim against the current. Take the above with a > grain of salt, but I suspect that if you're using FreeBSD we may share > some of the same instinct. > I used to have that kind of instinct when I was much younger. The instinct is partly there still, but I have learned to evaluate if I am fighting a current I can manage, or a stronger one that will swipe me away anyway. You say we "bend" to rustification, but the way you suggest means ports should bend to anti rustification, by removing features causing rust dependencies, pinning software to old versions, and so on. This would make the ports tree less useful for a lot of users. We would end up with old packages. Not something we can force on all the user base. On the other hand you suggest forking projects, but we barely have manpower to keep the ports updated as is. Let alone actually develop the ported software. Anyway forking can be done outside of the ports tree. Nothing stops you from forking, say, librsvg and keep your fork updated and at feature parity with the rust version. If this is your battle you can fight it outside of the ports tree. I'd add that the "ports" tree is just that "ports" not the place for forking or original development; we port what outside projects deliver with as little judgment as possible, for the users to use. A ports tree is not the proper ground for this battle. -- Guido Falsi <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bdb3f9a-6591-d7ac-87d9-334b4595411c>