Hacker News Reader

Comment by Wronnay | Hacker News Reader

Rolling Releases are basically my main reason why I choose Arch Linux over Debian.

It would be nice, if Google and Debian could team up together to bring a Debian Version with rolling releases.

Imagine the stability of Debian packages together with the easiness of upgrading an Arch Linux system - would be a dream for every server.

View on HN

Funny, a stable release is the main reason why I choose Debian over anything else. I enjoy that it doesn't change too much. And for the occasional software for which I really want (rarely need) the upstream version, backports, flatpak, docker or compile from sources got me covered.

But the beauty of libre software is its diversity. Keep on using what you like ;)

it exists: either Debian Testing (a week or so of proven stability) or Debian Unstable (latest and greatest).

If one follows the best practices for them[1] (installing apt-listbugs and apt-listpackages), one gets information of bugs and API-breaking changes before performing the upgrade, and can decide to pin the specific package as needed, and it will automatically get released when the bug is solved.

This is thanks to how the Debian packages treat bug reports, and the debian/NEWS file. I can't believe other distributions get it so wrong for so many decades.

Plus, these 2 distributions (Testing and Unstable) get all the automated QA usual from Debian: autopkgtest integration tests, piuparts, lintian, reproducible builds, policy conformancy..

It seems it's no coincidence that gLinux from Google, rolling release, and in TFA, is based in Debian.

[1]: https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...

No, it didn't exist (outside Google). Debian testing is not a rolling release because it is not a "release", it lacks internal coherence. As the article mentioned, testing packages are built in unstable and then simply moved to testing individually, with no regard to moving all the build dependency chain together. So you end up with packages in testing that were built using packages that are not in testing yet.

Edit: also testing lacks timely security updates, they don't bother to cherry pick security patches for testing and instead just wait until the new secure version make is way thru unstable.

That sounds like moving goalposts: the OP mentions Arch's rolling release. And Arch doesn't rebuild the dependents when a package gets updated.

On the point of Testing lacking timely security updates, it's fair. But I invite you to compare the timelines with other distributions (including from corporate backers), and you will realize that their manual testing takes even more time.

Plus, you always have Debian Unstable. And apt-listchanges and apt-listbugs work fine in Unstable. It's the same experience: you get notified of serious bugs before upgrading, you get to pin packages and the pins are automatically lifted with the fixed version.

> And Arch doesn't rebuild the dependents when a package gets updated.

That’s not the point they argued, though. According to the comment you replied to, given version X of package A built against version Y of package B, Debian testing might contain package A version X but not package B version Y.

As far as I know, this situation does not occur in Arch.

Debian testing is a rolling release with some caveat*

I use it on my desktop, but use stable for my servers.

* it is rolling until a new stable is released and at that point testing is frozen and you have to upgrade to the new testing version

Reply on news.ycombinator.com