<ukky>
farkuhar: It could be the case. But also I should have rebuilt previous sysvinit package with no /sbin/init to avoid collision, thus my 'db' should not contain /sbin/init under sysvinit entry.
<farkuhar>
I need to revisit the db_find_conflicts function in pkgutil.cc; maybe it was incorrectly concluding that /sbin/init still belonged to the previous installation of sysvinit, even though ukky created a new port that should have claimed ownership of the file, symlink or no.
<ukky>
btw, I also uninstalled sysvinit on my PC at home, after PC at work got borked. And PC at home did reboot properly, with no sysvinit installed.
<farkuhar>
I guess it depends on which port was installed most recently, when you force the installation with `pkgadd -f`. If it was the sbin-init-runit package that was most recently added, then the db should have assigned ownership of /sbin/init to that runit port, deleting the existing association between the file and the sysvinit package.
<ukky>
PC at work has bad RAM and triggers a lot of bad I/O. After reboot, System BIOS sometimes displays error screen with memory failures, and that could be another reason it didn't boot properly.
SiFuh_ has quit [Remote host closed the connection]
SiFuh has joined #crux-social
zorz has joined #crux-social
zorz has quit [Quit: leaving]
zorz has joined #crux-social
ppetrov^^ has joined #crux-social
ppetrov^ has quit [Ping timeout: 252 seconds]
ppetrov^^ has left #crux-social [Leaving]
ppetrov^^ has joined #crux-social
SiFuh-Japan has joined #crux-social
<SiFuh-Japan>
The people outside the city are way nicer and more social than the pricka in Tokyo
<SiFuh-Japan>
Pricks*
SiFuh-Japan has quit [Quit: Client closed]
SiFuh-Japan has joined #crux-social
<SiFuh-Japan>
there is a bar near here
SiFuh-Japan has quit [Quit: Client closed]
ivandi has quit [Quit: WeeChat 4.5.1]
ivandi has joined #crux-social
<ppetrov^^>
"please show me the way to the next whickey bar..."
ppetrov^^ has quit [Quit: Leaving]
ppetrov^ has joined #crux-social
<farkuhar>
ukky got me curious about bad I/O ... could the PC at work have a corrupted package database, where `pkgadd -f` did not have the expected effect of transferring ownership of /sbin/init from sysvinit to the sbin-init-runit port? I find it hard to believe that bad RAM could corrupt the file on disk so dramatically.
<farkuhar>
`sort /var/lib/pkg/db | uniq -d | grep -v "/$"` should show all the duplicate non-directory entries in the package database. It's amusing to run that command and see all the "$version-$release" strings that multiple packages have in common. Other than that, you shouldn't expect to see any filenames in the output.
<ukky>
farkuhar: That system has ECC RAM and I see errors in the dmesg log. Also, RAM errors are reported in System BIOS error log. I don't think those RAM errors affect disk I/O operations.
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
SiFuh-Japan: with (ba)sh it often takes a human reader to identify a useless loop in our scripts, as zorz did for one of yours. In the Rust ecosystem, the compiler itself issues helpful warnings like "irrefutable `if let` pattern; note: this pattern will always match, so the `if let` is useless; help: consider replacing the `if let` with a `let`."
<farkuhar>
On the question of why CRUX chose to use "big guns" (bash) to execute tiny boot script, maybe we should consider that bash was not such a "big gun" at the time the rc-scripts were originally written, and only acquired cruft over the succeeding two decades. The current bash maintainer hosts a ChangeLog that goes back to 2002, when CRUX was still at version 2.*
* farkuhar
triggered IRSSI's auto-truncation feature again
<farkuhar>
Search the bash ChangeLog for instances of "array" and you'll find some fascinating history of how this feature has evolved. At the time of bash 5.0, for example, they started allowing array subscripts to consist entirely of whitespace.
<farkuhar>
When bash was going through 5.1-alpha to 5.1-beta and 5.1-rc1, it became possible to initialize associative arrays using an idiom borrowed from Perl: a flat list of alternating key-value pairs.
<farkuhar>
Starting with bash 3.0 it became possible to assign array elements using negative indices, and it would do the sensible thing by counting backwards from the last element in the array. CRUX 2.1 was already in the works by then, but did they leap at the chance to use negative subscripts when processing the Pkgfile source array? Probably not.
<farkuhar>
On 2009-02-20 bash 4.0 introduced associative arrays, when CRUX was at version 2.5, but none of the CRUX-specific tools started taking advantage of this new bash feature. Years later, Alan would propose associative arrays as a way to rename downloaded sources.
<farkuhar>
The bash 4.0 changes also included some bug fixes in the expansion of $@ and $* when IFS is the empty string. Handling user redefinitions of IFS has apparently been a common footgun over the years, with script authors and even bash maintainers not anticipating pathological choices by the end user of the script.
<farkuhar>
To recap: bash has grown into its current form of "big gun", it didn't have all these additional features when the foundations of CRUX were being laid. It did offer basic support for (non-associative) arrays, which CRUX founders were all too happy to use for the Pkgfile source variable. That choice served as a "gateway drug", and they readily adopted the same feature for the rc.conf SERVICES
<farkuhar>
variable.
<ukky>
It would be wrong to use bash-specific features in Crux Pkgfiles. What if some user would uninstall bash and install some alternative shell they prefer more than bash? Especially when there is no explicit bash dependency specified for Crux core and opt ports.
<farkuhar>
ukky: The syntax for the Pkgfile source variable is already specific to bash. If you want to define an array in oksh, it requires a different syntax. The reason they don't declare a bash dependency is that bash is a core port, and the user is expected to have all ports in the core collection installed.
<ukky>
ah, forgot that all core ports must be installed...
<farkuhar>
It is allowed to list core ports in the dependency line if they're dynamically linked in, but bash is merely a runtime dependency for executing pkgmk, hence there's no explicit "Depends on: bash" where pkgutils is concerned.
<farkuhar>
On the question of whether it should be a supported use-case to have /etc/rc.conf parseable by other shells, one pushback you might get is that it's more consistent with KISS to have a one-to-one relationship between config files under /etc and the tools that source them. Hence rc.conf governs the behaviour of CRUX rc scripts, and if you want to govern the behaviour of your own runit files, you
<farkuhar>
ought to create a separate file under /etc.
<farkuhar>
I seem to recall a mailing list thread where somebody rejected a proposed name for a config file, on the grounds that the name wasn't suggestive enough to remind the user which tool was being configured.
<ukky>
That's what I did: copy-pasted the whole content of /etc/rc.conf except for SERVICES, and created new config file.
ukky has quit [Ping timeout: 252 seconds]
zorz has quit [Quit: leaving]
ukky has joined #crux-social
<farkuhar>
ukky: Feel free to join me in #crux-devel to argue for dash-compatible rc.conf.