Date: Tue, 26 Sep 2023 17:28:30 -0700 From: Jose Quinteiro <freebsd@quinteiro.org> To: ports@freebsd.org Subject: Re: dns/bind916 builds rust unexpectedly Message-ID: <1b5ad463-0793-74b8-efbf-55f1a96257b9@quinteiro.org> In-Reply-To: <ddd1e417-cdbd-f76e-ec92-293251b85c85@madpilot.net> References: <202309260653.38Q6rISB011933@nuc.oldach.net> <6d9121e9-87ac-1a2a-3cb8-b9bccaab4e96@FreeBSD.org> <646911f3-be02-c078-2833-f8af04299af3@quinteiro.org> <ddd1e417-cdbd-f76e-ec92-293251b85c85@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/26/23 09:14, Guido Falsi wrote: (snip) >> >> 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... > This was not my idea, it was presented by a member of the Core Team.(1) > 14.0 has already been delayed long enough. > I do not question the decision to "upgrade" OpenSSL instead. I have put in neither the time nor the effort to have an educated opinion on this. >> >>> 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 beg to differ. It's a large runtime that changes quickly, a package manager and build tool that create enormous binaries from even tiny pieces of code, and the answer to all your problems, according to some. In any case, I was talking about py-cryptography in particular, and Python in general. > 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). > I was neutral until it started consuming more and more time and resources on my Poudriere builds, and until I tried to write a simple program to query a Mysql database. I'm also wary of the fact that it appears to have tied us to the FreeBSD 11 ABI forever(2). > That said what is the alternative? > Why do I need an alternative? >> 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 never suggested doing this in the ports tree? The only change I mentioned was to base, and that was not my idea as I pointed out above. > > 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. > (1) https://lists.freebsd.org/archives/freebsd-arch/2023-April/000353.html (2) https://github.com/rust-lang/rust/issues/89058
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1b5ad463-0793-74b8-efbf-55f1a96257b9>