Yo OP, this is me @poki from another account. I had intended to leave the Lemmyverse for a while, but had to come back earlier than intended when I read your comment đ .
So, without further a due.
Okay, I appreciate the links. Iâve had a chance to go over both, and I think I get the gist:
Thank you for your time!
rpm-ostree is a work in progress, and it will be depreciated and replaced with bootc + dnf
What do you mean with âwork in progressâ? Youâve been using it relatively often in this thread (and IIRC even in others) when talking about Fedora Atomic and/or uBlue and its technologies. Like, do you consider dnf to be work in progress because dnf5 is around the corner?
I donât recall any mention of deprecating rpm-ostree, though I might be wrong. But, yeah; it will definitely lose focus in favor of bootc + dnf.
For example, I have a VPN client that is installed via a .run script, so it doesnât work with ostree. If I wanted to apply this software to my system, Iâd have to create a bootable container, then rebase to that.
Iâm not actually sure if it works out just like that as of right now. Creating your own image or bootable container is definitely a powerful tool that can help bypass some imposed limits; like e.g. populating files in /usr or baking in (current) rpm-ostree actions -some of which actually wouldnât work otherwise (as of right now)- directly into the image. Finally, it allows one to move from an imperative to a declarative system. However, Iâm not aware if it enables one to bake-in the installation of .run files. My only experience with .run files myself was with Davinci Resolve, but thatâs notoriously difficult to install regardless. Thankfully, itâs a popular piece of software and thus avenues have been created by which one could install it on Fedora Atomic and related projects.
So, in short, I donât see how creating your own bootable container would help you to bypass this.
But my goal isnât to create a new image, just to apply transient packages to the base Bazzite image
Exactly.
If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project?
Would I have to manually build a new container and rebase each time I wanted to check for updates?
By either of the two earlier mentioned means, the building is done automatically (on a daily basis) by GitHub. Furthermore, when you update, you just receive the latest image from your own GitHub repository in which your own image resides. Updates continue to be done automatically in the background, so you wonât even notice. Finally, if it wasnât clear yet, you only have to rebase once.
I feel like Iâm on the cusp of seeing the big picture, but Iâm not quite getting it, and maybe thatâs because I havenât worked at all with services like Podman and Docker.
Thatâs fine. Please feel free to inquire if you so desire!
Alright, having said all of that, letâs get to the crux!
So, did you try the following methods when installing the .run file? If so, how did it go?
Simply double press or right-click then install (of course, after applying chmod +x).
Within a terminal with ./<name of .run file>.run
Within a terminal with ./<name of .run file>.run --appimage-extract and then interacting with the AppImage.
If all of the above have absolutely failed, I only see three ways going forward:
Creating your own Flatpak đ .
(OR) Taking this to COPR đ .
(OR) Succumb to Toolbx/Distrobox đ . Like have you tried running the .run file within Toolbx/Distrobox? If so, how did it go?
EDIT: đ . I had hoped youâd return with a reply soon~ish. But alas⊠UhmmâŠ, Iâll be off for a couple of days and will return only next week. Just wanted to let you know*. FYI, Iâll probs return with (yet) another account.