@lanodan the issue is that at least outside bsd-targeted software, i don’t really see things calling daemon(), but instead, double fork() + setsid(), and those can’t really be no-op’d
portage is not transactional due to the issue of, you need an updated libfoo, to build the updated nya package, so libfoo is updated, replaces the old version on disk, but then nya fails to build, and the old nya on disk would no longer have the libraries it needs, thus broken
it's the same issue as "nya didn't update" on arch, but gentoo has the safety net of preserved libs
@kimapr@ada not that i know of, it does build with a network and filesystem sandbox, so packages can't poke outside of their $WORKDIR, but it's not a chroot
@kimapr@ada .so reference is a fallback, or, "fuck something went wrong better keep those around for a while"
it's more important on gentoo if you're running ~testing packages because compilation on those can fail, which would leave you with a package still linked to an old dep version
@ada@kimapr i do want to have a virtual build root for packages in my portage impl tbh
not only for transactional updates, but also so that packages in your live system not declared in {B,}DEPEND don’t affect the build (usually due to automagical dependency checks, aka dependency('foo', required: false);)
> Are you sure it's how OpenRC has been thought out so far, or that it's a direction you want to take it in and you can do it without breaking a lot of assumptions?
so far we have, start-stop-daemon that does not care how many daemons you start, and supervise-daemon which technically doesn't care but it uses the same "options" dir which means some settings and values (like cmdline and start time) override each other (which, not good)
tho librc has this rc_daemon api that is meant to manage serveral daemons per service doing pid and cmdline matching, with `/run/openrc/daemons/$service/%03d` folders for each daemon... but in reality i only ever see 001 in there, with the exception of the deprecated tigervnc script (the new script uses symlinks, so different logical services)
so... start-stop-daemon seems to have been written in the past with multiple daemons in mind, while supervise-daemon was written with start-stop-daemon as a base but completely ignoring the multiple daemons
--
as what direction to do from here, i'm not sure. having daemons/processes be 1:1 with services, makes things simpler, but it does take away one "feature" of start-stop-daemon
let's define optionsdir to /run/openrc/options/$service and daemondir to /run/openrc/daemons/$service
i can go either way, if i make it 1:1, i remove the %03d from the daemondir, and it becomes a single unified dir for supervision "runtime" (sockets/fifo), and i simply use /run/openrc/options to store the supervision state (child_pid, cmdline, respawn options, notify-fd settings)
if i make it 1:N, i keep the %03d subdirs per daemon, move all per-supervise-daemon option from the optionsdir to the daemondir/$id, and have the `status` output iterate all daemons and print info for all of them (tho i'm unsure which "runtime" `rc-status` would print in the summary page)
and this is where i'm at right now. current openrc is a mess of "it works, but it also doesn't, depending on the codepath" and my job is to make sense of this mess...
meson: uses pkg-config to attempt to locate a dependency (optionally can attempt that weird cmake format) if that fails, attempt to download and build the dependency from a wrap file, if such file is available if that fails, then it tells the user "can't find dependency"
that's, how you do it. integration with native first, download+build as a last resort
fast, emerging binpkgs shouldn't be slower than binary distros, and resolving dependencies for a system update shouldn't more than a second or so
first class, 3-stage (ROOT != SYSROOT != BROOT) cross compilation support, portage is great at this already, but while trying to build gentoo for the pinephone i hit some pain points i'd like to improve
isolated builds in a clean root, packages and random files in my system shouldn't appear in the build env of packages, *only* files from packages from @system + declared {B,}DEPEND
for now i think that's it, the three major goals
i also want to explore non-host builds, but first i need to understand how gentoo prefix works better
a wannabe hacker just going arounda c gremlingif i forget to cw or alt text please scream at me to, thank you♫♪ And yet we laughed despite it all, at this life which has no meaning at all ♪♫