Homebrew package manager

[Serpens]

Good news to all Linux users: Homebrew works on Deck. Just follow instructions on https://brew.sh/. Give it a try if you miss Pacman.

Homebrew allows you to install a lot of software packages, mostly command line developer tools, but not only. By default it installs software in /home/linuxbrew, which is a read/write location by default on SteamOS.

I'm not affiliated with Homebrew in any way.

[@R+5]

whats the advantage or use vs the arch package manager (pacman) or yay (which makes easy to install and manage programs in the AUR)?

[Serpens]

Pacman and AUR install Package in /usr, which is read only by default and Valve warns that it may get overwritten by system updates

[@R+5]

so the packages listed in homebrew are meant to solve file dependecy issues via symlink?

[Prezidentas]

It's not exactly the same as using distro repositories for distro-compiled packages

[Serpens]

I’m not sure what dependency issues you mean. Homebrew doesn’t use Arch packages, it uses its own. It does some magic with environment variables like PATH and LD_LIBRARY_PATH, not with symlinks.

[retrogunner]

I don't have my Steam Deck ... so the following is based on experience:

1. rtfm - https://docs.brew.sh/Homebrew-on-Linux
2. repeat step 1.

It will install brew packages into /home partition directory. Then update your /home/deck/.bash_profile to pulling in the brew environment (bin & library paths, etc.)

This is perfect package management alternative given:

• the read-only state of the OS image. No need for pacman or read-write enabling
  
• flatpaks are more about GUI apps than CLI Terminal applications & services
  
• flatpaks can be big (as they can contain lots of redundant libraries on the host)
  
• power users want a space to muck around in without losing it to an OS update
  
• folks can make their own brew packages for re-installation
  
• For those without a Deck, you can test the waters with even a Raspberry Pi.

What can be installed via brew, search at https://formulae.brew.sh/
OR list them all out at https://formulae.brew.sh/formula/ then use your browser's Ctrl+F Find.

IMHO, I foresee brew.sh & its available Ansible package will make Steam Deck Playbooks so easy peasy to distribute to non-power users.

BTW, for the Ansible haters - it's all about use-case:

• puppet & chef are not really available via Brew
  
• Ansible only requires yaml, openssl, python & six (a py2 & py3 compat util)
  
• Salt has the same pre-reqs as Ansible but it also requires libgit & zeromq (too heavy for the Steam Deck - no need for an MQ service on the Deck - bleh).

Cheers. Retro

[Ays]

I give this exactly one system image update before it blows up due to either conflicts between the third party packages in your path and system files, or the packages relying on said system files.

[Serpens]

Originally posted by retrogunner:

I don't have my Steam Deck ... so the following is based on experience:

That's why I started this thread: I got mine, can confirm it works. The only package that I noticed that doesn't work out of the box is gcc: I couldn't compile a hello world. Which is a pity and limits what's possible to install.

Originally posted by retrogunner:

IMHO, I foresee brew.sh & its available Ansible package will make Steam Deck Playbooks so easy peasy to distribute to non-power users.

That sounds like a great idea.

[retrogunner]

Bummer about the gcc. Might need to make a playbook for 'homebrew essentials' to:
enable r/w mode
pacman -S build-essential
#whatever else
disable r/w mode

then the playbook would only need to run after an OS update *IF* you're doing so brew updates/installs.

[retrogunner]

Originally posted by Ays:

I give this exactly one system image update before it blows up due to either conflicts between the third party packages in your path and system files, or the packages relying on said system files.

That's a possibility if not configured correctly. But homebrew for Linux recommended install location is under /home in user space - RTFM.

However, this is very much in the same vein as Python's `virtualenv` -- where a non-system level of python, libraries and deps are installed into a normal user space directory. They are isolated and dormant until activated:
* beforehand => `which python3` yields /usr/bin/python3
* `./activate && which python3` yields /home/username/prjpath/bin/python3
that means
* normal system installed applications are NOT broken for any user
* the userspace install can be packaged up & made portable
* activation is specific to the manually instantiated Bash shell running
so ZERO bin & lib pollution.

