Debian Packages That Need Lovin'
wnpp.debian.net
wnpp.debian.net
More recently, so many things I want to use are not available as a reasonably up-to-date package. Some examples are hugo and eclipse, where the versions provided are unusably ancient.
https://lwn.net/Articles/842319/
Meanwhile, more and more software is actively hostile to packaging / distributions, and things seem to have devolved into grabbing things from random github repos, or various dedicated/language-specific package managers like npm, pip, brew, ...
It's definitely annoying, seems like a step backwards, and its not clear to me whether there's some better distro i could be using, whether some funding / volunteer time could help, or the world has just "moved on" (backwards...) from the idea of a linux distribution with reasonably stable, up-to-date packages that "just work" for basic infrastructure so you can spend your time developing on your own project, instead of with the tedium of fetching and installing software and managing version compatibility problems yourself.
If you exclude the duplicated architecture packages in the Ubuntu repos and include the community-maintained packages, Arch has more packages new packages seem to commonly available within 24 hours of an upstream release.
For example, I use some utilities based on "rofi". A search for Ubuntu packages containing "rofi-" contains just no results, but a search for Arch packages returns about 50 results.
https://packages.ubuntu.com/search?suite=groovy§ion=all&...
https://aur.archlinux.org/packages/?O=0&SeB=n&K=rofi-&outdat...
AUR packages look easier to maintain than PPAs, so I'm more likely to get get involved with packaging something on Arch then I was on Ubuntu.
Hah! Very similar experience; see my sibling reply :)
Arch Linux is just an entirely different thing compared to Ubuntu. I'd like someone who isn't me to make sure stuff works. Only very rarely will I be bothered to do actual work to upgrade to a new breaking version on my daily driver. Randomly breaking my shit on a Tuesday will make me install something more stable. On the rare occasion that I'd like to try something unstable, I can usually find a PPA or something. I don't like edges that make me bleed on my base OS.
But there definitely is something nice about general stability (until you have to install something on an old OS that requires a new package and you enter a whole new hell).
Largely a myth and config-dependent. I used to have this issue 10 years ago but now most of my troubles are self-inflicted. Things are as stable as they come when using software from the official repos.
In my experience, Arch is one of the most stable OS's I've seen. But I suspect a lot of it has to do with what you're doing with it. First, ThinkPads are generally well supported in Linux. Also, I've never seen any reason to use GNOME as a desktop. I used to run XFCE on Compiz, then i3 as Compiz stopped being updated. More recently, I've switched to sway, and I've finally started using PulseAudio because it's required for Zoom. Obviously, i3 and sway aren't for everyone. YMMV.
Yes and yes. Source: I run Zoom with i3.
But the one you might want to consider instead is called PipeWire. It implements the ALSA, Pulse and Jack APIs with a single implementation and it's pretty much the future of audio (and video casting) on Linux.
If you're using Wayland, you're already using PipeWire, but likely not for audio. On Fedora you can follow the instructions here https://fedoraproject.org/wiki/Changes/DefaultPipeWire which basically boil down as "uninstall pulse and install these packages" and you'll be using PipeWire for your audio.
I had tried several times to switch to it and it was not ready, but about a week ago I've been able to make the move with no loss in functionality and even got a fix to an old bug that affected my sound card, so at least with version 0.3.22 I can recommend giving it a go. Switching back to Pulse if bugs arise is trivial anyway.
Zoom on sway works, but since sway runs on top of Wayland and Zoom doesn't have the bindings to communicate with Wayland, I'm fairly positive screen sharing would not work. At least, not out of the box ... it might be possible to connect it to some other screen capture process if you're adventurous.
PulseAudio runs on top of ALSA. Traditionally, Linux desktop applications connect with ALSA and you can still manage ALSA directly. More recent applications, such as Zoom, expect to connect with Pulse and don't support connecting directly to ALSA.
From a user perspective, Pulse offers some advantages like being able to manage audio levels for different applications independently. In early releases, Pulse was unstable and difficult to troubleshoot, so it was easier just to use ALSA directly. Pulse has gotten a lot better in recent versions.
On the same line, I don't realize that my Bluetooth driver was broken until I checked dmesg. This one wasn't fixed upstream yet, but I don't need Bluetooth on my laptop anyway.
Still consult the release notes before upgrading between major versions in case there are relevant release-specific gotchas before/after/during, and for generally helpful precautionary advice, but quite often there aren't.
- desktop users want the latest thing, immediately.
- server users want nothing to change, ever.
I want things to work. I don’t want to spend my time arguing with my tools, just for the sake of having the latest and greatest. I might go through and upgrade everything every couple of years, at most.
Beyond that, I just want security upgrades to happen without me having to think about them.
Right now, I'm running Arch Linux with a small smattering of self-compiled stuff. Arch seems to actually be pretty stable, unless you're using their 'testing' repos... and it's very close to bleeding edge. Their secret, I think, is staying as-close-as-possible to upstream -- the trouble usually starts when distros start to add large patches. This has been a huge issue for me with Debian/Ubuntu.
EDIT: Sorry, I feel I didn't explain this very well. The main point is: You can have multiple versions of all the software on your system, including stuff like PostgreSQL. That's actually very powerful.
Another potential problem is the licensing and root-on-ZFS.
Personally, I'm really looking forward to an in-upstream-kernel FS like bcachefs. (I'm actually a fan of ZFS, we use it on our servers, etc. I still feel a bit uneasy about the licensing issues and the fact that it's not in-kernel.)
I think even the Linux kernel would be a component of NixOS and could be substituted with something else.
The whole idea is just an enterprise-proposal away from getting polished around the edges.
If something needs to be installed system-wide, like dev headers for ncurses or something, I’ll install it through apt. But for nearly everything else (git, Neovim, fzf, tmux, htop, ripgrep, ...) I install it though Linuxbrew.
Linuxbrew formulas are up to date, not ancient. I have yet to run into a problem where a formula only worked on macOS and not Linux. Also for homebrew core packages they publish pre-built bottles so that I don’t have to build everything from source.
It’s pretty great. Pop!_OS is pretty much zero-upkeep, and Linuxbrew has everything I need.
I’ve said it before but the only thing really missing to keep me from using Linux as my main OS with this combo is better desktop mouse sensitivity and keybindings that mimic macOS system-wide (Cmd-C, Cmd-V, ...)
I've wondered about this. This would depend on upstream being sane about how it does things or puts things.
Is this always the case?
I think modern package managers for programming languages show us the right approach here. A cargo binary crate can be built on any platform that rust supports, it knows it’s dependencies and the compiler flags are passed in in a consistent way. I could imagine cargo having a 1 button “publish crate to dpkg/homebrew/ etc etc” button. Or alternately, I could imagine Debian allowing crates.io to exist as part of the package namespace. Then you could “apt install crate/foo” and the “foo” package author wouldn’t have to think about dpkg at all. (Maybe this already exists? It would be a sweet way to use the ppa system.)
The same balance of forces that mandate all of that toilsome work are exactly what would prevent any standard bundler from succeeding.
You can follow https://utcc.utoronto.ca/~cks/space/blog/linux/SnapsFlatpaks... and https://www.techrepublic.com/article/why-snap-and-flatpak-ar... and various related discussions around this and eventually I am confident you will conclude that while things may change (today there's docker in the mix as well, tomorrow there will be something else), the one-true-packaging-solution will never be invented.
There are simply far too many fundamentally conflicting interests to ever prevent that level of standardization.
What you see now is more or less what you will always get. Or, perhaps, we'll see something worse (i.e. only fully locked down computing devices, only app stores with no sideloading capabilities, various other dystopian outcomes). I'm pretty sure we're not going to see something better though; we've had plenty of time...
I've been very happily using Guix as a package manager inside my Debian, thereby having a Debian with up-to-date versions of packages and access to all the other benefits of using a next-generation package manager (specifying release candidates, docker-like portable builds, plus emacs integration).
Just have to be slightly careful not to install packages via Guix that might cause conflicts, especially with Gnome. But if you do you can always just hop into a tty and `guix package --roll-back` to get back to a working build.
Maybe one day I'll migrate to Guix as a distro in itself rather than just a package manager within a foreign distro (Debian), but for now the setup works well, and it's also a nice way to get experience with Guix before diving into the deep end.
It does basically work, but it can be a bit jarring, depending on exactly what you're trying to do.
Their packages repo has a “latest” which is very up to date. One can also use ports for more control and custom options etc
Devolved from what? I believe from software not having any dependencies unless they absolutely must because adding dependencies is such a royal pain. Software written in C and C++ has long been used to the system package manager being language package manager, and the (UNIX) OS being its IDE.
Debian packages a noticeable amount of C-based software which is just old. Emacs, for example. I suppose that skipping major versions (25 to 27) is considered unacceptable, and packaging and maintaining several versions is just proportionally harder.
(This is why my laptop now runs Void, and I get a fresh Firefox next day after the release.)
But that's what I'm talking about. Suppose there is no software in Debian that uses a Python dependency that you need, hence no one packaged it. Now instead of adding a line to your setup.py (or whatever Python devs use), you have to go through the entire adventure of cooking a Debian package if you want to follow the Debian way. And them submitting it to the main repo which is an adventure and commitment of its own which most people are not ready to make.
Sure, that works to the benefit of everybody, not only your app. And that's the whole point of Debian distribution. Debian developers work on improving Debian. Not on publishing their software. This is the main difference between “app stores” and “package repositories” and “distribution”. Debian is a distribution, and a package repo is only a part of that.
But it kinda saddens me that every language ecosystem has their own package repository, and every distribution ends up having to do effectively busywork of adapting those packages to their distribution and its rules.
I guess this depends on your definition of success, but from my perspective as a Python developer, it doesn't really. Most Python software I'm aware of encourages users to get it by other means (e.g. pip, Anaconda, containers), and anecdotally, the majority of users seem to do so. The occasional people who use apt cause frustration 'upstream' when they report bugs in a version that's 2 years out of date.
One package which I help maintain upstream had a security flaw with a CVE, left open in the Debian package for many months after we fixed it. No-one upstream is a Debian developer, and no-one in Debian was updating the package.
Python started out with a traditional model of applications sharing libraries, and is now moving in the direction of self-contained applications with separate dependencies. Languages like Javascript and Rust went straight for the latter model, so are probably even less amenable to Debian packaging.
Seems like now that hyper scale cloud vendors are displacing distros as gatekeeper, we’re going down a road towards niche packaging for languages, frameworks, etc.
UNIX is C's platform, hence POSIX and its influence on C and C++ based OSes.
C was born to make UNIX portable, and C++ was born a couple of years later on the same office rooms where UNIX came to life.
Any guest language introduces additional hurdles, debugging tools, binding libraries, editor support, and naturally OS package managers.
Now, I think there's a pretty nice balance going on. Seems like the distros do a good job of getting you to a working GUI and command line, and we've had all kinds of new tools show up for getting to the latest/greatest for development. That said, I think the distros could do a much better job helping devops and admins understand how to use tools like apt and yum. Then there's the whole container thing, which really does give us a more universal way to distribute software (ok, maybe not snaps).
I understand your comment but Hugo is the wrong example, this package is actively maintained and is up to date in Debian unstable.
It took me 5 days to figure out how to package a complete web app with params, upgrades, post install transpiling, db init, etc.
And I haven't put that on a private repo yet, it's yet another annoying thing to do.
Nothing is well documented, doc is old and confusing, the tooling is archaic and wants to inflict pain (debconf anyone ?), the life cycle of a Deb package is atrocious to get right.
And you have to do all that in raw bash scripts. Not there are no alternatives, any scripting language is potentially usable, but the support is poor enough to deter you from them.
It's not I don't want to contribute to the ecosystem, but I won't invest the colossal effort and exercice in frustration to overcome the barrier to entry. My packages don't even need to go to the official repo, just let me do my things in peace.
Make a python lib that let you describe a package, hook on life cycle events to run code, with clear documented recipes et where to put what types of files, and let me run that to generate the Deb. Event web pack is easier to use for God sake.
I'm not even touching the process of packaging something to be included in debian repositories here, which is another beat entirely.
Quit the smug act, debian packagers. You don't know better.
You do know better on how to design a distro and protect the official repository. Great. I praised you for that for decades.
But you know nothing about making your users life easy. You just don't. So ask them, and fix that, or don't complain about no contrib. This is not news, we raised our voices for years.
I contribute all the time to Foss in code and doc, I donate in mass. We ARE willing to help. And we do.
It's not us. It's you.
If only that were true. The entrypoint in Debian packaging is a damn Makefile.
I've been a Debian Developer for 16 years, and creating packages for more than that. Saying that I like it or that there aren't problems would be the archetype of Stockholm Syndrome.
Here is a "pragmatic" way to write Debian packages without relying on non-Debian tools: https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-pack... (I am the author).
But other than that, I quite agree with your stance: we (Debian) makes life of our contributors harder than it should be. Unfortunately, there is no awareness in the project for that. People trying to change that just silent themselves, like https://michael.stapelberg.ch/posts/2019-03-10-debian-windin....
It doesn't cover anything fancy like post-install actions though.
No accountability, tightly knit cabal with high barrier to entry, refractory to external opinions, etc
Which was the intention I believe - hence why https://packages.debian.org/stable/doc/anarchism is a package.
But that's beyond the point that if what they really desire is contribution, which they have been claiming for years, they should make it less painful to package software for the plateform, which we have been claiming for years.
Meson, Conan, winget+msi, and the hundreds of other mixtures of build system + package manager also take long to understand. And you have to understand each of them.
Homebrew does not even want package authors to create packages themselves.
It may be a matter of perception: If you count all web searches, interactions with CI, conference talks that help you understand a more recent package manager, it will also add up to 5 days.
Creating a deb is more boring, it's just the machine and you.
I never even read the documentation, I just did:
$ file some.deb
$ ar --output somedir some.deb
$ ls somedir
I'm pretty proficient in bash myself, and error handling, debugging, decoupling and refactoring in bash are all horrible. It's just not design for being good at a script with more than a couple of lines. The fact we do use it for such purpose does not make it good at it.
The fact it has no namespace, the lack of decent data structures and the very limited functions also all leads to making it a poor foundation to build a lib on. Hence deb packages don't have any kind of framework for basic things: you are on your own.
I have packages closure, Java, python, php, c and very complex piece of software with weird version formats and so far Debian packages cover all those cases for me.
I find that is pretty easy to complain about things we don't know, or rant when frustrated, but after investing a bit o time to learn and understand how it works pays off.
IMO, what really needs some lovin' is the official onboarding process for new contributors.
Regarding the Debian package process, etc.--I'll be blunt and say that all of the pain you see is by design. It's not designed to be a super inclusive or friendly community for contributions. There are explicit gatekeeping checks in place to ensure everyone follows "the Debian way" (nevermind that there is no clear definition of "the Debian way" that anyone agrees on and it's only used to enforce power hierarchies in the project). It comes from an even older gatekeeping around "the Unix way". IMHO ignore all that rubbish.
That is disingenuous.
As much as I am annoyed by Debian gatekeeping, I am also gratefull that there still exist one Linux distribution that's serious about their users rights, aka software freedom, and that is able to properly discern, for instance, that Ubuntu was not going to be easier for newbies to install on their computers than it was going to be easier for Ubuntu to force, say, amazon crapware on newbies computers.
I hate Debian gatekeeping yet one have to admit that's the last line of defense against appstores everywhere and the last living example of what user empowerment can be.
Package management on Debian has started to look much like an app store (in a good way) with Gnome Software[0], just without all the non-free stuff.
And I'll offer a defence of that barrier - Debian isn't about making an operating system. It is very explicitly making a free operating system. Listening to one Q&A session after a Stallman speech was more than enough to show me that there are a lot of capable developers out there who just don't get the idea of free. While those developers are a mighty force for good they need to be kept away from the Debian main archive. It isn't a place for them. They can go start their own project (eg: Ubuntu, Mint).
> It comes from an even older gatekeeping around "the Unix way".
That's not gatekeeping, that's a very specifically-defined approach to operating systems.
whereas anyone is welcome to contribute to debian, they just have to follow the rules. there's kind of no meaning to the term "gatekeeping" if any organization that has rules to follow counts.
But you do realize that I'm objecting to its use as a pejorative here.
I don't mean to say that you have to accept it as it is. If you don't like it, just go somewhere else. If you are motivated to help fixing stuff, that's wonderful. Just don't pretend we like to make stuff difficult for the sake of it.
Disclaimer: volunteer Debian Developer, always on short time to contribute.
Every few years, there are various attempts at simplifying packaging, usually in the form of a more universal helper to build a package skeleton, but it doesn't really reduce the complexity and until now, none of these helpers replaced debmake.
Since then Debian packages have become easier to create and maintain. And it’s a great skill if you ever need to create e.g. a custom-compiled version of nginx or some such. It’s a really well thought out system and I am surprised it isn’t more widely used. By contrast Docker seems to be more portable but way more of a pain in the ass.
I know there is an install, postinstall, and remove scripts but don't have a clear idea of when exactly they will get called and what "interface" they must implement.
It would be really helpful to have a "package lifecycle" state diagram like this https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram that shows all the states and events that "fire" based on .deb scripts and metadata.
I skimmed the New Maintainers Guide for a rough idea of what to do and then used the Debian Policy Manual with the various debhelper manpages for specific references of what each field/script meant. I also dig into the source of some packages to see how they were packaged (for example, when I was creating an archive keyring). The two areas I had the most trouble with were deb triggers and debconf, which only seem to be documented on external sites.
New Maintainers’ Guide: https://www.debian.org/doc/manuals/maint-guide/
I do agree that once it's setup properly with a CI pipeline, it becomes a breeze to install and maintain updated systems.
A lot of well known packages (Apache2 / OpenSSL / LibreOffice etc.) have no owner?
If you look into the details for some these packages, you will see that it is a dead discussion forgotten even by the person who initiated it, a decade ago.
E.g. the discussion about Libreoffice is not about Libreoffice at all, but Apache Open Office, and you can see that there are people who have offered help, but the OP never responded to their offers.
Just click on the links on the package names and read for yourself.
EDIT: Previous HN discussion about LibreOffice's lack of resources: https://news.ycombinator.com/item?id=23793942
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910917
The RFH is mostly here to get more people involved, by the maintenance of Apache2 in Debian is going well and the latest version is currently packaged: https://tracker.debian.org/pkg/apache2.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523
But there are a few simple principles operating here. Mostly they follow from the Debian being a collection of 1000 developers, all equal. There is no CEO who can decide what's important and force someone to do something. Instead, Debian is a do'ocracy. If there is a dispute, it always takes the form of two Debian developers wanting to do something different. (This means users don't get a say. Not because Debian doesn't care, but because it's a do'ocracy and users can't do anything without going through the lengthy test and evaluation process that Debian insists all it's developers must go through.)
Asking for help, then not taking up an offer breaks this first rule. We don't have two Debian developers doing conflicting things, so there is no conflict. It may not be the nicest way to behave, but shrug no one can force someone to do something like supervise a newbie. After all Debian developers are unpaid volunteers, and you can't force an unpaid volunteer to do something.
Lets take it further. Lets say we have two Debian developers proposing to do different things. Lets say a Debian developer wants to upload a new version of libreoffice. A second rule comes into play here: the package maintainer is king of his packages. He can resist just about anything providing he isn't breaking any policies. So providing the libreoffice package is in reasonably good condition - not too old, all CVE's fixed, yada yada he can resist the new version. In fact I've resisted people wanting to update my package to a beta release, so I've don't just that.
Now lets say Debian packager of libreoffice has let it languish, in fact languished so much it's accumulating CVE's. And worse, in order to resist he must be actively deleting the new version. So we have two people doing different things, and they conflict. At this point either developer can invoke Debian's dispute resolution mechanisms. Interestingly the team doing the dispute resolution isn't allowed to do something themselves, they can only chose which (or perhaps neither) of the things done can proceed. In this case not updating a package accumulating CVE's breaks policy, so they would probably allow the developer uploading the new version to proceed.
This is a very different way of going about getting work done then people normally experience in their working life. A work environment is typically far more hierarchical and authoritarian. A boss can actually order someone to accept help for example :). However, Debian's system is demonstratedly every bit good as RedHat's. Security patches come out just a quickly, and it has far more packages. And clearly as there are 1000 of us developers all pulling together, it can't be too hard a system to work in.
The honest answer is I don't know. No one has explained it to me, and I wasn't there when it was born. But Debian being what it is, I'd be surprised there if there was a grand architect, or that it's possible to point to a definite moment in time it became a thing. The formality Debian has acquired over the years looks to be to attempts at codify existing practice after it was challenged. Codifying works to prevent reoccurrences of the unpleasantness associated with such challenges.
The practice has always been someone volunteers to maintain a package, they expected nothing but the freedom to do the job in the way they saw fit without fear of interference providing they followed policy, and no reward except the bouquets and bricbats for how it turned out. When put that way it's not much of a reward, but it's been enough to attract a lot of us to the task.
The importance of that reward can best be seen by looking at what selfish motivation is left if you took it away. Good deeds are great and all, but when done where nobody can see them or others can easily take over after you've put all the hard work in or worse can claim credit for it, such hidden deeds are not great motivation for sticking at it for years.
We are all very aware that binds us and we are protective of it. But human nature being what it is, it can't be surprising the second rule has been challenged on many occasions, which has lead to it being codified in so many ways it's become part of Debian's DNA.
Please don't pick up a package just because you think it would be cool to be a maintainer. If you are not invested in the well-being of the userbase, you will get called out.
The person doing this might get called out, but will the negative consequences of that calling out outweigh the resume padding benefit they experience?
If not, then I would expect this to keep happening.
First, choose a package that really matters to you. On a daily basis. A package that you yourself would NEED to have it up2date the next day a new version is out.
Get the source deb and try to build it. Usually it's not very hard.
Then, try to do the same on all the debian variants (unstable, stable, ...)
If you succeed and the package works, you have the prerequisite competencies, at least as a beginner.
Then, these are some of the things that you will need to do, quite often.
Change the configuration of the package description so that you can build it with a later version of the source. For all variants of the distro.
Then try the same with the package dependencies, where those dependecies are not needed for other packages.
Then try to push it as close towards the latest source version, as you can without breaking stuff.
Once you do all that without issues and you are confident that you can use the version you built from source as a daily driver and you are not bothered by that, contact the original maintainer directly and offer help, sharing the details what you did as proof that you are competent enough.
If the maintainer is uncollaborative or unresponsive, put up your own repo for public use, and invite the public to install the package from your repo, so that the public will see some benefit and you will receive zillion of bug reports to further streghten your competence level.
If you are an active developer in the language that is used it will be easier, but you can do it even if you are not.
Example. Todays news here, is the latest release of Kodi. Debian does not have the most recent version. Some months ago I had an issue with the Kodi from the debian multimedia repo, so I decided to build it from source. It took me the better part of a day to have all the build tools installed and set-up everything, starting from zero. But in the end I had the latest Kodi running and it was running like that for 5 months and I even forget that I built it.
I managed to do that without even looking into the source code. In fact if you ask me what programming language is used to develop Kodi - I really don't know and don't remember.
Package maintainance is more about testing than about building.
So a list like this can serve as a guide in the process of choosing where to help. Just sort by number of users that use the software and go down the list until you find something that you use daily and where you would like to have the most recent version available and would volunteer your effort for 2-3 years (it is not really helpful if maintainers change every couple of months).
I'll also have to find something my employer is happy with me working on, but I think you've pretty clearly laid out what I'd be signing up for, and I appreciate it.
PS: lots of different ways to help Debian:
Is there another Linux distro that gets multiple eyeballs on (core) package changes and proper security reviews that you folks would recommend for daily driver?
But the rpm package need adoption and refers users to alien, but the alien package is orphaned.
hah, looking at wikpedia it seems LSB support have been dropped by Ubuntu and Debian in November 2015.
i do appreciate being able to apt-get install some obscure package and have often wondered how it's a sustainable system that maintainers are putting in effort to package these things up into a distro for me. but maybe it isn't?
I don’t even know the last time I found a publicly accessible mp3 url stream, or listened to a local mp3 file. Local files had to be like 10 years ago.
I have been using it like that almost every day for 15 years now.
My theory is that it is obviously because there is a way how to run Eclipse, without any issues and without the need of an officially tested debian package, so there is not huge demand.
Something like Netbeans doesn't need a debian package but Eclipse is split into lots of jar files that each depends on some shared libraries.
Do click on the package titles to go through to the relevant thread. For most the packages you'd be worried about, what you'll see is either a well-reasoned handover of responsibilities, or a simple call for help.
(Or just look at the 'type' column - RFH is Request for Help, RFA is Request for Adoption. Important or complicated packages looking for more team members isn't a panic.)
The main reason I'm still with gentoo is inertia and I really like the tools and just the way things work. The problem really is the portage tree (basically the repo) which is become more and more bare as the years go on. For example, I miss eix whenever I use debian, apt-cache just isn't as useful. Also, having to use not systemd is a plus and a reason I won't use Arch. Any suggestions?
I don't need USE flags all the time or compiling everything with -O3 -march or whatever, for most things it's just a plus that it might be faster. I think the one thing that might actually matter for me is in Gentoo fixing broken things is more direct, just compile, while I've had issues that persist on ubuntu even after reinstalling something. It just felt like there was somehow "stale state" in my OS which even sounds ridiculous saying. But, at this point, I can't handle breaks in portage because while you can fix things, it requires mental effort on my part and I'm tired of it.
EDIT: reading your comment, if you're asking for my opinion I mean look at this in particular:
https://bugs.gentoo.org/420783
ioquake3 was literally removed from portage for this "bug" which even if you accept that it's a hypothetical issue has easy patches that were never included, and it was removed, essentially removing hosts of open source fpses from portage! I even read a forum post talking about "upstream" not caring...upstream? ioquake3's release was charity, it's not like an active project.
This has been happening for a while. I've been here since 2008 or so and the instability and removal of slots within months has gotten out of hand. Again, the tooling is great, emerge, eix, the whole system of configuration files is awesome and I'm just used to openrc. I wish I could keep them but the slot removals in portage has just become such a chore to deal with.