Skip to content

Lynne Teaches Tech: Package Managers, the Precursor to the App Store

If you use Windows, you’re probably familiar with the scenario of installing a program and trying to run it, only to find out that it requires something called “.NET 4.0” to be installed. This is because .NET provides functions that the program makes use of, and thus it requires .NET to work.

This is called a dependency. Some programs have dependencies that are required for them to function properly, and installing the dependency before running the program is necessary.

mstdn-ebooks is a small program I’ve made to allow you to host a Fediverse bot that generates posts with words learned from your post history (more about that here). It’s written in Python, meaning that it requires Python installed to work. It also uses and BeautifulSoup, meaning that these need to be installed too. Installing all of this by yourself is a mess. Fortunately, a Python utility called pip can download and install them for you. Pip is a package manager.

When you ask pip to install mstdn-ebooks, it will install too. It will also install everything needs, and everything those dependencies need, and so on. This saves you a lot of time and effort!

Almost all Linux distributions have their own package manager. When you want to install a program, such as Firefox, the package manager will make sure all of the necessary dependencies are installed. The package manager can also update your installed programs and dependencies, meaning that you have one place where you can keep everything up to date. This is in contrast to (most) Windows and macOS programs, which will individually prompt you for an update when you open them.

Arch Linux listing the packages that need updating.

You might notice that this package manager approach sounds similar to how Android and iOS work. Like with a package manager, programs are installed from one place (Google Play or the App Store) and updated from that same place. When you open VLC on your MacBook, you might get prompted for an update, but this will never happen on your iPhone – the updates come through the App Store.

There are, however, a few key differences between package managers and mobile app stores.

Where App Stores Go Wrong

Firstly, mobile app stores don’t manage dependencies. If a mobile app needs to use a dependency, it will be included with the app. This means that if you install ten apps that use the same dependency, each app includes a copy of that dependency. This has its advantages and disadvantages, which you can read about in more technical terms here (the app store method is static and the package manager method is dynamic).

Secondly, mobile app stores are limited to getting apps from one place. This means that if Google doesn’t approve an app, it can never appear in Google Play (ditto for Apple and the App Store). Meanwhile, if (for example) Debian doesn’t approve an app for inclusion into their program repository, you can add someone else’s repository and install it as normal. This would be like if Google Play had a feature to install and update apps that didn’t come from Google. Google and Apple don’t provide this because they want to be able to test, mediate, and restrict the apps that can be installed by the end user.

For example, both Apple and Google have rules against providing donation links in your software. Donations can only be given through in app purchases, meaning that Apple/Google takes a cut. Adding a link to your Patreon or Paypal will get your app removed.

While it’s still possible to install apps outside of Google Play on an Android device, it is discouraged and generally more inconvenient. Meanwhile, on an Apple device, this is not possible for the typical end user at all without jailbreaking the device. This means that getting your app distributed to most Android and iOS users requires you to go through the app store, giving Google and Apple an unavoidable monopoly over the distribution of software. Both Google and Apple charge a fee to list your app on their stores, and they also take a cut of any in-app purchases the end user makes. Meanwhile, if a Linux distribution were to do something like this (and none ever have), people would simply make a new store for users to use, and switching to it would be as easy as adding one line to a configuration file.

Banning donation links and requiring publishing fees make it difficult for developers of free and open source software to put their apps on the stores, and thus difficult to distribute their apps at all. Meanwhile, many Linux distributions encourage developers to make their software free and open source, and a few even require it.

There are a few alternative app stores available for Android devices. One of them is F-Droid, an app that behaves much more like a traditional package manager than a mobile app store. Updates and installations are still handled through F-Droid, but unlike Google Play, all apps are required to be free and open source, donations are permitted, there are no app fees, and it’s possible to add alternative vendors to the app (meaning that even if F-Droid doesn’t approve the app, you can add a distributor who does and still install the app through the F-Droid app). F-Droid takes this philosophy a step further and warns users of “anti-features” that some apps have. For example, all apps that track users in some way have a warning stating so. You can read more about anti-features here.


Package managers and app stores provide a repository for users to download and update software without having to worry about using installers full of ads, websites presenting fake downloads, and websites getting hacked to distribute virus-laden installers. At the same time, the centralisation of distribution provides an avenue for those distributing the software to exert control over the available packages, which can be a good thing (preventing viruses from being available for download) and a bad thing (Google and Apple banning donation links).

Thanks for reading! :mlem:

3 thoughts on “Lynne Teaches Tech: Package Managers, the Precursor to the App Store”

    1. I’ve thought of publishing it to the AUR, but I don’t know how I should handle dependencies like (which isn’t in the AUR). pypi may be a more viable choice, though!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.