https://discord.com/channels/1072614816579063828/1074422586894712912/1276562855604391997 what do you
https://discord.com/channels/1072614816579063828/1074422586894712912/1276562855604391997
what do you think about this
what do you think about this
ROof, this is something the entire ublue team needs to look at
RSomeone should go in there and inform them of our use case
RIt would be unfortunate if Homebrew declares us as unsupported
HMy 2 cents is it would fall on fedora and brew to sort it out.
We don't do anything special.
But I think it is more on brew to fix. If home is a symlink then follow the link to the absolute path (or just assume atomic and look in /var/home)
Not rocket science
We don't do anything special.
But I think it is more on brew to fix. If home is a symlink then follow the link to the absolute path (or just assume atomic and look in /var/home)
Not rocket science
Ayeah, i would love to PR but i dont understand ruby lol
Aalso the problem doesnt sound that complicated
HSame
Lsame
La 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
general