Ok, I just hijacked my Void system and brl fetched an Arch stratum.

In a post below, someone mentions a problem using the rather old-school Amiga-ish? file manager called Worker.

So having added Arch, I can get access to official Arch binaries and build AUR package sources.... Before I go digging for probably broken old linux games or weird old window/file managers in AUR, what are some cool things specific to Arch AUR, not in official Void binary repos?

I use:

• Debian by default. The old/stable nature means its low maintenance, which I value highly. I previously tried using CentOS for this, but the repo size was so small that I kept falling back to Debian anyways. Debian's obvious downsides of its packages being old can be easily resolved on Bedrock by selectively getting bits from other distros. The downside of dist-upgrades can be resolved by not dist-upgrading the production stratum. Instead, I can either dist-upgrade a copy or brl fetch the new release and pmm world the functionality over. I keep the original stratum around and doing production stuff until I've confirmed the new one is good, in which case I just remove the original and move responsibility over (either with brl rename or brl alias stuff).
• Arch's main repos when I want something new. I usually try to minimize getting stuff from the AUR.
• I occasionally use Ubuntu and Debian Testing as sorts of goldilocks middle ground between Debian and Arch. Before the lib32 shenanigans, I used Ubuntu for games, as I could be confident games were tested against it.
• I've found Void has packages others (outside of the AUR) don't surprisingly often. Its init system is the most obvious example, but also occasional random bits like scron.
• I use Gentoo for things that I'm picky about compilation details. In addition to USE flags and savedconfigs, I have small patches for things like mupdf that Gentoo has been automatically transparently applying to package updates for me for years.
• In the past I've used CentOS for some business/professional software that primarily targets RHEL. More recently I tend to use it to test software I write (unrelated to Bedrock) against particularly old library sets.
• I have friends and coworkers on Fedora, and consequently I keep a Fedora stratum around to test against.
• Since its so small, I use Alpine for quick disposable strata.
• The way Bedrock's build system kicks out binaries for non-native ISAs is a bit unusual. I don't want to maintain a network of physical hardware for each ISA over concerns like having a cheap SBC die and delay a hypothetical important security update. While Bedrock's code can be easily cross-compilied, its dependencies cannot often not, and I found people who do drive-by contributions do not take cross-compiling in mind. Consequently the drive-by contribution would cause me a lot of additional work to tweak for cross compilation. The obvious remaining option is to use qemu ISA translation, but despite admirable efforts from the qemu folks it's rather slow. So I Bedrock'd the problem and mixed bits from different distros: I got cross-compile binaries from native ISA strata so the build goes fast, but non-native-ISA qemu-user mode strata for build scripts and make files so they don't have to be cross compile friendly. I have a handful of brl fetch -a'd Debian and Gentoo strata dedicated to this build system.

Perhaps someone else can, but I can't help you there; I usually try to avoid the AUR. Being a user repo, it's usually less well maintained than primary repos from various distros, which means both that things break more often and slower (if any!) security updates. Since I'm running Bedrock, most things from the AUR I'd otherwise be interested in are usually accessible from some other distro, which lessens the its need.

Generally I recommend coming up with a Bedrock use case before installing it, rather than installing Bedrock then trying to find a use case. Bedrock does have some downsides, and so if you can't find anything it's probably a net loss.

Well, I managed to remember some of the fun things I used to run from Arch/AUR which are unavailable in Void:
BasiliskII (m68k mac emulator), Dungeon Crawl Stone Soup (roguelike in Arch repos), The Urquan Masters (FOSS version of Starcon II in Arch repos), ti99sim (TI99/4A computer emulator), xcpc (Amstrad CPC emulator), xroar (Tandy Color/Dragon emulator).

Most of this--except Dungeon Crawl, which is a big hairy mess on most distros--isn't super-hard to compile natively without resorting strata, but I wanted to try something new and lazy. It seems like there are too many AUR helpers now, but yay works ok. I had no big troubles compiling as long as I make sure to run yay specifying strat arch. (Unsurprisingly, yay won't run otherwise.)

