[SOLVED] Alternatives to gentoo that solve these problems?

[crocket]

I moved from ArchLinux to Gentoo because systemd and AUR were frustrating me with various issues.
I liked the fact that Gentoo treats third party, local, and official repositories seamlessly.
However, gentoo has a few issues.

• libreoffice-bin breaks often. Often, I cannot upgrade my system, or libreoffice-bin has its libraries broken after upgrade. I don't want to compile libreoffice on a slow laptop although I compile libreoffice on my fast desktop.
  
• I use several haskell packages from haskell overlay. Due to https://bugs.gentoo.org/555266, haskell overlay maintainer cannot prevent his haskell packages from breaking often. I often cannot upgrade because haskell overlay packages are often broken.
  
• emerge alone cannot upgrade haskell packages. Thus, I need to alternate between emerge and haskell-updater to upgrade haskell packages. This is bad. Sometimes, I need to alternate among haskell-updater, perl-updater, and emerge to upgrade my system. Why is emerge alone not sufficient for system upgrade?
  

I considered Void Linux, but it doesn't support third party and local repositories as Gentoo does.
I've used Artix Linux on my slow laptop, but it often breaks packages because it hasn't fully ported packages from ArchLinux to Artix Linux.

What alternative OSes do you recommend? I want

• Rolling release
  
• Independence from systemd (and pulseaudio). Ideally, I want to avoid dbus, too, but I couldn't avoid it on any OS I've used so far.
  
• Ease of managing third party and local repositories
  
• Stability of binary packages in official repository
  
• Stability of third party repositories. I mean issues like https://bugs.gentoo.org/555266
  
• Smooth upgrade without errors (I don't want to use haskell-updater and perl-updater because emerge fails with errors during upgrade.)
  

[Jaglover]

https://www.linuxquestions.org/questions/linux-general-1/i-like-gentoo-but-it-has-several-issues-that-make-me-want-to-try-other-oses-4175624625/

Sure, there happens to be a discussion going on, what a coincidence.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[crocket]

[Hu]

Prebuilt (*-bin) packages break when they depend on libraries that change ABIs. This is unavoidable. The only possible fixes are to rebuild the package (meaning, not use a prebuilt or wait for the prebuilt maintainer to recompile the package and upload a new version) or to cease breaking the underlying ABI. Linux has facilities for clean shared library upgrades, but some projects persist in not using them, leading to more ABI breaks than are needed.

In what way do the Haskell packages break? The linked bug report requests an extension to repoman, which seems useless here. First, I can't find anything that explains why the Haskell maintainers use upper-bound versions. The bug links to https://wiki.haskell.org/Package_versioning_policy which, after some silly redirects, leads to a page that says only that this is the standard, but fails to explain why:

[krinn]

[crocket]

[crocket]

[Hu]

That issue looks like just a recounting of the negative consequences of the upper bound dependencies. I stand by my earlier claim. The only even vaguely valid reason I can see for systematically applying upper bound dependencies is if you have a high degree of confidence that new versions will usually break everything, such that maintaining exhaustive whitelists is less trouble than dealing with the inevitable breakage.

If the Haskell packages cannot or will not use sane packaging practices, you should probably not rely on them.

I still don't know why you need the cleaners at all, so I cannot comment on how not to use them. I have not needed them in quite a while.

[crocket]

[The Doctor]

Sparknotes:

a) use the desktop to build a binary. The solution is in the portage man pages, so the details are left as an exercise to the reader

b) Royal. Pain. In. The... Rear. If you must use Haskell packages from the overlay, stop syncing it so often. If it ant broke don't fix it.

This seems to be a theme with Haskell which explains why it hasn't caught on despite being a very interesting language.

c) See above. Stop trying to update something that isn't broken. Or at least update the main tree first then sync the overlays for an upgrade. The problem with overlay software is that it may be poor quality or good quality. You don't know until you try it.

[John R. Graham]

[Yamakuzure]

[hypoon]

I strongly disagree with "If it ain't broke, don't fix it." as applied to software updates. Serious bugs can often be invisible to the end user, especially if they're security bugs. Users shouldn't be expected to know when old package versions "ain't broke".

Furthermore, when something eventually does break, the process of updating to a new version is sometimes complicated if the package has not been updated recently. In my experience, a Gentoo box that hasn't received any updates for more than a year isn't worth trying to update anymore... it's better just to reinstall.

Haskell does manage package dependencies pretty strangely. The API is intended to be consistent if the first two numbers of a version string match. I have no idea how well developers adhere to this rule, though.

As far as I can tell, multiple package versions do not conflict with each other on a Gentoo system (I would appreciate it if someone else can confirm this). The ideal way for Haskell and Portage to interact may be just to slot every version of every package. Upgrading would involve installing the new version, rebuilding anything that can utilize the new version, and then letting depclean remove the old version if it's no longer required by any other packages.

[krinn]

[sitquietly]

[hypoon]

I expect glsa-check to catch the major stuff, but not all bugs are identified as security bugs at time of patching. Sometimes it's discovered much later, when the patches have been available for a long time, but not everyone uses them yet. I recently listened to a video of Linus Torvalds discussing this exact point, where he refuses to ever mark kernel bugs with a "security" label. His argument is basically that most bugs can be security bugs if someone is clever enough.

