Yeah and that’s why their own ChromeOS is not even mentioned … This argument died years ago since advanced Linux users have no problem with for example unpacking deb packages and installing apps for a specific user or simply compile from source.
TLDR; Below is more descriptive answer about packages in Linux.
Do you know how hard is to create a package? I didn’t liked that in selected by user packages to install are dependencies required to compile many apps using asdf version manager. I decided to make a quick research checking how hard is to create a meta package. It was so simple that I have created few meta packages each for different asdf install and one meta package to install all of them. Now when I want to install software needed on any deb-based distribution I copy-paste my files and run just one command to install meta package.
Here is all I need to do:
# create a parent directory for meta packages
mkdir my-packages
# enter parent directory
cd my-packages
# create at once all directories each for one meta package
mkdir meta-a meta-b meta-c …
# in simple loop enter every directory, generate ns-control file and enter parent directory
for dir in `ls`; do cd $dir && equivs-control ns-control && cd ..; done
# once all packages are generated I open directory using my text editor
subl .
Example ns-control file:
$ cat /usr/local/asdf-meta/asdf-erlang/ns-control
# important for package manager copy-paste data for all ns-control files
# package belongs to development group
Section: devel
# mark package as not necessary for OS
Priority: optional
# declare which standard we use when building package
Standards-Version: 3.9.2
# other copy-pate data for all ns-control files i.e. package name and maintainer
Package: asdf-erlang
Maintainer: Tomasz Sulima <email>
# all our hard work goes here …
# the biggest thing we need to do is copy-paste packages from documentation
# and separate their names using comma (,) character
Depends: autoconf,build-essential,libgl1-mesa-dev,libglu1-mesa-dev,libncurses-dev,libncurses5-dev,libpng-dev,libxml2-utils,m4
Recommends: fop,libssh-dev,libwxgtk-webview3.0-gtk3-dev,libwxgtk3.0-gtk3-dev,openjdk-11-jdk,unixodbc-dev,xsltproc
# a simple word or two …
Description: meta package for Erlang dependencies installed using asdf version manager
# you can also add more information, but those are completely optional and not needed in our case
Without comments it’s 8 terribly hard to maintain lines. Only 5 of them were copy-pasted for all packages. That’s inhuman. 
But those are not dev files, right?
Right, I forgot about another loop. Here it goes:
# just one word have changed: equivs-control -> equivs-build
for dir in `ls`; do cd $dir && equivs-build ns-control && cd ..; done
ok, so those deb files can be used in some custom repository like for example sublime-text or vivaldi have, but how hard is to add them locally and what about updating them?
That’s also simple:
# let's go back to parent directory of the one containing all meta packages
cd ..
# copy this directory where you like
sudo cp my-packages /usr/local
# instruct apt about your custom repository
# trusted=yes is required unless you add extra file with repo information
# which is not needed in our case
echo "deb [trusted=yes] file:/usr/local/my-packages ./" | sudo tee /etc/apt/sources.list.d/my-packages.list
# create a new script available in `PATH` environment variable
subl ~/.local/bin/update-my-packages
# finally mark script as executable
chmod +x ~/.local/bin/update-my-packages
Finally here is our update script:
$ cat ~/.local/bin/update-my-packages
#! /bin/bash
# enter directory we have just copied
cd /usr/local/my-packages
# remove old generated packages
rm Packages.gz
# this line we already well known …
for package in `ls`; do cd $package && equivs-build ns-control && cd ..; done
# all you have to do is to generate a Packages.gz
dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
# we can safely remove unnecessary buildinfo and changes files
# generated using equivs-build command
rm */*.buildinfo */*.changes
# check if the script is runned with root rights or using `sudo` command
if [[ "$EUID" = 0 ]]; then
# just update
apt-get update
else
# make sure to ask for password on next sudo
sudo -k
# update with sudo
if sudo true; then
sudo apt-get update
fi
fi
Now every time you change any ns-control file all you have to do is to call update-my-packages script and the updated deb is available to install using apt. All you have to remember is to update package version. 
Both research and copy-paste took me “5 min”. Not sure, maybe it’s too much for corporations, but for me that is yet another way to save lots of time especially when filtering out all that build-essentials staff when reading a list of install by user packages. It changed dozens dependency entries in just one entry which remains me that on next installation I need to copy said meta packages.
But wait - I still didn’t said the best thing …Regarding the magic complexity … I have followed Ubuntu documentation on MX Linux which is Debian (stable) and not Ubuntu-based distribution. I guess that it would work without problem on all Debian-based distributions.
Now let’s take a look at package types used in most distributions:
deb (Debian based) - binaryebuild (Gentoo based) - compiles from sourcepkg.tar.zst (Arch Linux based) - compiles from sourcerpm (Fedora/SUSE based) - binary
Except above there are 3 “portable” formats: AppImage, flatpak and snap.
Most of packages are created by community, some of them are compiling apps from source. The most noticeable problem when changing distribution is glibc version change. You need to recompile (or install binary compiled for your glibc version) all of the software you have copied (I did so when tested copying asdf directory).
Most of work you have to do if you want to support lots of distributions:
- Check
distrowatch for most popular distributions
- Collect package type (like
deb) and glibc version data
- Compile your app from source for each
glibc version
- Package to
deb, pkg.tar.zst and rpm for each glibc + package type combination
- Create
ebuild for new version, if you did not added dependencies it’s basically copy-paste with changing one number
- Optionally also package compiled binaries with
AppImage, flatpak and snap
- Upload all packages you have generated to your repositories
So almost whole process you can automate using CI. The other things left is to first create said repositories which you do only once and update package dependencies if needed.
If you want to know more simply create a new topic and feel free to ping me. You can also take a look how simple documentation is. For example in case of meta packages you can see:
They support or plan to support every platform except 
What I really don’t understand is when they add support for 
I would really understand if they would not have a client on 
btw. If they do not plan to work on 
I understand that 
changes a lot, but it’s also not so easy to answer with it for every such ridiculous decision. 
, so I was waiting 
for at least a basic support for development tests even in some 
This feels a bit off-topic in the context of this thread, so I’d ask that the discussion of Linux package management find a better home. That writeup would be a great blog post for anyone who’s interested.