Re: dns/bind916 builds rust unexpectedly

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