Theo de Raadt wrote:
> 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.
I understand that there may simply be nobody with commit access who is 
interested in maintaining these packages. If that is the case, then 
obviously they should not go into the ports tree.

But if someone is willing to maintain them, I do not really see what is 
inherently wrong with providing an alternative.

My idea is that this would remain entirely optional. For example, if 
uutils coreutils is already installed, a port that requires 
GNU-compatible coreutils could treat that dependency as satisfied 
instead of forcing the installation of GNU coreutils. The same idea 
would apply to the other uutils packages and to brush that I have proposed.

I am not suggesting that these implementations should silently replace 
the OpenBSD base utilities or become the default. They would simply be 
another option for users who deliberately choose them.

At the moment some of these projects are still experimental and are not 
completely compatible with their GNU counterparts. I agree that this 
limits where they can safely be used today. But for people who 
explicitly opt into them, I do not think the mere existence of 
compatibility differences is a reason not to experiment with them. Over 
time I expect those differences to become smaller, especially given the 
amount of interest in this from companies such as Canonical and Microsoft.

That is really all I mean by this. I am not trying to impose anything on 
OpenBSD or replace its own utilities. I just think there is value in 
having the option to choose an alternative implementation.