From nobody Wed Sep 27 07:52:49 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 4RwTP11CpSz4v5tv for ; Wed, 27 Sep 2023 07:52:53 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RwTP10fmnz3FWY; Wed, 27 Sep 2023 07:52:53 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695801173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=hQUzO09bCVF3RA+cYODiZuOV1J7yeX5/FaKG4qQmpaM=; b=I2JK5ETCuYfzT14QvjodPQ7Jtd7jh7XBEInNBfcQii/D6bYh4ELh1zkskyKZsHsktEaYBz qTdhXiU8gAmFsGdeQ+0o9St+JeYuj3LWDPaSvUPJyIVDULIPsYuuNUlR2bMjYkK8B9xm5w HOkwPm50Xffmh/+R93UgEAuz+wx/6D+HqXbv64ucDbqCyLKTCdSWVtkD1fARTQaEu0Ginb cYhy3K7GzjGYtGdsMJITXls2rVYxOB0vyHPXKOLLnOIY/RzCiQ00IonU9hXX4Ba0F/22Y2 o5rjVe7P9Shq7EnnobJWHqb3N51Cm7+panjw9SxKYKympuXkKxbbqurIb0eDlg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1695801173; a=rsa-sha256; cv=none; b=QLM09ZCucCj8/YeF0NI8gLkdmaVZuKlUpZ/XMFt/nnYVxKGqW853rb9J1Rjkshgc4lR9HQ rxKO+oNZEGhzY7tD1bCOBcitWVl8PJKjFShZXpp8XJmHhzOiLUvN/wvH6+4petrUgOA7Ad z2r1ehU6VMIZcFaqz99hZJG0no6h/v4FM41KKIvbY47HQ+ac+7n6H74Hz1fTlhLDrUpCV3 NyAtiZB3TC1gLIWOyRTVULd2i/slOd1E/iHEFl65bQFOEToXdeMDiwrinVSLoYpJf00cHd W1ISCpPQva9SD6YBeA51uUNiZNFpAMvHkujLIxofQ0Ly1Rj5Do1Hw2toRuw7tw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1695801173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=hQUzO09bCVF3RA+cYODiZuOV1J7yeX5/FaKG4qQmpaM=; b=YgvqXq/l1Yx1wxFtJ1/hRvzFDob/L4WcZvRjYzWT5HSVWHovpPpxxcsqHt30UnpE+VlV18 M46XExc/qlvJ085Pt3yJh5zGEEgNNJprnqW33ez5skd0ezeJaKXbkEJChoAn4DDlUgQmpf X8fhCvNQP8Q22lj1SOarStIJSm+bzgwkZwr6a8y6aCKJXzJGYfsil0z2WMH7Fc2Nw80EkC I29h8lPMZpAHyxJZpKL+vk6oJvO/L3hurdEEDQzKZ/uz19QtkAYcqBxQqMP8LZhOKPah+O hP0KmNtTnYe1aYAs1v1ISnszYwO1Cd0ujdeqY6JIDr4ZXdWSKzFOlt5pZgDISg== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RwTP04PWbz1359; Wed, 27 Sep 2023 07:52:52 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <1e6c5140-e4e1-49ed-b377-4fc690738687@FreeBSD.org> Date: Wed, 27 Sep 2023 09:52:49 +0200 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 Thunderbird Subject: Re: dns/bind916 builds rust unexpectedly Content-Language: en-US To: Jose Quinteiro , ports@freebsd.org References: <202309260653.38Q6rISB011933@nuc.oldach.net> <6d9121e9-87ac-1a2a-3cb8-b9bccaab4e96@FreeBSD.org> <646911f3-be02-c078-2833-f8af04299af3@quinteiro.org> <1b5ad463-0793-74b8-efbf-55f1a96257b9@quinteiro.org> From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeAQTAQIAIgUCT4b6XQIbAwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQGuaGDlbL0pOWigf/YVTVf3+ZRnzeGP7CjGV1 Wrrxzjc8h8W64NZasV0XLHGFjl5MYwtm9jJ9gbL8Ubtqstey7lYpjOk2fG6YDhY5eptWCpR6 1QqYrioukhCfKbodSk6PnIZcx719nJVK2P7ihdFEN78TavpBwqIf9hGEcKkMpbRFQv1mYvXD hKVwQGY+8bkH/a/pAWmIyD4qMfKCMurH5DexxEt5SYWu5BB5hd/DWyZ0wuZ+F79KMPzLBPJW 5cpdLNbrvenSqFZGJEGhtTp7GFJJr6lTy8VLBArxmFHiY5jGyR45eZEGDcz86FfGgvPnnpi7 aNCc/ROdF7fnZYPh8uZGGjQbd4EYK4xMzc7BTQRTEHtBARAAoWGsNx6g90r8gcNKaiPpJBiK y8ztV2FyV5LsT0OgQBW3vIxt/odtsxVNNjpyS/BNZCyzLAsFc1WrGBzhYsmPN9SGB5/5YTvk zf5YViU5VAsZlj/MRWCZrWtpic4c0A7N4csOYReNtk/q8YB4PIFsZ9A+kTuoZhnu5t5PdfBA 74+SVwKu84+PZk9wDEY1LbFVT8vM42oKsmoswlIhwJ2xuJI/gbk+cMUe0yiRpNjo4Svw4RB8 4B6uFwdRr/PtS7xi2Zqoof5AaQT9YSBpGpKJOe/Qk5MP4PF6Fqq+go89n77Y2kJkwcHaLoD/ GJ+ZDASIiMRe1y54FHOQ1RCTGGpnJLXdKuGhwv3J21pU8HNlq0ASNQMMQmYAwtUWzjmp/KEy I1qkcmjafcxb8TmiaoK8SQN1Zf96fc/sIrZN6Z5oOCEyyCQ0prH/PTA2jlRkKQ487PTGk2JS KU5VuS57Nlk2DrnvjWp57aV9eFAhpnrrJPuGmFz83/Pc8gC0t7N7i7VVHYRcC5naxYB2UoI1 OUkyxpT/HvQFXXVZ3/KmdXMzrx191AggCPWIwUAP+VcaURSYpeDk6/ZVAOVOe1ChqcJisCD7 wK20/OOvJ2AtkWreGu1CZ9zSx7nK/VYdLr34GxQ4bT1G+9rBQNnFSNbX2TJ431Mdo1GCjDeR K4CtSnrNKYkAEQEAAcLAXwQYAQgACQUCUxB7QQIbDAAKCRAa5oYOVsvSkw3nCADhsKRf+rAR ULTpOh5HoLam62ZJZAyCkNqqu/rke5uj5AaaDY/h7BNhBDiDqhhZLTeofGpVVaErPsWN+tX5 0fypsIt9KAhy90GFrtrIZlWuyK4wsoZvDfp9yaRk+lIM58dw/Rcfxn670JaPTFSRPECVn/uL qBhJSkbYlY212YT9fxVUTJe6wIvDLQrQEjrQD/h1FMhfcLhAqsndltRd6DPvTKeMd/6VAxn0 hkoBKhEy5LkWjM9CHppu+bBkQ91/kj2uJQSXO8euonwHHS3c+6N2i2H7I0emcHGu07wuRB2t Dnw/RLBxohffdPZT2kbxuG7lhVHzwVDw5DRwSw8GkOdy In-Reply-To: <1b5ad463-0793-74b8-efbf-55f1a96257b9@quinteiro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 27/09/23 02:28, Jose Quinteiro wrote: > 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) I was simply stating that ideas and practice are two different things. For the idea of moving ports to ports only OpenSSL there were some big problems regarding ports crossing the boundary between base and ports (can't link to two different SSL implementations at the same time) and the need of a lot of testing and work. There simply was not enough time in the 14.0 rleease timeframe. It can still be done though, nothing is lost. >>> >>>> 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). This can change, anyway. Also, the thread you linked shows the proposal was formally accepted, let's see how things evolve. > >> That said what is the alternative? >> > Why do I need an alternative? Yes you do in the sense that one need to do one thing or some other thing between two or more options. Regarding "rustification" the options are, we upgrade ports of software being moved to rust or gaining rust dependency (which is what we are doing and I think is the correct thing for a ports collection that has no role being judgemental about the ported software). Or we do something else. For example we abstain from upgrading software that moves to rust or gaining rust dependencies (keeping the last non "rustified" version). [1] Or we do something else that I have not thought about. (I'm not trying to trap the discussion in a false dicotomy, but I see no other possible courses of action) In other words, what are the options we have? [1] I also think this is wrong for the ports tree because it's giving value judgements about ported software which is not the ports tree role and would be a bad service to all users except the ones which strictly agree with such value judgement > >>> 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. > Actually the change you mentioned is to both base and ports, I stil lthink it would be a good idea, but requires time and a lot of work/testing. Also that proposal can be applied and has no real relation to rust. It is a good proposal in itself. It would only marginally address the rust issue. BTW (I have not thoroughly checked or tested this) we do have a DEFAULT_VERSIONS= pycryptography=legacy flag, and latest head (and 14.0 I guess) should have compatibility shims to make it work. Not sure it does actually work though, just an observation. -- Guido Falsi