Thoughts on dropping Debian to make PureOS an Arch-based distribution

Okay, those might be good arguments after all :stuck_out_tongue:


Some more: Arch does not even support arm64 officially, which we need for the phone. Arch for ARM devices is an unofficial project, while Debian’s arm64 support is first-class.

Also, Arch takes a very limited approach to upgradability. You’re supposed to update often and always read news before updating. Partial updates are explicitly not supported. This is an exact opposite to what Debian does in its packaging - pacman isn’t even able to express some package relationship that you’d need to ensure smooth upgradability from any given past version of every package.

I use Arch on my laptop, because I’m a somewhat experienced GNU/Linux user and I can take the needed system maintenance. It wouldn’t be a good fit for PureOS though, which aims to be stable, user friendly and currently doesn’t even provide an equivalent of Debian sid (there’s only stable and testing). And that’s not even mentioning freedom issues - Arch has no strict licensing policy like Debian does with its DFSG.


That is true for now, although it is unthinkable that Arch and Arch ARM will not merge soon, given the spreading of ARM CPUs (same goes for Manjaro and Manjaro ARM). Also “unofficial” might not be the right word: Arch and Arch ARM are simply (almost) independent projects, but per se Arch ARM supports ARM… quite well (they even distribute Phosh for mobile phones).

I would say this is true in theory. In reality the last (minimal) manual intervention I needed to perform on my machine comes from this news from one and a half year ago. That means one and a half years of continuous self-sustaining updates. I would say that this has been the case with my laptops for the last ten years.

That might be the price to pay for a rolling release distribution, and Arch users are happy to pay that price. On the other hand, if we want to go into packaging-freak-show, there is always GNU Guix, which basically allows to do everything a user better does not do.

There is Parabola for that, or even Hyperbola. The latter is probably even stricter than the FSF concerning user freedoms, since they are proposing to drop the usage of the Linux-libre kernel in favor of a OpenBSD-derived one because of freedom issues.

I know, mine is “What if” question. I believe though that the stability of Debian compared to Arch is a myth, and my experience has been the exact opposite: Debian tends to break, while Arch is incredibly resilient.

Stop upgrading your Arch for a few months and then install some application… or even do pacman -Syu, then we’ll see about that :wink:

(btw. “stability” does not only mean “does not break”; how ABIs are tracked and how much of a moving target the base distro is matters a lot when it comes to maintenance)

On Arch, you can’t even update linux package and expect modprobe to work until a reboot :wink:

1 Like

I do that with my father’s laptop (since I meet him once every six months more or less). It might take a couple of shell commands more, but things work in the end.

Never tried that instead.

I have added linux and linux-headers to pacman blacklist and only update them manually after I have wondered why a newly connected USB device does not work one time too many for my taste :stuck_out_tongue:

Updating the kernel (and maybe also libc?) is the only update where a reboot is strongly suggested on Arch.

If I am not mistaken though the same strong suggestion applies to Debian too.

I forgot to address this. Of course pacman does not have the means to express upgrade relationships, but that is simply because by design upgrades are not a thing in Arch. It is a rolling release distribution, the word “upgrade” makes no sense in this context (that’s kind of the whole point of it).

There are user-made snapshots of the official reposiories that can work as time machines though.

Of course, you don’t have to tell me all that. I’m using Arch successfully for years and I’m pretty happy with it. Some things I mentioned are even reasons I’ve not switched back to Debian yet.

But at the same time the very same reasons are why I wouldn’t base PureOS on Arch if it was only up to me. I’m very explicitly not a “regular user”. I can deal with Arch. You can too. I wouldn’t suggest it to someone new to GNU/Linux if they were supposed to maintain their system on their own though.

Nope, kernels with separate ABIs get separate packages in Debian; there are no downsides to not rebooting into an updated kernel other than running an outdated kernel :stuck_out_tongue:


I doubt that Purism is going to decide to switch to Arch. Guido Gunther and Matthias Klumpp are Debian developers, and the former CTO Zlatan Todoric was one as well, whereas Purism doesn’t have the same level of expertise with Arch.

I think that it is more realistic for you to push for the creation of a Purism community wiki, where the Arch community can document how to use Arch on Librem hardware and we can pester Matt Devillier for how to do things like update the firmware when using Arch. I think that Purism needs a community wiki so people who use other distros don’t feel left out.

