David Uhden Collado wrote:
There is no agenda here.
There is.
My goal is simply to have alternatives for
^^^^^^^
software that already depends on GNU utilities in order to work
correctly on OpenBSD.
I have always found it somewhat unfortunate that some ports need GNU
^^^^^^^^^^^^^^^^^^^
coreutils, bash, or other GNU utilities rather than being able to use
the base system tools. Where those dependencies cannot reasonably be
removed because the software genuinely relies on GNU semantics or
extensions, I think having another compatible implementation available
^^^^^^^
is useful. It is simply about having a choice.
It is simply about a choice YOU WANT, and you think other people
should let it happen.
I am not suggesting replacing OpenBSD's base utilities, nor do I want
subtly different implementations appearing unexpectedly in users'
normal workflows. That was never the objective. The intended use case
is specifically software which already expects GNU-compatible
utilities and currently depends on the corresponding GNU ports.
But you are suggesting providing an alternative, which other people
need to also invest time in maintaining.
And they will have subtle differences in workflow.
And they will be compatible with non-standadized decisons
for GNU behaviours, and incompatible with OpenBSD non-standard
specific for our behaviours.
And you want that. That is your agenda. That includes other
people investing effort into also maintaining this ones it goes
in the ports tree.
Besides coreutils, there are other projects reimplementing GNU
software in Rust under permissive licenses, such as other uutils
projects and brush. They are not yet 100% compatible with their GNU
counterparts, so I would not claim that they are ready to replace them
everywhere today. But I expect compatibility to continue improving
over time.
Come on stop it. OpenBSD is a consistant system with it's own
choices, and you don't find OpenBSD ls and grep utilities on Ubuntu.
And no, my interest is not simply "because it is written in Rust."
Rust is relevant to the packaging because it determines how the port
has to be built. The implementation language itself is not the
objective.
There is that word "objective".
I also do not understand the hostility towards these projects.
It looks like you are trying to convince other people to accept
your agenda and put labour into making it happen.
If the
concern is that AI or LLM-assisted development may have been involved,
that is a separate discussion from whether the resulting software is
technically useful, compatible, maintainable, and suitable for ports.
What?
LLMs can substantially reduce the amount of time required for some
kinds of software development, including work that would previously
have required much more manual effort. I think the sensible way to
judge the result is by the code, tests, compatibility and maintenance
quality rather than by assuming that the development method itself
makes the project undesirable.
What?
In any case, I would rather keep that discussion separate. My interest
here is much simpler: providing additional permissively licensed
alternatives for ports that already require GNU-compatible tooling.
What?
OpenBSD is a consistant base system developed by a fairly small group
of people, with a select porfolio of upstream software adapted to
work on it as packages, by another small group of people.
These people don't make everything work. Important things are
selected.
You believe you have identified something more important than the
other things the ports developers continue to work on and argue
towards that, and I think you are wrong. I believe you want others
to invest time along your agenda and that is not fair.
