Slow package updates on Gentoo / Outdated packages

[timon_54045]

I have switched from Arch to Gentoo about a year ago and I really like the experience so far. One thing that has bothered me from time to time is that it seems that package updates seem to take quite some time in many cases. I use ~amd64 globally, but many updates simply take long to get into the repos. Gnome 47 is not available yet, despite being released about 4 months ago, many of the core gnome apps are also not updated yet. ffmpeg 7 has been masked for over half a year now, just to give a few examples. I know flatpaks offer a way around this in some cases, but this does seem to circumvent the reason why many of us use Gentoo in the first place.

Personally, I don't really have the time and knowledge to contribute directly to solve this, but I would like to know what the issue is in most cases. Would increased funding help with this situation? I would be happy to contribute to Gentoo and/or Gentoo developers financially if this is what's holding it back in this regard. If so, what would be the best way to contribute?

I hope this post doesn't come of as too complain-y, I am genuinely interested in what the community thinks about this.

[Banana]

There is more to it and more complex why things are as they are, so the first step to get involved, read https://www.gentoo.org/get-involved/contribute/
_________________
Forum Guidelines

PFL - Portage file list - find which package a file or command belongs to.
My delta-labs.org snippets do expire

[sam_]

New versions of ffmpeg end up breaking a lot of packages because upstreams don't adapt to deprecation warnings and so on. You're free to unmask it locally. We're often more exposed to issues like this given we're a source-based distribution. Arch doesn't always do mass-rebuilds when packaging something new that is "core" and so they don't always notice something can't even be rebuilt against e.g. new ffmpeg immediately. You can keep an eye on Bugzilla on tracker bugs for FFmpeg at least. I asked toralf the other day if he could start tinderboxing ffmpeg-7 so that may start filling up soon too.

GNOME requires someone dedicated to help maintain it (ideally several people) which folks have written about on the mailing list and I think r/gentoo before.

Donating to individual developers can help. I don't personally have enough hours in the day (or particular interest) for/in GNOME. You can see what Matt wrote about it in e.g. https://mattst88.com/blog/2021/05/13/GNOME_40_available_in_Gentoo/. You can also see https://public-inbox.gentoo.org/gentoo-dev/CAEdQ38H7gmcL4J+RjqwJSzTHENZuqBdye3L7PMuEBJvYqBqPTw@mail.gmail.com/ and https://archives.gentoo.org/gentoo-dev/e50d4c32f263da91618da27be650d22bc6d55407.camel@gentoo.org/. GNOME also tends to have people submit pull requests but they end up not responding to feedback or addressing it properly/throughout which doesn't help. I had to drive-by fix several things like this that would've been clear from build system diffing.

I think often people don't understand the difficulty in packaging stuff, let alone in Gentoo, where you want to make sure it works for everybody. You need to diff all build system changes, make sure everything is reflected accurately, across 100s of packages for something like GNOME. So, locally bumping it and having it Work For You doesn't mean it'll Work For Everybody. Especially true for automagic dependencies where something is used if installed but not used otherwise, which then breaks binpkgs. Often, you end up finding that something needs upstream changes (either a bug report or sending them a patch) and they may want to discuss it or suggest a different approach. Another problem is sometimes other distros can workaround something more easily than we can, e.g. glib-2.80 introduced a circular dependency on gobject-introspection: binary distros can easily solve that circular dependency "once" for their users, but we don't have that luxury. See bug 937616.

You also have to then e.g. consider whether some new functionality upstream should be made optional. If it isn't, some users may complain. If it is, upstream may complain because the configuration is "unsupported" or unusual or leading to odd support requests or something. This applies to many cases of new build system options if the option even exists. You have to familiarise yourself with the pros/cons of the functionality, the new dep, go digging upstream to see what it really does.

Funnily enough, when searching up these links (I knew the discussions existed but couldn't find some of them immediately), I found threads on /r/gentoo where people complained about KDE Plasma 6 being "masked for 6 months" - not understanding that there were 1.5 people working on that in Gentoo, and it was unmasked in ~arch pretty early, we were just very careful about when to stable it and wanted everything to be ready. They interpreted that as us being "6 months late" (because it wasn't stabled for 6 months or so from release), despite heavy work ongoing both upstream and downstream in that time. You can't please everybody.

Both of the examples you give are special in their own way.