Re: [dev] [sbase] Defining scope of sbase and ubase

From: Mattias Andrée <maandree_AT_kth.se>
Date: Sat, 9 Mar 2024 00:59:15 +0100

On Fri, 08 Mar 2024 23:33:12 +0100
Eolien55 <eolien55_AT_disroot.org> wrote:

> Страхиња Радић <contact_AT_strahinja.org> wrote:
> > The problem of having separate *box executables could be solved by creating an
> > "umbrella" *box project, perhaps having sbase, ubase and [insert_letter]base as
> > git submodules, and deciding what to build based on the contents of config.mk.
>
> The problem is that sbase and ubase each include a version of libutil, whith some
> functions which are the same, and some other wich serve the same function but
> vary in implementation due to version history.
>
> git submodules are kinda meh I think for this problem, because it wouldn't change
> the problem of source code duplication (and of versions drifting apart) between
> the 2 projects, as libutil is part of both sbase and ubase trees (not mereley the
> umbrella-box project).
>
> I believe we should put what are currently sbase and ubsase in a single git repository,
> sharing all that is portably sharable, but still separating utilities that are portable
> from linux-specific ones.
>
> I think sbase and ubase should try to provide useful, well-implemented, suckless
> utilities. If we want POSIX utilities, let's add them! But I don't think we should
> restrain us from doing that. sbase's sponge and cols is so useful I'm constantly
> using them, even though I normally use busybox.
>
> Regards,
> Elie Le Vaillant
>

I agree, a single repo (or alternatively making libutil it's own repo) is
necessary if we want one binary, and I think we do.

Even if submodules was possible, I do not think they are a good solution.
Using submodules is unpleasant and pointless since all could is under our
control. I think submodules should only be used for code that you do not
have control over but need the source code for. Either you have separate
repos and have normal compile time dependencies (require that the libraries
are installed) or you put everything in one place, one repo.

I see the separation of sbase and ubase into two repositories as basically
equivalent to the a single repo with a sbase directory and a ubase directory,
except better when it comes to tagging new versions, but since there reason
to have separate releases for these, it doesn't really make a difference.
So simply putting sbase and ubase in two different directories in the same
repo, and then put a makefile there to build all of it into one binary would
be step up, of course there would be some linkage problems and making them
share libutil would be the next step up. Of course, it should be possible
to select if you want ubase included in your binary or not, is the point
of the separation in the first place.

I think there should be one directory called "portable" containing only tools
from sbase, and one directory called "linux" containing the tools from ubase
and maybe even symlinks to the tools in "portable". This structure would allow
us to add implementations for other operating systems as well. If we add
symlinks to the tools in "portable" to "linux", each directory could have
it's own makefile. But I'm not sure this is preferable over a single Makefile
in the root directory.

As mentioned in an other branch of this conversation, I think we should
have a base with only the POSIX tools but than have additional optional
tools, which could be group into overlapping categories, as you can select
what you want on your system.


Best regards,
Mattias Andrée
Received on Sat Mar 09 2024 - 00:59:15 CET