main/postmarketos-base-ui: add coreutils as dependency

People running UIs should not have to depend on basic utilities from busybox such as non-portable /usr/bin/env. Total size is 1176KiB, which should be marginal compared to any UI installation.

This came up in a discussion with @sonnyp, related to this issue[[1] in an app he maintains. Like really, we should not be starting something with busybox to save 1MiB

[1] https://github.com/sonnyp/Tangram/issues/236

changed the description

By Pablo Correa Gomez on 2023-02-15T10:28:23

All of these apps will still have to be fixed if they are from aports like tangram was fixed here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/44251.

By Emi Vasilek on 2023-02-15T11:08:32

I'm not opposed to this personally but I have serious doubts this will get through.

By Newbyte on 2023-02-15T11:54:58

Coincidentally we have a team meeting tonight, so maybe we can discuss this then.

By Newbyte on 2023-02-15T11:55:53

Like really, we should not be starting something with busybox

i assume you mean "implementing -S in busybox".

well, there should be no issue with that theoretically... it's not like busybox is a "posix toolkit". none of the utilities are posix to the letter. and this specific thing (-S) doesn't sound that complicated.. people implement tiny things like this all the time in busybox :p

maybe you see it as "starting something with busybox only to save a paltry 1MB", but the same applies to literally everything else thus far. this is not the first busybox-related mishap, nor is it different from the 50 million instances of needing to work around a lack of systemd or glibc or or or specifically. and it will only be useful here downstream wise (for downstream packaging), because i will explicitly not allow "just depend on coreutils" for misc application in aports- it's only a last resort where there's no real other way (incidentally, fmt is quite common, so maybe i should make a standalone fmt..).

so unless this will fix something specifically in pmos-only packaging, it's actually 1MB for nothing- if a package from aports didn't work without this, it was actually an aports bug, and we would fix it there. what scenarios does this help in, if not that?

By psykose on 2023-02-15T18:24:08

For the record, I have spent the whole afternoon and part of the evening trying to implement -S in busybox, with no luck. I'm surely not the best programmer, but not sure this is a tiny thing to implement... Also sxmo-utils already depends on coreutils.

This is getting a bit too much for me anyway, so I'm letting you decide and stepping away :)

By Pablo Correa Gomez on 2023-02-15T17:50:54

added discussion label

So at mentioned team meeting we discussed this, and concluded:

• we want to stay compatible with alpine, all our packages should build fine without coreutils (unless you need it as last resort as @psykose described above)
• these small size increments add up, it's good to keep the overall system size low. if we said we install coreutils, next would be "less", pciutils, ... - there are a lot of tools that busybox replaces where we could install the "proper" version.
• it doesn't matter for casual end users who won't use the terminal, and advanced users who open the terminal should be able to just install coreutils (or man pages or whatever bloat floats their boat). feel free to add a section on installing coreutils / more busybox replacements in the cheatsheet (this is linked in the motd message one sees when connecting via ssh)

By Oliver Smith on 2023-03-04T07:00:20

@ollieparanoid so should this MR be closed then? Or is it kept open for confirmation / additional input from @pabloyoyoista ?

By clayton craft on 2023-03-04T07:00:20

closed