As a power-user who wants to minimize OS Update loss (i.e. do overs), brew.sh / homebrew satisfies my use-case where flatpaks fall flat (pun intended).

To each their own. Cheers, Retro.

[Ays]

Originally posted by retrogunner:

Bummer about the gcc. Might need to make a playbook for 'homebrew essentials' to:
enable r/w mode
pacman -S build-essential
#whatever else
disable r/w mode

s/build-essential/base-devel/. This is not a debian.

Originally posted by retrogunner:

However, this is very much in the same vein as Python's `virtualenv` -- where a non-system level of python, libraries and deps are installed into a normal user space directory. They are isolated and dormant until activated:
* beforehand => `which python3` yields /usr/bin/python3
* `./activate && which python3` yields /home/username/prjpath/bin/python3
that means
* normal system installed applications are NOT broken for any user
* the userspace install can be packaged up & made portable
* activation is specific to the manually instantiated Bash shell running
so ZERO bin & lib pollution.

This is only true if you do activate your homebrew environment manually (the documentation tells you to put it in your .profile).

Also it's not isolated in any case. The activation script retains the system paths, and it does not even touch the library path - homebrew links libraries using absolute paths, but anything relative would still be looked up in the system's lib path. That might work, but it's not what I'd call proper isolation.
And linking to absolute paths makes it hardly portable either.

[retrogunner]

Originally posted by Ays:

s/build-essential/base-devel/. This is not a debian.

Thank for pointing that out. It's not something I've installed on my PinePhone (I flip-flop it between Manjaro and Mobian). And my PCs are Debian Mint for ease (a break from day-job RHEL/SLES).

I am looking forward to my Deck as my Gaming Arch use-case.

Originally posted by Ays:

This is only true if you do activate your homebrew environment manually (the documentation tells you to put it in your .profile).

Also it's not isolated in any case. The activation script retains the system paths, and it does not even touch the library path - homebrew links libraries using absolute paths, but anything relative would still be looked up in the system's lib path. That might work, but it's not what I'd call proper isolation.

And linking to absolute paths makes it hardly portable either.

The folks who likely are using brew are not general users. They are likely folks wanting more from their CLI while not losing stuff to OS Updates on the Deck. They will have no qualms about the way they wish to execute `/home/linuxbrew/.linuxbrew/bin/brew shellenv` be it via their .bash_profile, an alias, etc.

I think there will be some Deck Community HOWTOs on an appropriate way to use Homebrew to identify the best way (and when) to instantiate it.

You are correct in that when issuing 'brew shellenv' it places the system ENVs after brew ENVs. That might be a problem for game or app if placed in a .bash_profile . For those in the community who's use-case includes using Homebrew, that will likely surface in the HOWTO (or depending on personal linux experience.)

Personally, I'll make `alias teatime="/home/linuxbrew/.linuxbrew/bin/brew shellenv"` to prevent .bash_profile persistence, making it easy to 'activate' in Bash when desired.


As for symlinks & pathing, brew appears more portable given it's using relative symlinks to files in its own directory structure. I ran the following my [debian] laptop: /home/linuxbrew$ find . -type l -ls | less

Every link was relative and to objects in the linuxbrew homedir. I seriously doubt the code base is using absolute paths being bad practice. This project been around since 2009, I'm confident there are no fully qualified paths internally. (Even its built-in ruby interpreter appears isolated enough).
https://en.wikipedia.org/wiki/Homebrew_(package_manager)


"Portable" in my original post is a relative term. I'm not expecting it be USB Flashdrive portable like Cygwin or an AppImage. Portable as in:

a) packages made for Linux x86 brew should work on other brew x86 Linux installs.

