Re: Deprecating non-functional SHAREDSTRINGS build option and xstr(1)

On Wed, 24 May 2023 at 06:15, Robert Elz <[email protected]> wrote:

> But that's an entirely different thing than the programs (mkstr and xstr)
> being removed.    Further I see nothing in mkstr.c which would in any way
> "not work", and cross-build support for it should be no different that
> for cat or ls (or any other random program) and as we cross-build almost
> everything (except perhaps amd64 usually) I very much doubt that either
> mkstr
> or xstr are failing.
>
> That's quite different that using then as tools in a cross-building
> environment though, I can't see why mkstr would be a problem even there
> though, but xstr might be.
>
> So, no objection at all to SHAREDSTRINGS being removed (which I think has
> already happened) - but I still see no rational reason (beyond "I don't see
> a need for it") to remove the programs from the system.
>
> I don't share your belief that the src repo benefits from having crufty
programs taking up space in it, not to mention the cycles spent building
the damn things. We burn enough energy as it is on things without having to
keep useless stuff around.

If you want to be able to access the superfluous software, move the
superfluity to othersrc or pkgsrc (pkgsrc having the advantage that these
programs would then be available to users of other platforms, not just
NetBSD). We've done that before with window(1), which I consider a much
more useful program than mkstr or xstr - I like it, but still think it was
the right decision to move to othersrc.

The danger with using the src repo as a dustbin/trashcan is that the
rubbish pollutes the rest (and that src repo has some gems in it that
aren't available elsewhere). Plants in a garden don't thrive unless
weeding, pruning and active management take place all the time - and the
whole garden is all the better for that.

agc