From nobody Wed Sep 27 00:28:30 2023 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RwHXQ07n1z4vrVJ for ; Wed, 27 Sep 2023 00:28:38 +0000 (UTC) (envelope-from freebsd@quinteiro.org) Received: from mx2.quinteiro.org (mx2.quinteiro.org [71.19.154.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwHXN0NXgz4Q8c for ; Wed, 27 Sep 2023 00:28:36 +0000 (UTC) (envelope-from freebsd@quinteiro.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quinteiro.org header.s=default header.b=v2HhAJ2f; spf=pass (mx1.freebsd.org: domain of freebsd@quinteiro.org designates 71.19.154.200 as permitted sender) smtp.mailfrom=freebsd@quinteiro.org; dmarc=none Received: from www.quinteiro.org (www.quinteiro.org [204.109.56.22]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx2.quinteiro.org (Postfix) with ESMTPS id 4ECA721D9A6 for ; Wed, 27 Sep 2023 00:28:33 +0000 (UTC) (envelope-from freebsd@quinteiro.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=quinteiro.org; s=default; t=1695774513; bh=9CIGGHDGJT70Zpj+16EIPdCHljxdDrdnCi3h3tRmp/U=; h=Date:Subject:To:References:From:In-Reply-To; b=v2HhAJ2fQ6ky/ZZrw1xfptRvDqr7+GPq7OJwLjsB4qIxtXW8TauCbNAg1jauqtXvc YryYNFVroxzKq3Jetg4vfTHegPQUlSapDX2sOWJtFq6IRJtwh76uv/4kXuBenPpVDD 3bX7RaXfE4xSmAgy3dWG6Yk2ASxaWdD/Z1zDHG5E= Received: from [172.16.1.231] (157-131-78-27.fiber.dynamic.sonic.net [157.131.78.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by www.quinteiro.org (Postfix) with ESMTPSA id C868C2EDC0 for ; Wed, 27 Sep 2023 00:28:31 +0000 (UTC) Message-ID: <1b5ad463-0793-74b8-efbf-55f1a96257b9@quinteiro.org> Date: Tue, 26 Sep 2023 17:28:30 -0700 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: dns/bind916 builds rust unexpectedly To: ports@freebsd.org References: <202309260653.38Q6rISB011933@nuc.oldach.net> <6d9121e9-87ac-1a2a-3cb8-b9bccaab4e96@FreeBSD.org> <646911f3-be02-c078-2833-f8af04299af3@quinteiro.org> Content-Language: en-US From: Jose Quinteiro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[quinteiro.org:s=default]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[quinteiro.org:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[ports@freebsd.org]; ASN(0.00)[asn:47066, ipnet:71.19.154.0/24, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[quinteiro.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4RwHXN0NXgz4Q8c 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