b) given all Steam Decks are architecturally identical (including read-only SteamOS OS objects - OS mounts, paths, etc.), Decks are more like a Console PC (like a x86 Chromebook). So if using a default SteamOS 3.x install, any Deck specific brew package (Bottles) or repos (Taps) should be pretty much a smooth operation.

Even if using absolute paths, SteamOS 3.x installs are identical so it doesn't matter. Only if someone re-images their Decks to main Linux distro Deck portability wouldn't matter - and then they'd be using said distros mainline repos.

And when Valve releases SteamOS 3.x for general PCs a bit later on, they should work there too as the OS drive image (pathing, etc) should be identical to the Deck.

I'm in no way advocating everyone install homebrew. That's harmful to most Deck user's experience. It's about options & use-case. brew will work for some folks (like me) and likely not for most others.

After a long day, I'll just want to play some games on the couch or just before going to sleep. Being able to brew install some SDR, pentest tools, emus, game servers for lan parties, and other desktop tools that won't get borked on OS updates will be nice. (I'll likely have to build my own Kismet). It would empower the Desktop mode even further than what flatpaks offer.

[Screenager]

It would be amazing if steam itself would become a repo. It acutally is a repo, it just costs 100$ to add a package. RetroArch is already on Steam.
Valve actually has something to say about this:
https://partner.steamgames.com/doc/sdk/uploading/distributing_opensource
With this whole SCO vs everyone trolling I kinda understand Valves position here.

Originally posted by steamgames.com:

(...) (b) decide that what the Steamworks SDK does is just a communication with a service that does not invoke the copyleft requirement of the GPL.

But yeah I believe you have to be a major troll to see a GPL2 violation by simply packaging and distributing binaries.
So I see absolutly no reason (other than the 100$) why maintainers shouldn't add steampipe to their devops pipeline.
Would be great by Valve to build their own repo or give maintainers free steamworks access. Valve could make open source software more accessible , and Valve could profit from more usability on SteamOS and solve all that how to install software problems. Everyone would profit, or am I wrong?

[retrogunner]

Turns out `alias teatim="/home/linuxbrew/.linuxbrew/bin/brew shellenv"` won't work as that just echos out the ENVs - derp. (I assumed it was echoing was it was doing). But, not all is lost. The simple fix is to:

# this is a one-time setup
$ /home/linuxbrew/.linuxbrew/bin/brew shellenv > ~/.linuxbrewenv # not to pollute the bash dot files
$ echo 'alias teatime="source ~/.linuxbrewenv"' >> ~/.bashrc # or to ~/.bash_profile

So then I can still have 'teatime' to use anything brewed.
teatime
use-brew-installed-utils || brew commands

I know there's a way to 'brew shellenv' every time all in one bash-foo way, But this allows me a way to control:
* I must always have 'teatime' before anything brew so it washes out to having one command per shell instance anyway
* control the availability of brew & its installs
* should I choose to change the ENV Pathing precedence, it will be trivial to edit ~/.linuxbrewenv

[Ays]

Originally posted by retrogunner:

As for symlinks & pathing, brew appears more portable given it's using relative symlinks to files in its own directory structure. I ran the following my [debian] laptop: /home/linuxbrew$ find . -type l -ls | less

Every link was relative and to objects in the linuxbrew homedir. I seriously doubt the code base is using absolute paths being bad practice. This project been around since 2009, I'm confident there are no fully qualified paths internally. (Even its built-in ruby interpreter appears isolated enough).
https://en.wikipedia.org/wiki/Homebrew_(package_manager)

I was talking about binary dynamic links, not filesystem links. Try

readelf -d /any/brew/binary |grep NEEDED

. Unless the way brew works was significantly changed when they ported it to linux, most paths you'll see here will be absolute. That's how it "isolates" itself from the system libraries without modifying LD_LIBRARY_PATH.


For the rest: of course do what you want with your deck if you know what you're doing and/or accept the risks. My point was this is the kind of thing that has a high probability of breaking at some point, so shouldn't be done by someone who doesn't know wtf and had just wandered into this thread.