Debian Developers Figuring Out Plan For Removing More Unmaintained Packages
Posted by unixbhaskar@reddit | linux | View on Reddit | 101 comments
Posted by unixbhaskar@reddit | linux | View on Reddit | 101 comments
DonutsMcKenzie@reddit
This might be a controversial opinion, but I'd really like to see distributions spend less time maintaining user-level graphical application packages and much more time on providing a stable and secure base system, customizing and curating the user experience, and developing improvements to upstream software.
These days almost every GUI application can be maintained and distributed through Flatpak (in many cases by the development team themselves). For all of these various distributions maintainers to go through the process of building, packaging and maintaining the same pieces of software over and over again is not the most efficient use of their time (even though I do appreciate it).
jr735@reddit
That's not going to fly in Debian, not a chance.
Indolent_Bard@reddit
Couldn't Debian just freeze the flathub repo or something?
jr735@reddit
I don't know, but I still can't see it flying. Debian is about stability, not upending the entire process. I like apt package management and that's why I'm there.
Indolent_Bard@reddit
Well yeah, but why couldn't they have a stable flat pack repo? Though I suppose that would kind of defeat the entire purpose of Flat Pack to begin with,
jr735@reddit
Sure, they could. They could also start using pacman, or make Debian declarative. And all those things would defeat what makes it Debian, just like having old packages in flat defeat what flat is.
This is what I suggest. Someone who is interested in this (clearly not me) set up a stable distribution where only the absolute core is Debian. Then, they can populate whatever they want by flats.
Which packages in Debian do you think should be replaced by flats? There must be some list.
Indolent_Bard@reddit
Honestly, I'm not knowledgeable enough to say, nor do I actually think there's any point in replacing any Debian packages with flat packs. That being said, what you've described would basically be an immutable Debian distro.
And that raises an interesting conundrum. Flat Pack kind of defeats the stability purpose, but on the other hand, an immutable file system means you're way less likely to break things. Perhaps an immutable Debian distro makes sense, or perhaps it's nonsense.
jr735@reddit
I would say nonsense. There is no way in hell Debian is going to completely upturn what they do for the latest fashion - flats and immutable systems. There are other distributions. If someone wants immutable, go with one that's immutable. Debian isn't know for changing things. It was hard enough to get approval for nonfree firmware during the install procedure. There's no way they're moving away from apt to bring in flats, which does, as you point out, defeat stability.
Debian is very useful as a server. Flats are useless without a GUI.
alsv50@reddit
At first sight you are right.
But on the other hand it's a trap. The result might be the opposite and system might be less stable.
More user (also GUI) applications are additional use cases that are additional test cases for the core system.
Less applications - some bugs might not be detected earlier.
DonutsMcKenzie@reddit
That's a fair point and makes sense to me. I just can't stand what appears to be duplication of the same work.
Business_Reindeer910@reddit
"it's a trap" followed by "might" seems to make it simply some assumption rather than having any evidence.
same
omniuni@reddit
I begrudgingly use a few Flatpak packages and they eat way too much space. These are simple GUI packages that could realistically be packaged up very easily as native apps, and they would then take up kilobytes, not gigabytes.
Tight-Employ1489@reddit
What world are you living in? Since when gui apps are "simple" now? Modern gui apps are anything but simple and with so many abstraction it is very important to have good packaging. I can't remember how many times gui apps have broken during testing because libraries updates.
nelmaloc@reddit
KCalc on Debian: 620KB
KCalc on Flatpak: 6,59MB
omniuni@reddit
They're not as complicated as you think, though. And I agree, we need a good solution. But Flatpak has way too many problems to be that good solution.
Helmic@reddit
what packages that are supposed to be kilobytes are instead taking up gigabytes? i'm aware of things like GTK dependencies needing to be available to flatpak, but those are also shared between packages, what specific named packages is this impacting?
omniuni@reddit
Take something like Bottles or ProtonUp. Those GTK dependencies take up a lot of room, when I already have them on my computer. Even worse, sometimes they need different versions of those dependencies.
Both of those should be maybe a few megabytes if they were actually just plain old native packages.
Helmic@reddit
Bottles is 141.5 MB to download, 437.8 MB on disk for me. ProtonUp-Qt is 95.5 MB to download. I'm not sure where you're seeing gigabytes. My desktop's not fixed yet so I can't go check their size on my Arch install, but I remember them being fairly sizable there as well - though, since we're just talking MB in size for a handful of applications on devices that typically have at least 500 GB of storage, I'm personally very fine with spending some extra storage space for some of the benefits of sandboxing and having recent packages on an immutable distro like SteamOS.
omniuni@reddit
First, you have to remember to include all of the dependencies.
Second, that is still absurd when they should be something like 500kb.
Helmic@reddit
I really wish I had my desktop working right now, because 500kb for Bottles sounds kind of absurd. But yeah, Flatpak applications do share their dependencies so that space on disk is split between many applications, the more Flatpaks you use the less each individual application takes up. If you have an existing setup that's more centered on using the distro's package manager, the odds are that you'll already have that disk usage spent already on dependencies.
omniuni@reddit
Bottles is written in Python.
The entire repository (which is far more than just the app itself) is just 2.4 Mb.
ABotelho23@reddit
That's just not how containers work, and I feel like you know that.
omniuni@reddit
And unless Flatpak solves that problem, it's a poor solution.
ABotelho23@reddit
Right, that's why containers are quickly becoming the default way to ship server applications, and distributions are trending towards shipping less GUI applications and make users use Flatpaks.
See:
https://www.theregister.com/2023/06/07/red_hat_drops_libreoffice/
https://en.opensuse.org/Portal:Aeon/SoftwareInstall
It's not a serious problem like you're describing it. People have generally accepted the overhead.
omniuni@reddit
I think it is a problem, and I do not accept the overhead. It's ridiculous.
ABotelho23@reddit
That's fine. But you probably won't have much of a choice in the near future.
omniuni@reddit
I don't think Flatpak is going to last. At some point, people are going to stop being OK with hundreds of gigabytes of dependencies eating up their home directory. If it's already a problem with just a few select applications installed, it's only going to get worse.
I've already started moving as much as possible away from Snap and Flatpak even though it's more annoying, because it was just becoming a waste of space.
The whole concept of Flatpak is about as anti-Linux as you can get from a historical perspective.
One of the biggest things that drew me to Linux in the first place was efficiency. I don't want to give that up, and I'm pretty sure I'm not the only one.
ABotelho23@reddit
Besides that being hyperbole, people are getting bigger and bigger hard drives every day. I think you're very wrong.
Based on what? You're just saying things now. Efficiency isn't just about storage space.
omniuni@reddit
If we keep pushing Flatpak as an answer, the tens of gigabytes right now will easily become hundreds.
Look at how every single traditional package manager has been designed.
ABotelho23@reddit
More hyperbole.
What does that have to do with anything?
omniuni@reddit
If I have about three apps installed now, and each one of 500mb instead of 500kb, what do you think it would look like to have a dozen apps installed like that? Or two dozen?
Don't you think the last 30 years of how Linux distributions have designed things is relevant to understanding historical philosophy?
ABotelho23@reddit
Because you're ignoring that runtimes get reused. The more Flatpaks you use, the more runtimes storage scales.
No, because this isn't the same. Flatpaks and containers specifically solve problems that developers have been dealing with forever. Maintaining a distribution is a lot of work, and non-trivial. There is an insane amount of work that is being duplicated. People who can't be bothered to actually do the work to maintain distribution packages are lucky to have distributions like Debian and Arch. The number of packages they maintain is astronomical, and still people demand more.
Philosophy doesn't mean anything in the end. Solving real problems and reducing workloads is the most important thing.
omniuni@reddit
Those runtimes still are often not exactly the same required versions and you end up with a lot of duplicates.
Flatpak is a very bad way of trying to solve a problem.
ABotelho23@reddit
RemindMe! 5 years
SchighSchagh@reddit
The problem is that each flatpak is updated at a different cadence, so you inevitably end up with half a dozen versions of the GTK dependency due to various flatpak being stuck in time and compiled against different versions of the base dependency
Helmic@reddit
that is true, there's a lot of packages that don't actually need to be specifying a specific version that do so anyways and thus take up more space than is needed.
leaflock7@reddit
Flatpaks still have issues . Not ready for prime time imo. Too many quirks and GUI not working as expected
lawrenceski@reddit
I theoretically agree with you but I’ll start using flatpaks only when ALL gui applications will work as their repositories counterparts
Indolent_Bard@reddit
You know what? That's completely fair. The OBS Flat Pack has an issue with Black Magic input devices like capture cards, because it can't access the files it needs, and there's literally no way to download those files separately. Black magic themselves would have to actually create a plug-in.
ABotelho23@reddit
You know it's possible to use both Flatpaks and regular applications at the same time, right?
lawrenceski@reddit
Of course, but mine is a statement. I wil never use flatpaks until they all will work in the same way. As for now they're not and it's easy to read "oh for that program you can you the flatpak, for that one instead you must use the repository version".
ABotelho23@reddit
But is that "statement" based on any reasonable logic at all?
It just sounds like pointless fluff to me.
lawrenceski@reddit
Yes, in 2024 I don’t see any reason at all to use for example a flatpack for word processing, a repository browser, and so on just because some software doesn’t work well. Also, for my use, in the very best case the flatpak version work as well as its repository counterparts. It never works better.
ABotelho23@reddit
Official Flatpaks maintained by upstream will be more up to date than distribution packages. That's a pretty good reason for a lot of people.
It's also becoming common for software to only ship Snap and Flatpak. Sometimes it's the only way to get some software.
natermer@reddit
It has been my experience that it isn't unusual that Flatpak works better then distro-packaged software.
For example some game emulators and old games like Old School Runscape were just configured better then what was available on Arch.
Also for some software you get a selection of versions to choose from. Like if you are using Gimp via flatpak you can choose between stable and development and nightly builds.
The biggest problems I have had with flatpak stuff is going to be inaccessible directories... Flatpak apps are sandboxed sometimes so that not all files and folders in my home are accessable. That and shelling into a flatpak environment isn't terribly convenient.
Verrix88@reddit
Flatseal to the rescue!
Niralith@reddit
Or just the kde settings if you're using that.
ObscureSegFault@reddit
I've tried and FlatSeal is more user friendly. And as much as KDE is the only obvious and sane choice for a Linux DE, not all people are using it.
not_perfect_yet@reddit
Cool. Good for you. Mine worked worse.
metux-its@reddit
That would even be worse from QA & security perspetive. Debian is neither Windows nor IOS nor Android.
cloggedsink941@reddit
Ah yes, telling people who work for free what to do… I can't see a problem with that /s
DonutsMcKenzie@reddit
You don't understand the word "opinion" or what?
cloggedsink941@reddit
I'm explaining it's a stupid opinion.
asp174@reddit
I used flatpacks in the past. They were convenient. They were available.
And sometimes, maybe, they were maintained.
I don't know how flatpacks are organised today, but I stopped using them a few years ago. My main grief was that even Debian Stable packages were more up to date than some major flatpacks.
ABotelho23@reddit
I imagine Flatpaks would be a thing distributions could collaborate more on. Flatpaks are effectively a "FreeDesktop" Linux distribution.
asp174@reddit
No. Flatpak aims to make a piece of software completely independent from a specific distrubution.
Just like Snap.
ABotelho23@reddit
Yes, independent from the host, but a distribution is simply a collection of software shipped a specific way. That's why we use the term distribution.
That said, it's pretty important you don't ignore that I said
https://snapcraft.io/core18
Not necessarily. Both of them have a base, and the "default" base for Snaps is actually based on Ubuntu. The "default" runtime for Flatpak is FreeDesktop.
asp174@reddit
In the context of r/linux, I'd say a distribution is a Linux distribution. Like Ubuntu, RHEL, Debian, Arch, etc.
You'd have to argue for a different interpretation.
You'd have to put some effort into a different interpretation of "distribution", especially as Flatpak makes the claim to be sandboxed, and run on and current and future Linux distribution.
ABotelho23@reddit
Flatpaks are Linux, are they not?
If I run an Ubuntu container on top of Arch Linux, what is my "distribution" from the context of an application running inside the container?
What about if I make a distribution call "Super Linux", where most of the distribution is image-based, and I host my own Flatpak remote specifically for my distribution?
asp174@reddit
I think we're splitting hairs.
My interpretation of "distribution" is the operating system as a whole (as outlined in my last comment), not the "distribution" of specific apps.
And you're low key agreeing to that with your last comment ("if I make a distribution call "Super Linux", most of the distribution is image-based").
Let's get back to your original comment:
In the context of a Linux Distribution, like Ubuntu, RHEL, Debian, Super Linux, etc, I don't think that a lot of collaboration would happen, as Flatpaks are aimed at being sandboxed and thus portable between distributions. And are maintained by random entities.
The individual distributions put a lot of effort into their specific software distribution model. Superimposing another model without any kind of vetting would not fit most of them.
ABotelho23@reddit
I think it's important to know why it's called a "distribution". It's not a coincidence.
https://en.m.wikipedia.org/wiki/Linux_distribution
So yes, it's an OS, but an OS is a collection of applications.
So if I make a "Super Linux", and my method of distribution is via Flatpak with a custom hosted remote, that's part of my distribution. It becomes how I distribute my applications to my users.
That's why something like Flatpak with the Flathub remote is effectively shipping a distribution that can be run on top other distribution. As in I can run the FreeDesktop distribution within the Debian Linux distribution. Docker containers do the same: run a distribution within another.
I don't think it's that crazy to think that distributions today could collaborate to maintain the "FreeDesktop distribution".
For example, if Debian, RHEL, SUSE, Ubuntu, Arch and others all decided they were no longer interested in shipping LibreOffice as part of their distribution, they could instead spend a fraction of their current effort maintaining the LibreOffice Flatpak hosted on Flathub. Then if more stable distributions like Debian or RHEL wanted to maintain an older version of LibreOffice alongside the blessing edge version, they could collaborate on that too. That way, Debian and RHEL are not duplicating work maintaining two separate packages.
Does that make sense?
MiPok24@reddit
I have the exact opposite experience.
Lots of niche packages in Debian, Ubuntu and Pop!OS are outdated, but if they exist on flatpak, they are well maintained most of the time
waterkip@reddit
No thank you. I'll rather build from source in that case.
Sentreen@reddit
Have you heard about our lord and savior Gentoo?
waterkip@reddit
I'd go back to BSD if im using ports again :)
ActiveCommittee8202@reddit
Got downvoted to hell in another subreddit for the same question. You're lucky that people aren't being gatekeeper here.
jr735@reddit
The reality is that this sub, despite its claim, is filled with fluff. When it comes to serious technical and philosophical discussion as to why this isn't wanted, check each distribution's subreddit. As I said, this would never fly in Debian. And, the whole concept of trying to unify Linux is exactly backwards from what Linux is. The only people that want that are those that don't understand the concept of software freedom, much less the technical aspects of distributions.
Distributions differ only in package management and release cycle. The rest is essentially fluff. If you want to eliminate those two things, then there really are no distributions, now are there?
Having completely distribution agnostic package methods means there is no package management and there is no release cycle. Hence, there are no distributions, just flavors, and even that is shaky.
If you want one way to do things, that's what Windows and MacOS are all about. As was pointed out several times, each time this topic is brought up, all this would do is create more forks, not fewer.
ABotelho23@reddit
Do you understand that a Linux distribution can host their own Flatpak remote? Fedora has done this. Debian could effectively ship a small base, call that Stable, and then use Flatpaks to update specific applications on top of the base distribution. This would simplify the ship out of backports.
Distributions have already been trending to a more common base with systemd, FHS, and unified usr. Being able to move from one distribution to another more easily enables users, it doesn't handicap them.
jr735@reddit
Good for Fedora. I don't see it happening anytime soon for Debian. Enough people use Debian as a server they won't want this nonsense. That why snaps, as abhorrent as they are, caught on in Ubuntu. They are, after all, the Betamax of distribution agnostic distribution methods.
ActiveCommittee8202@reddit
Stop yapping. People like you are the reason that Linux isn't growing and you're like big corps proxy.
Just shut the fuck up
The devs wouldn't spew bs like you do
underdoeg@reddit
i agree and already use flatpaks whenever possible. it would make it simpler to maintain up to date applications. especially on non rolling releases like debian.
karuna_murti@reddit
just make an aur like repository and dump them to that repo. let people adopt it if they want
sophimoo@reddit
not the philosophy of debian, they aim for reliability
BoltLayman@reddit
I am not sure how developers coped with all those 74k packages from their experience perspective. But for me as an end user that has always been just a steaming heap of everything, which I haven't been able to sort out in my daily routine, so mostly this rich choice of software is always CONFUSING AND NOT HELPING!
I always considered RHEL approach to be more practical and with modern software distribution stores flatpak/snap those who need old or abandoned software could always find their piece of .... sh..bits :-))
Too many choices is as bad as too little.
PDXPuma@reddit
They didn't. A package I maintained is still in debian even though the services that it ran on no longer existed and haven't for years. I still play this logic puzzle game called "Einstein" that's ancient and sets your screen to 640x480. LOL
Indolent_Bard@reddit
Why are they maintaining a package you literally can't use?
jr735@reddit
What you mention, though, is really the challenge. What you maintained is still there and essentially dead, you indicate. How do they curate that? I have ideas, but nothing concrete or necessarily feasible. They mentioned looking for a specific RC bug. Okay, that's helpful in finding things that haven't been keeping up to date even when they should.
Some software is "finished" I suppose and doesn't need a lot of updates. Many very basic programs and silly little games would fall into that category.
I suppose there are more automated ways to do these things, too, but some of it is going to be old fashioned thinking. Take a fairly obsolete concept, like newsgroups. How many dedicated usenet readers are there in Debian and how many are unmaintained? You don't need to get rid of all of them, not by any stretch of the imagination. But, if one hasn't received an update for 5 or 6 years, it's safe to say it should be flagged for review. The same would go for dedicated telnet clients.
I'm one of those that doesn't like seeing software disappear or get difficult to find, no matter what it is. However, I don't pay for the Debian servers, so all I've got is an opinion.
PDXPuma@reddit
I think you start by flagging any software over five years old without a release or update and put it on a list. Then, a group of five random debian maintainers vote on whether or not this is still a valid project / going concern. If more than 2 vote yes, it stays.
The real problem is, it takes a lot to become a debian maintainer, and if this is done it means some maintainers may lose projects or lose their last project. And that's probably why it's still this way.
VelvetElvis@reddit
There's a lot of specialized scientific software in debian that most developers wouldn't know where to even start assessing. It might have only a few hundred users but removing it might tank someone's research.
jr735@reddit
That's all relatively reasonable, as far as suggestions go. Now, you say it takes a lot to be a Debian maintainer, which is true. If your project hasn't been touched in five years, are you really much of a maintainer?
That being said, I would add to your idea that if they vote to drop the package, a check is done with the maintainer first and maybe check popcon. If the package is "complete" and the maintainer is just leaving it as is for that purpose, so be it, especially if it garners a lot of use.
PDXPuma@reddit
Oh, I'm not a maintainer any more. I just was surprised to see the package I was on was still there.
jr735@reddit
I'm not completely surprised, given what I've seen in the testing mailing lists. Someone was able to start an effort to yank rox-filer; I'm not sure how it started, but the justification was the lack of use and age, as I recall. Other times, I've seen where a bug has come or a dependency is no longer met, and if there's no fix, it will disappear from sid, then automatically from stable, and hence next stable.
NoCSForYou@reddit
Some software hasn't been updated in 5 years but still works. Assuming it's feature complete that is.
jr735@reddit
Absolutely. That's why there has to be caution.
wRAR_@reddit
Removing packages that still work is indeed a more complicated thing that was proposed in the original email.
jr735@reddit
Absolutely. One has to be cautious. I'm sure there are many old package out there that still work but are hardly used and hardly updated. I mentioned rox-filer. I don't know how many people still use it. I use it in IceWM in Mint and was using it in Debian testing until they yanked it quite a while ago. It certainly may already be gone in Mint 22; I'm not sure.
Membership-Diligent@reddit
is your name still on the package? (ypu could also file a bug to get it removed, if you think that's sensible)
wRAR_@reddit
You aren't supposed to browse through packages shipped by your distro searching for interesting ones.
TheLinuxMailman@reddit
Decision fatigue is a thing.
imbev@reddit
This is exactly the motivation for my distro, HeliumOS. An immutable AlmaLinux/RHEL derivative base, with Flatpak and Distrobox for applications
maep@reddit
If the package is broken or nobody uses it anymore, sure. However there are a couple of packages where deveopment ceased which still work and are incredibly useful. I hope they keep those.
usrlibshare@reddit
!= is guaranteed to continue to work
!= don't need someone to look after them in case something bad happens (breaking library change, vulnerability or bugs discovered, ...)
If people need ancient software, they can always git clone +
configure && make && make installit themselves (and take care of solving any problems themselves as well). After all, Debian does have "a working C compiler".But distros don't need to burden their repos with abandoned code, nor should they.
Business_Reindeer910@reddit
Isn't this more about unmaintained packages than unmaintained software? Unmaintained software can have a maintained packag.
TotallyNotARuBot_ZOV@reddit
It takes work to keep them working in future releases, this work has to be done by someone.
If nobody is responsible and nobody steps up, why should abandoned packages hold back the rest of the distro?
Indolent_Bard@reddit
And that's exactly why Flat Pack is better.
maep@reddit
Many command-line tools written in C or C++ will continue to build without any work required. That's the beauty of a standardized language.
TotallyNotARuBot_ZOV@reddit
And many GUI tools written in C, C++, Python or just about any language will eventually fail to build when their deprecated GUI toolkits are removed from the distro. That's the ugliness of the reality of software development.
DFrostedWangsAccount@reddit
Yeah for another example I know it's old and unsafe but I need an app to use libssl1.1 and it's nice to be able to install it even if it's deprecated and unmaintained, securing it is a separate concern but I manage.
That's something I've always loved about Linux, the question you're googling has an answer from 15 years ago but you can still install the programs and it just works the same as it did back then.
wRAR_@reddit
"still work" doesn't mean "will always work", and "development ceased" often implies ancient code that no longer works with modern tools and libraries at some point.
rizalmart@reddit
If the package was so good and stable that it doesn't need changes except recompiling. will it considered as unmaintained?
6-1j@reddit
if no mainterner then ditch