As you might guess, I'm messing around for fun or "pure research" if one must sound industrious. Security is not a concern on this dedicated experimentation laptop. I'm too far from sufficient understanding of Bedrock to even think about running it on a good computer used for important things.

Curious. I dont specify strat before running yay. It runs fine. (... and I've just checked to see I hadnt aliased anything in my fish config for that... not that I see.)

[strikeout]Do you need do this because you have multiple arch-based strata and/or multiple strata providing yay and other parts involved and there's some kind of version mismatch?[/strikeout][Edit:no it wont be that, sleepy notion doesnt fit the evidence cited.]

what's the output when you attempt to run yay without specifying with "strat arch" first?

[edit: afterthought: if yay in PATH, PATH not clobbered by shell config, yay shud "just work", iirc]

--------

To answer your title question, "What do people typically install in a stratum?":

I can't really speak much to people in general,
but for me...
whatever wherever as needs arise.
typically sticking to hijack/init stratum[void]'s packages where possible, especially for more init/de type stuffs. But by no means rigidly so. Whatever reasons on the fly package by package as to which strata will provide it for me.
Though of course, availability plays prominently, and if there's only 1, then it's the 1 (and void's surprisingly well stocked, very little sought outside it). pmm's lovely to be able to search across multiple distro's repos to see which has what you're looking for.

To offer an answer of a sort to the question in your thread content "what are some cool things specific to Arch AUR, not in official Void binary repos?":

If I were feeling more sharp, I'd maybe script some kind of diff from pmm's (or native package managers') installed list commands to show what i have from aur that's not in void. Lacking that sharp feeling just now, instead I'll merely offer: Lots of things. Lots of shiny things, silly things, niche things. ;D (we'll see if i'm back with a little script and output after food & hydrating etc).

It's easy to get lost in the bedrock honeymoon and want to install all the things, like being let loose in a candy store, all you can eat/carry, for free. After that excitement settles, it's back to just a utility meeting needs as they come up. + the gratitude of more being in reach.

I'll second Siljrath here. That is surprising. Something is wrong.

Some more details about my system: I started with Void, ran the hijack script, and installed arch and debian in strata. I'm using Void's kernel and init scripts. Oh, and I didn't do anything special to install yay: I just downloaded the latest binary release from its github and ran it:
./yay -Syu

and that gave me an error about a missing libalpm.so.whatever. I figured it was some Arch pacman-related lib and tried: strat arch ./yay -Syu and that worked fine, so I tried installing some fun stuff. (There were a few "build-essential"-but not called that-packages to be installed to get things building and everything seems fine.)

Ah, this is the issue. That is an unusual way to install yay. Most people install it as a pacman package with something along the lines of `makepkg -si` so it shows up in the $PATH rather than run it directly from an arbitrary directory.

Part of what Bedrock has to do to make things work is wire up binary libraries to binary executables. If you install binary in a stratum-specific location (something like `/bedrock/strata/<stratum>/usr/bin` via a package manager or `/bedrock/strata/<stratum>/usr/local/bin` manually) and run it through the $PATH, Bedrock knows which stratum's libraries to associate. That's why `xbps-install` and `pacman` both just work without the need for `strat`.

If you run a command from an arbitrary directory via `./` without `strat`, Bedrock has no hint about which stratum with which it is associated, and so Bedrock guesses the stratum of the calling process (which is usually a shell). In this case your shell came from Void, so Bedrock wired up Void's libraries when you ran `./yay`, which didn't work because it needed Arch's libraries. If you run `./yay` from a shell provided by Arch, it'd work. Using `strat` to tell Bedrock which set of libraries to use is the correct workflow if you do want to run a command via `./` that isn't from the calling process (i.e. shell)'s stratum.

2 members found this post helpful.

I figured it had something to do with the environment and wasn't too concerned. I like keeping stuff like yay out side the normal PATHs because it forces a little hesitation/thought before firing it off. At very least, I am less likely to accidentally run yay as root.

1 members found this post helpful.