Right now the Debian Testing kernel (5.10.46) is significantly behind the Arch kernel (5.13.9), but that only happens during a freeze before a stable release. Most of the time, there is only a month or two of difference between the kernels, and the thing that really matters for Purism is Coreboot support, which is mostly determined by the cooperation between Intel and Google for Chromebooks, so I really doubt the speed of kernel updates matters that much.

Interesting that someone uploaded ProcessMaker to AUR, but that package is 4 years out of date, and anyone installing it will want version 3.6.5, not version 3.2.1. The issue, however, is that ProcessMaker Inc. refuses to support Arch as a platform, whereas ProcessMaker Inc. does have a few clients that use Debian, although most are using CentOS. The creators of commercial software generally don’t support rolling-release distros because they are too much trouble for them to maintain, and many companies aren’t going to take a chance with an unsupported platform.

I haven’t installed Manjaro, so I can’t really comment on it, but I think it is unlikely that Purism will base PureOS on another company’s distro, for the same reason that Purism chose Debian over Ubuntu.

Arch has fantastic documentation for expert users, but it can be overwhelming for new Linux users in my experience, and when they do a Google search for how to solve a random Linux problem, they are more likely to encounter instructions for the Debian family than the Arch family.


I can really understand your point of view, which has its fair amount of arguments. I would probably push for Arch instead (I actually just did that with this thread). I would probably be thrilled by the challenge of creating the tools necessary to make it accessible to everyone (in case Manjaro did not already do that), and I would welcome the hackers that will want to put their hands on my OS. And in case of very inexpert users, they don’t have to do anything, my OS comes pre-installed anyway :stuck_out_tongue: and GNOME software has the right bindings for pacman.

I agree that the human factor always plays a big role in these decisions.

That does sound like a nice scenario…

It must be a package not used much, and whoever uploaded it stopped using it too. In cases like this I would do as follows:

  • I would download the last snapshot of the AUR package
  • I would update its PKGBUILD file to the latest version (in most cases this means only updating the version number and the md5sums)
  • If everything works as expected I would click on “Submit Request” from the AUR package webpage and I would adopt the package – since the package has been flagged as “outdated” more than two months ago (precisely almost three years ago) my request will be instantly granted by a machine and I won’t have to wait for an admin’s approval
  • I would upload the updated package to AUR

Et voila, the whole Arch community will benefit from my (small) intervention and I will use the latest version of the package.

On Arch you really don’t need that. There as an amazing alternative: The Arch Packager-User. Arch’s Packagers-Users are fantastic weird humans. They do not want to be simple users. But they do not want to be developers either. They like to do only one thing: to package things. Whatever they find on the internet they package it.

They check the upstream website of their package three times a day waiting for an upstream update. And when this comes they update the respective AUR package faster than the speed of light. They are so fast that it must have happened a few times that they created the AUR package before the upstream package was released.

Sometimes they create poor-quality packages, sometimes instead their packages are way more refined than the packages officially released for other distributions.

I know a few users that really have a real passion for creating and maintaining AUR packages (and they are seriously not interested in becoming developers).


Everyone’s experience is different. Right?

I have a bunch of physical computers and a bunch of VPSs all running Ubuntu. (Also have a bunch of Raspberry Pi computers running an operating system in the Debian family.) I have not experienced serious breakage on Ubuntu upgrade. I have never had to reinstall from scratch on Ubuntu upgrade. No prayer needed.

So, for me, Ubuntu and Ubuntu upgrade has been stable and low maintenance over, say, the last decade. (Perhaps it was more flakola in 2008.) Before Ubuntu, I was using Mandrake. I also have some Mint (but not used much any more).

I would point out also that if a customer values stability over everything else then it is possible, indeed encouraged, to stick to the Ubuntu LTS releases i.e. upgrade at most every 2 years and potentially even less frequently (while still getting security updates, so it really depends on whether you need new functionality).

I wouldn’t compare a migration from one version of Ubuntu to the next with a (one-off) migration from Debian to Arch. Would the latter even be possible or would it be a case of “blow it away and start again”?

A migration from one version of Ubuntu to the next is just a big patch. Takes (much) longer to download. Takes (much) longer to install. Still just a patch.

