a workaround that might work is to use a bind-mount instead of symlink
a workaround that might work is to use a bind-mount instead of symlink
Awell my problem has workaround but i fear for future problem
LI don't know ennough, yet, tho, about how silverblue is set up
HThen the ball is in fedoras court since the installer does a symlink.
Also bind mounts don't work for composefs so doubt it will happen
Also bind mounts don't work for composefs so doubt it will happen
Laha. gotcha. it's a symlink to allow overlaying?
ZSometimes, containers have limitations when it comes to accessing hardware
ZSo my guess is it acts as a fallback on those cases
ZPlus, though personal opinion, not everyone can bother to open a container just to install a simple CLI program
AIt's because bluefin is targeted also at Mac users and they use brew
AA lot of swe use brew
RWhat are ublue folks thoughts on moving several of the ublue-os/main preinstalled cli tools to brew, and including brew in ublue-os/main?
Rit would help prevent collisions between rpm and brew packages and make the core system image leaner
Rfzf, nvtop, htop, tmux, even vim, etc could be moved
Ralso smartmontools, net-tools, apr-util
Rand probably others
RI'm not too keen on including brew on the main image. It goes against the idea of them being unopinionated and not veering too far from upstream.
Instead, I'd be happier removing some of those tools, and moving them downstream (either as RPM or Brew), though it's not as easy to do now they are already on the image
Instead, I'd be happier removing some of those tools, and moving them downstream (either as RPM or Brew), though it's not as easy to do now they are already on the image
Rthough it's not as easy to do now they are already on the image
yeah, that's why I was thinking simply moving them to brew would be a good compromise
RIt goes against the idea of them being unopinionated and not veering too far from upstream.
They already include changes that imply brew usage, like:
https://github.com/ublue-os/config/blob/main/build/ublue-os-just/etc-profile.d/brew.sh
Revery ublue image user's shell is checking for the presence of brew on init
Rthe only change would be whether or not brew + some cli tools are opt-in vs opt-out
Rwhereas today if you want to use brew for those cli tools, it's much more cumbersome
JI totally get wanting to use the tools you're familiar with, but in the fedora world, rpm packages are unavoidable and brew packages are
As someone who doesn't use brew, you'd then have to check for package in dnf and then check for it in brew which is more confusing
I'd be more interested in a brew-first spin than some multiple package-managed thing
As someone who doesn't use brew, you'd then have to check for package in dnf and then check for it in brew which is more confusing
I'd be more interested in a brew-first spin than some multiple package-managed thing
Rall the ublue end-user images are already "multiple package-managed" except ucore
i'm far more familiar with rpm/dnf/yum than brew
wanting to use the tools you're familiar with
i'm far more familiar with rpm/dnf/yum than brew
Rhonestly I've never used more than two commands from brew:
brew install and brew uninstallRsimple as it gets for a package manager really
Rwith ublue handling updates automatically, I don't need to use any other command
Rthat and you shouldn't be checking for rpm/dnf packages before brew packages on ublue anyway, because you'd have to layer them or boot them in a distrobox, both of which are suboptimal compared to running them through brew
Ri didn't mean for this to turn into "brew good vs bad" 
Rif ublue folks aren't interested, then no worries 
JYa thats definitely true. I just mean that things can get a little crazy with all the different methods to install things. I always hate having the thought of "how did I install this 6 months ago?"
There's so many ways to install things it could maybe rival PC game launchers
There's so many ways to install things it could maybe rival PC game launchers
Rthat's something I definitely want to see improved. unfortunately, the variety of package managers feels like a natural consequence of being flatpak-first right now
Rrpm-ostree install just
just install brew
brew install pip
pip install stuff
just install brew
brew install pip
pip install stuff
R:clueless:
Roh i forgot flatpak
Rsomeone package flatpak in pip :clueless:
Rand then rpm-ostree in flatpak
R:clueless:
NAppImage
Rthe pain of almost every proprietary app being an appimage...
Rlike?
Ralso let's move to #
general
generalRah yeah good idea
Tgear lever >
J@RoyalOughtness sorry that anigif was burning my eyeballs
J@Kyle Gospo https://github.com/coreos/rpm-ostree/pull/5061
GitHub
It's useful to see in the progress output how many layers there are to fetch.
This is similar to
containers/bootc@6eb5718 which ended up being totally reworked in a nicer way in containers/...
This is similar to
containers/bootc@6eb5718 which ended up being totally reworked in a nicer way in containers/...
Jwe're close
KYesssssss
Ranigif?
JI'm looking into this feature request and am looking to create patches for gcc and kde settings. is this still the authoritative way to handle patches with rpm packages?
GitHub
adding an update GUI would be helpful to users that want to configure their updates without touching a text file Possibilities: Integrate with GNOME or KDE system settings some form of independent ...
RPM Packaging Guide | Red Hat Documentation
Fuhhh
