<illiliti>
if you want to avoid hardcoding a list i have a better idea
<illiliti>
we could make /var/db/kiss/installed repo-aware
phinxy has quit [Quit: WeeChat 3.5-dev]
<illiliti>
i.e install/copy packages to /var/db/kiss/installed/<repo>/<pkg> instead of /var/db/kiss/installed/<pkg>
<illiliti>
this way we could fetch core packages at runtime
<illiliti>
and exclude them
phinxy has joined #kisslinux
<testuser[m]>
Hmm seems too intrusive, and now it requires hardcoding the repo "core" instead of the name of a meta pkg. someone could have gnugrep set as their *grep but it's in extra/ repo so
<illiliti>
metapackages install dependencies that i don't want. without provides system they are even more distructive
<illiliti>
i have had a bad time with them on other distros. i would prefer to not have them at all
<illiliti>
let's keep things simple and just document when needed
<testuser[m]>
I mean it would work like by default kiss would have a meta core package installed which includes baselayout, busybox, openssl, musl, gcc and whatever else. If someone switches their coreutils for example, they'll override the meta pkg with deps as toybox, gnugrep etc instead of busybox
<testuser[m]>
But it's clunky without provides
<testuser[m]>
For sandbox alone it could be solved by testing owners of a hardcoded list of posix specified utils but meh
<wael_>
what us a use case for a meta package, just to have many packages bundled together at installation time?
<wael_>
provides system can only get so useful
<testuser[m]>
What
<testuser[m]>
It's for grouping pkgs
<testuser[m]>
Here it's group of pkgs that all pkg assumed are installed at build time
<testuser[m]>
assume*
teddydd has quit [Ping timeout: 260 seconds]
<testuser[m]>
gcc, openssl, make etc. assumed
<testuser[m]>
Now for a sandbox you only want to allow access to what the pkg explicitly requires
<testuser[m]>
It can't explicitly request gcc or openssl cuz someone could be using clang or libressl
<testuser[m]>
Ignore openssl part, that's mentioned in depfile
<testuser[m]>
say busybox vs toybox
teddydd has joined #kisslinux
<illiliti>
wait perhaps just having provides system solve this problem?
<illiliti>
one would have to hardcode provides names tho: e.g ssl, cc, make etc
<testuser[m]>
Yeah
<illiliti>
but it still better
<testuser[m]>
But why not have one pkg to provide all those instead of individual
<testuser[m]>
They can be made a bit more general ig, like toolchain, coreutils
<testuser[m]>
But every pkg needs them so i don't see a point
<testuser[m]>
in splitting
<testuser[m]>
Like there's no pkg that needs gcc but doesn't need cp/mv
<illiliti>
because individual is more explicit than opaque meta package?
<illiliti>
look, the fact that we hardcode core packages is a temporary
<testuser[m]>
There should be a limit to explicitness else it'll become a mess
<illiliti>
when we get provides system core packages are no longer explicit
<illiliti>
implicit*
<testuser[m]>
Like if you wanted to go super explicit you could have a provider for every single command
<testuser[m]>
say for the cc package, does that include ld, strip etc
<testuser[m]>
If so then it should be called toolchain
<testuser[m]>
Which introduces some opaquenes
<illiliti>
can't tell now
<illiliti>
we need to have a clear picture which packages should be converted to provides
<illiliti>
then i can tell whether metapackage is viable or not
<illiliti>
maybe there's some way to abuse provides system to implement groups
<illiliti>
if such exists i would prefer it
<illiliti>
btw
<illiliti>
there's already a request to make gmake explicit
<illiliti>
how with your toolchain approach it would look?
<illiliti>
fuck my net
<illiliti>
slow as shit
<wael_>
I wouldn't fuck a router
<testuser[m]>
User would override (or provide) the toolchain meta pkg with deps set to bmake instead of `gmake`, and pkgs that explicitly need gnu features would depend on `gmake` instead of not having any mention of make at all
<wael_>
like base and base-devel?
<illiliti>
if package need posix make, would it still depend on toolchain? assuming that toolchain depends on gmake
<wael_>
maybe a check at build time?
<wael_>
idk anyone who uses posix make
<wael_>
I doubt it would work with most packages a system needs
<illiliti>
i use and strive to write Makefiles compatible with it
<illiliti>
hm wait toolchain could depend on provided make instead of gmake
<illiliti>
and package could explicitly depend on gmake
<illiliti>
sounds like a big headache to implement it properly in dependency resolver
w1ke has quit [Ping timeout: 260 seconds]
<illiliti>
yeah these nested levels of provides would drive me mad