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 <madpi...@freebsd.org>