I ask again: have you tried to install Parabola on Purism hardware?

If you are seriously advocating that Purism go down that route, you should at least have tried the thing that you are advocating.

I assume you are aware that dos is a PureOS developer so if he says “Not going to happen” then those are the thoughts of a PureOS developer. That doesn’t mean that he can’t be persuaded and he is in any case just one PureOS developer but I think you will need to work on the underlying problem … what is the compelling case for change?

1 Like

Feel free to do so! “Thrill of challenge” is rather low on the priority list for a company that has certain goals and has to make money in order to pay the developers; also making sure that it can achieve these goals within the available money. But with a hobby you don’t have to take such things into account at all :smiley:


There can be many solutions for who values stability, and yours is certainly one. I guess it should be clear that my proposal is not for who values only stability, but for who values a good balance between stability, recent software updates and experimenting facilities.

Of course, I agree with that. But for many users the “migration” to Arch is the last migration they will face and once there no more “migration” or “upgrades”. It might be worth a discussion.

No – although I am confident I will be able to. I have actually never tried Parabola or Hyperbola or Trisquel. Of the FSF-endorsed ones I have tried only PureOS. At the moment I am seriously curious about GNU Guix and its reference distribution GNU Guix System – I believe that the GNU folk should seriously try to find another name for “GNU Guix System”, it just does not work as a distro name…

This is a general discussion, where many routes can be proposed or addressed. I believe that the lightheartedness to wonder freely is a value in this context.

If you are really curious about my compelling case(s), the main reasons of interest for me are:

  • Bringing to PureOS the simplicity whereby non-official / experimental software can be installed / tested / maintained in a public repository as it happens with AUR and Arch’s makepkg
  • Dealing with more recent and constant software updates (a rolling release model)
  • Bringing to PureOS the amazing technical / problem-solving documentation produced by the Arch community
  • I personally just love Arch’s pacman

This is my personal view of what I value. So I wrote here to compare my personal view with that of other users and PureOS developers.

I agree with these arguments after all.

1 Like

There are other threads already asking why not OpenBSD I’m sure some of those reasons are also relevant, and I’d rather see PureOS go that route if they were to ever change.

You make it sound as if anyone can add any package to aur at any time with no review before it is available to others. That sounds dangerous to the average person whom wouldn’t know a random package from an official package.
I hope I’m just incorrectly interpreting what I read from you.

Many of the people I know abhor updates and as such will rarely do them, and then throwing in that you have to go to the terminal when you wait too long between updates…

The current approach from so many technologies lately of rolling everything and never completing anything is not one I support. Having specific versions that are points in time where these are the functions and they work is a good thing. I much prefer knowing what features exist compared to a rolling release where a feature might get added while partially functional then the dev loses interest and the feature gets abandoned to remain partially functional indefinitely… this isn’t to say this can’t happen with point releases, but generally this is a much more common flaw of rolling/agile development.

I personally just love Debian’s apt :wink:

Our user base is quite diverse, from Kernel developers to users that never used Linux before. And usually attarcted to our products for different even if overlapping reasons; user Freedom, Free Software and Privacy. We have users that like user privacy but are not interested in being shell command proficient.
And while I personally might argue with that, it is still their right. We (purism) need a system, that can accommodate these different cases and that means; that can work without needing “couple of shell commands more” for an update.

I also used Manjaro on a personal laptop, for the the last 4 years until I lost my patience with it :smiley:

Manjaro has a really nice installer that makes possible to have an Arch (yes, it is Arch) system up and running in about 10 min time. And it is easier to use than the debian installer.
But PureOS does not use the Debian installer, it uses Calamares, which makes very simple to install PureOS


Welcome to Arch. Yes, it is literally like that, anyone can upload any package they want. However there is a review process after the packages have been uploaded online. In case of malware they are usually removed very quickly.

The Arch community is aware that AUR packages might be anything and is advised to pay attention to them (paying attention might involve installing only packages from trusted users, or users they know, or packages that have received at least some votes, or quickly reviewing a package themselves before installing it).

Keep in mind that AUR and the Official Repositories are two different things in Arch.

This does not happen with Arch. Rolling release means providing updates as soon as they are ready (and there is a review process), not when a software is in its beta stage.

1 Like

I understand this argument as well.