I once had to locate old portage archives (they call it the "attic", I think?) in order to rescue a Gentoo system because the transitional packages were no longer in the tree. This was not recent, and I don't remember what caused the issue, but it was much more trouble than it was worth. If you keep your configuration organized, redeployment can be rather quick and painless. Redoing my systems every six months keeps me from getting too attached and forces me to adopt reasonable data integrity measures. These habits also reduce reduce downtime when "bad things" happen.

Over the past few years, I've started updating world every day. I spend much less time tracking down messes of blocking packages and interdependency hell. It may be that the issues are much easier to solve if encountered independently. Actually, every recent issue in memory has been an easily reverted commit to the Haskell overlay, which is a lot easier to diagnose when you don't have much to update. It's a bit annoying, but I'm optimistic that it'll be resolved eventually.

The best thing I ever did was to create a cron job to sync the tree overnight and email me a copy of a pretend emerge world. This makes me much more inclined to run the update when I get to work (or fix something first if needed), and even when I can't update for a few days, I can see in day-by-day resolution what changed and created the blockers (or whatever other issue might arise at the time).

[The Doctor]

[hypoon]

That's fair enough. The nature of Haskell drastically reduces the likelihood of certain types of bugs, and I'm of the impression that a large number of version bumps are for minor new features or performance improvements, although I have no data to support this notion. So for Haskell specifically, you're probably right.

I'm actually not 100% sold that the overlay is the right approach to maintaining a Haskell stack on a machine. At least one Haskell development workflow involves keeping a separate complete set of all the project dependencies stored with the project itself (I think this is Cabal sandboxing, but I don't use it personally, so I could be mistaken). This development workflow lends itself to having a lot of software needing a huge assortment of specific versions of dependencies. That's not how shared libraries typically behave, and Portage is not designed to handle that situation (though it may be capable anyway).

[Hu]

[hypoon]

The packager isn't choosing the upper-bound dependencies. They come from the software developers. While I don't necessarily agree with it, it's the way hackage (central repository for all things Haskell) does it, so it's the way most Haskell developers end up doing it. There exists an automated tool (hackport) for creating ebuilds from hackage, and I assume it's used to generate most of the ebuilds in the overlay.

By comparison, it sounds like a ton of work to go through every ebuild in the overlay and cross-reference the corresponding Haskell source code with multiple versions of its dependencies to determine a more reasonable upper-bound version, or make the judgement call that the library's API seems stable enough to remove the upper-bound version altogether.

In other words, my understanding is that the Haskell overlay functions similarly to a compatibility layer between Portage and Hackage. There are two things I really don't understand. First, why delete old versions from the tree? Is storage space for ebuilds that tight? Second, why do I have to mask a new version to prevent portage from trying to upgrade it despite the fact that portage knows the upgrade exceeds the upper bounds of other installed packages (and complains about it)? Shouldn't portage understand that the new version does not meet the dependencies of an installed package, and therefore should not be upgraded?

[The Doctor]

Portage is designed to be a powerful tool for a power user, not an AI. Portage stabilization criteria in the main tree dictates that for a package to be stable all of its dependencies must be as well. If the developers do their job right you never have a problem with mixing stable and unstable unless you choose that path yourself.

An overlay need not adhere to this as they can do whatever they like. Unfortunately this confuses portage since there are a large number of ways to proceed. All it can do is present the information and beg for help.

I have no idea why the maintainer wouldn't want older ebuilds around. Maybe it is just to prevent too much cruft from building up and causing another headache. However, I will venture a guess that the dependency nightmare is a large reason Haskell is not fully supported in the portage tree.

As I've said before, I've played with Haskell and it is a nice language, but I think the overloads have made it such a mess that no one really wants to develop in it. Other functional languages (like lisp) do not have this problem and are widely used (despite somewhat user friendly not being).
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[Hu]

Yes, it is a significant amount of work to check the dependencies if you cannot assume new library versions are backwards-compatible. That is exactly what the Haskell package maintainer is required to do now, every time a new version comes out. Somehow, every other language supported in Gentoo manages to maintain enough backward compatibility during library upgrades that the general standard is to assume new versions won't break things. In those cases where that assumption fails (OpenSSL-1.1 comes to mind), the new version gets masked until the problem is resolved.

[crocket]

Let me summarize.

• Repoman doesn't check upper bounds, so haskell overlay maintainer makes mistakes often. https://bugs.gentoo.org/555266 tracks this issue
  
• ebuild EAPI=6 cannot track fine-grained ABI changes of haskell packages, so haskell-updater is needed for now. https://bugs.gentoo.org/449094 tracks this issue. EAPI=7 will fix it.
  
• libreoffice-bin breaks often due to reasons unknown to me. I have never had other binary packages like firefox-bin and google-chrome broken during upgrades. While it is true that binary packages will break eventually due to ABI changes, libreoffice-bin seems to break due to other factors.
  

[The Doctor]

I can explain (some) of the Libre stuff. Libreoffice is a big build that links to many, many other libraries. It also has a relatively slow release cycle.

Firefox and chrom(e/ium) update with regularity and most of their libs are bundled, ie shipped with the binary. This means less to break and the builds are refreshed more often thus preventing bit rot.

I understand why the bin options exist, but I dislike them because portage is fairly good at detecting when they break but the only solution it can offer is to reinstall it. That works for a source package but it doesn't fix the problem with the bin.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[crocket]

I think I'll stick to gentoo on my desktop. But, I'd like to try other OSes on my laptop.