Yes, I meant that brew only packages Zed for MacOS
Yes, I meant that brew only packages Zed for MacOS
RThose are casks
RThey're not actually on brew
RJust a wrapper to install it from app store usually
RIt's like winget on windows
RIt wouldn't really work on Linux unless you integrated it with appimage or flatpak
JI'd love for someone to make a brew plugin that just replaced casks with flatpaks when on linux
RThere's probably a way to do it with a fish function
Ralias brew-install-cask='flatpak install'RKinda cursed tho
Jnah we'd need a proper plugin
RUblue revolves around Flatpaks, and most CLI applications aren't available as a Flatpak. Homebrew contains thousands of CLI packages and libraries, and it works effectively in userspace on atomic/immutable systems, making it the perfect pair
RTogether, Flakpak covers GUI and Homebrew covers CLI. Other solutions like distroboxes and layering just fill in the gaps
Ahttps://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" 
