A proposed policy to remove unfixable packages from Ubuntu [LWN.net]

From:		Martin Pitt <martin.pitt-GeWIH/nMZzLQT0dZR+AlfA-AT-public.gmane.org>
To:		technical-board-nLRlyDuq1AZFpShjVBNYrg-AT-public.gmane.org
Subject:		Proposed SRU policy amendment for package removals
Date:		Tue, 11 Nov 2014 14:54:18 +0100
Message-ID:		<20141111135418.GD2909@piware.de>

Hello TB,

as discussed in the last meeting, I wanted to put up a proposal for
amending https://wiki.ubuntu.com/StableReleaseUpdates for package
removals like the recent owncloud. Please check that this graps what
we discussed; I'd also appreciate language cleanups.

Thanks!

Martin

== Removals ==

In rare cases, an universe package becomes actively detrimental in stable releases: If it is
unmaintained in Ubuntu and has unfixed security issues or got broken because of changing network
protocols/APIs, it is better to stop offering it in Ubuntu altogether rather than continuing to
encourage users to install it.

It is not technically possible to remove a package from a stable release, but this can be
approximated by SRUing an essentially empty package with an appropriate explanation in `NEWS` and a
corresponding critical debconf note.

Such a package removal should have an SRU tracking bug with an appropriate explanation, and needs
to get confirmed by the [[https://launchpad.net/~techboard|Technical Board]].

Examples: [[https://lists.ubuntu.com/archives/ubuntu-devel/2007-Septe...,
[[https://launchpad.net/bugs/1384355|ownclod]]

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

to post comments

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 14:39 UTC (Wed) by garrison (subscriber, #39220) [Link] (3 responses)

I suppose as a corollary we will begin seeing production systems that use unattended-upgrades break overnight as upgrades are pushed that replace an essential package with an empty one. I can't imagine this will go over well when it happens.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 14:52 UTC (Wed) by xnox (subscriber, #63320) [Link] (1 responses)

a critical debconf prompt will prevent non-unattended upgrade to empty package. So that's a non-issue. And this is for universe packages only, none of which are essential on a wide scale of things.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 16:52 UTC (Thu) by jb11211 (guest, #87222) [Link]

I can't get my hosts out of bed in the morning without Universe. :)

Changes in Universe will impact real systems running real workloads.

That said, if you are allowing automatic upgrades in your production environment without first testing them your asking for pain. IMHO

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 14:55 UTC (Wed) by dgm (subscriber, #49227) [Link]

I'm sure this will be weighed in when the _proposal_ is discussed.

Why not just remove it?

Posted Nov 12, 2014 15:39 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses)

It is not technically possible to remove a package from a stable release,

Is this really something that's impossible to fix? Surely the first thing to sort out would be to fix the release machinery to allow packages to be removed during the course of a stable release's lifetime.

Why not just remove it?

Posted Nov 16, 2014 19:49 UTC (Sun) by JanC_ (subscriber, #34940) [Link] (1 responses)

Simply removing the package would still keep the old package version installed (including all its bugs), so at best it would prevent people from installing it after that date...

Why not just remove it?

Posted Nov 19, 2014 9:22 UTC (Wed) by epa (subscriber, #39769) [Link]

Surely you can force a package to be uninstalled by adding an Obsoletes: to the base system package (or the dpkg equivalent of this, I am speaking rpm).

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 16:46 UTC (Wed) by torquay (guest, #92428) [Link] (38 responses)

This is not really a problem specific to Ubuntu. Yes, Ubuntu certainly shares the blame for packaging random stuff and then not supporting it. However, the problem is a direct consequence of using the broken distro model of software distribution (or more precisely, the mudball approach).

Rather than packaging everything under the sun, the real solution is of course to provide only the bare necessities for an operating system, which have stable API and ABI from one release to the next. All other software would be an add-on, downloadable directly from the vendor, not through an intermediary channel known as a distro. These distros (ie. the Ubuntu distro, Fedora distro, Debian distro, etc) are in fact bottlenecks and failure points. They also encourage silos and fragmentation.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 18:39 UTC (Wed) by woooee (guest, #54179) [Link] (15 responses)

I'm not installing anything from some unknown "vendor", ala MS Windows. If it's not in the distro's repositories, I won't install it.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 19:30 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (6 responses)

You are fortunate to have no software desires/requirements beyond what people can be bothered to package and assiduously maintain for your chosen distribution.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 20:32 UTC (Wed) by bucky (guest, #53055) [Link] (5 responses)

Few end users take the responsibility to personally review every single product he may want to use. A trustworthy distribution offers some peace of mind in that regard.

A distribution's choice to de-certify a product is a legitimate part of REMAINING trustworthy. It shouldn't be taken as anything more than "we don't have the resources to continue reviewing this product."

That's where the end-user steps in and says, "Well, I DO have the resources to at least review this product for my own situation, and I think it's fine."

Different end-users are going to have different requirements, making "better" and "worse" distribution+vendor+user combinations very personal.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 4:00 UTC (Thu) by torquay (guest, #92428) [Link] (4 responses)

"we don't have the resources to continue reviewing this product."

This is unfortunately the case for the vast majority of packages in almost any Linux mudball (distro). The number of people working on each mudball is far less than the number of packages. The majority of these workers are in fact volunteers, who may simply stop doing package updates, fixes, etc because they don't have the time (newborn baby), lost interest, graduated to a "real job", or simply got hit by bus.

Packagers, and by direct extension Linux distros, are hence a bottleneck between the software creator/vendor and software user/consumer. Rather than throwing more people at the problem, the solution is to get out of the way, where the software vendor directly provides the software and updates to the end user.

This can be possibly done through an App Store-like model, but the battle here would be to have a reliable and common host environment across all the Linux mudballs (Fedora, Ubuntu, etc). This is what SteamOS is trying to achieve, albeit the apps on SteamOS are limited to games.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 21:41 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> albeit the apps on SteamOS are limited to games.

This isn't true anymore:

http://store.steampowered.com/tag/en/Audio%20Production/#...

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 22:36 UTC (Thu) by ledow (guest, #11753) [Link]

Indeed... I have at least two development tools that are on Steam too.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 3:58 UTC (Fri) by lsl (subscriber, #86508) [Link] (1 responses)

> Packagers, and by direct extension Linux distros, are hence a bottleneck between the software creator/vendor and software user/consumer. Rather than throwing more people at the problem, the solution is to get out of the way, where the software vendor directly provides the software and updates to the end user.

I do not perceive distro packagers that way, at all. They provide a very valuable service to developers and users alike. As a programmer, distributions do the work that I'm not equipped to handle appropriately, namely running the infrastructure to do builds on every kind of machine from DEC Alpha to IBM System z. I really don't want to get into the business of running my own build infrastructure.

As a user, I benefit by getting ready-made packages instead of having to build my own from tarball releases or git repositories, Sure, if I need a specific version of some program, I might choose to not take advantage of the distro-provided package, but for >90 % of the software I run I just don't care about the exact version as long as it's reasonably recent.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 11:23 UTC (Fri) by krake (guest, #55996) [Link]

I agree.

What people seem to overlook a lot is that none of the Linux distributors lock their systems down in a way that makes any other software distribution impossible.

Some mobile device vendors do, but none of the general purpose OS vendors.

Installing software from the OS vendor's source is then a convenience, which might or might not be available for all programs a specific user needs.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 14:29 UTC (Thu) by NAR (subscriber, #1313) [Link] (7 responses)

So you don't trust the creator of the software you actually want to use, who knows how it works, developed it for a few years, but trust the distro maintainer, who might not touched the source at all, just massaged the Makefile and created deb and/or rpm file... Do you remember how the Debian maintainers broke openssl for a couple of years?

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 17:16 UTC (Thu) by raven667 (subscriber, #5198) [Link] (6 responses)

You really need some work with both skillsets, someone who knows how the software works, and someone who knows how the _system_ is put together outside of any individual piece of software. Maybe the system integration can be managed by documentation and tools which funnel developers into a supportable workflow, using shared libraries, putting files in standard locations, using system-level tools for registering components, managing config changes, etc. Each application doing their own thing because the developer doesn't have the visibility of how the whole system hangs together is its own problem that older systems had which the distro model has spent a lot of effort trying to fix.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 10:51 UTC (Fri) by NAR (subscriber, #1313) [Link] (5 responses)

I believe for most of the software it shouldn't matter how the "system is put together". After all in Eclipse I can generate via a single click a jar file that runs on WinXP, Win7, Linux, etc. Of course, this is a user application, not a plumbing-level software, but at least Linuxes should not differ in ways to e.g. add an application to the main desktop menu - because the user doesn't really care about this. Software should not come from distributions, but from actual authors who should have a stable, compatible target environment. I mean distributions don't really add value to the users. They "adapt" software to the distribution - but the only reason why this "adaptation" is necessary is that they artificially make the environment different enough so that they have to adapt software. Kind of catch 22.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 16:32 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

With your JAR file you are building it within a system, Java defines and standardizes pretty much as much as a distro does, and substantially insulates you from the OS kernel and other platform differences. So not an apples-to-apples comparison

What you would really like is if the distros used much of the same plumbing, libraries, filesystem standards, ABI, so that you can make a packaged binary that works well across many vendors distros as possible. You won't get all of them because anyone is free to make their own distro that is laid out however they want, and people do want different things, there are reasons why the packaging standards are different between Debian and RHEL and SuSE, you may think those reasons are "artificial" but they do still exist.

I think there is a trend toward convergence, the distros seem to be working together more often than not, the differences are more about their legacy than about their future.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 18:25 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

As long as userspace programmers don't really believe in maintaining compatibility with new releases, the distros are always going to have some places where they differ, just because different distros accept different levels of risk in deciding what versions of libraries and software exist.

The current discussion here on gpg 2.1 dropping compatibility with old keys is a perfect example, depending on what version of gpg the distro chooses to install, they will get different results, and if they install both 1.4 and 2.1, the distros have to pick a path and name for the 1.4 version. That is going to be different for different distros (as there is no way to standardize it).

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 22:09 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> That is going to be different for different distros (as there is no way to standardize it).

Well if the distro and package maintainers talk with one another then they might be able to come to a consensus on a consistent way of handling these packaging issues, convergence in areas of the distro where differences aren't serving a useful purpose is a good thing I think.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 22:29 UTC (Fri) by dlang (guest, #313) [Link]

The problem here is that the gpg people don't really accept that it's an issue. Yes they allow the different versions to be installed at the same time, but if they really believed that people would want to have access to their old data, they wouldn't remove the ability to use the old keys.

That would be FAR easier than trying to coordinate with all the different distros out there.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 15, 2014 15:57 UTC (Sat) by lsl (subscriber, #86508) [Link]

> After all in Eclipse I can generate via a single click a jar file that runs on WinXP, Win7, Linux, etc.

So you just distribute whatever happens to be on your disk whenever you click that button? How can anyone reproduce that build? Do you state somewhere what exactly is required to build your software? Do you even know?

These questions are easy to answer if the whole process from creating the build sandbox/chroot to the final package is automated.

That's doable with some scripting, sure, but what if you don't write Java, but, say, C or any other language commonly compiled to a machine-specific representation? For projects below a certain size it's just not feasible to run the infrastructure to build for N different operating systems running on M different architectures.

Also, as a user, distributions offer me a reliable and unified way to update the software on my system. Writing and operating such an update mechanism in a secure way is hard, so most projects, understandably, punt on this. This leaves the user with the burden of tracking upstream release and installing them.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 20:17 UTC (Wed) by ttonino (guest, #4073) [Link] (1 responses)

Perhaps an 'trusted addon package source' can play a role.

The distro being a stable base API and base functionality which is not under the API guarantee (think Firefox).

One or more sources (maybe from the distro itself, or another trusted party) delivering faster changing, larger applications that are not supposed to have anything dependent on them. These sources may offer a way to install older versions as well to mitigate compatibility issues.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 4:15 UTC (Thu) by torquay (guest, #92428) [Link]

The distro being a stable base API and base functionality which is not under the API guarantee (think Firefox).

Within Fedora land there was a lot of talk about having software rings (see Matthew Miller's slides), where each outer ring is a consumer of stable APIs/ABIs provided by an inner ring. Unfortunately, more than a year later, nothing concrete has come out of this.

The is the Fedora.Next effort that takes "inspiration" from the rings idea (ie. Fedora is now split into separate components: a base OS and desktop/server/cloud overlays that build on the base OS). However, this is still very far from actually implementing the rings idea that makes a difference at the interface between the software vendor and software consumer. Packagers and distros are still getting in the way.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 12, 2014 23:47 UTC (Wed) by misc (subscriber, #73730) [Link] (13 responses)

But then, you have to say "no" to packagers, which is always something which is not well received ( think systemd, gnome and the harsh criticism they face because they choose to focus rather than being everything for everybody ). In fact, that's a bit demotivating to people who think this is already hard to make proper packages, so saying "no" is not gonna motivate a lot of volunteers to spend their time, unless you spend a lot of time to explain the vision.

And there is distributions that do that, like Centos for example ( due to RHEL doing that ), and still, people ask for packages repository like EPEL and more stuff, or say "I would want to use more stuff". Now, you will say that you cannot download rpm from upstream, but that's the point, despites having 1 distribution doing that, no one care upstream. And even worst, some upstream do not care of the stable ABI, like chrome is not running on rhel 6,

I think one of the root cause is more that we have more people who code than people who do the rest so this mean there is more software to package than what we can package and maintain properly. We could reduce the overhead of making a package, but there is a limit to what we can do. And as long as we celebrate more the coders than the rest, we will have more coders than the rest.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 4:26 UTC (Thu) by torquay (guest, #92428) [Link] (11 responses)

And there is distributions that do that, like Centos for example ( due to RHEL doing that )

No, I'm sorry, but CentOS and RHEL do not do that. RHEL and CentOS do not provide guarantees of stable API and ABI between two major releases. Stuff written on RHEL 6 is not guaranteed to run on RHEL 7. This is obviously in contrast to Windoze, where a random piece of software written for XP is very likely to work correctly on Windoze 10.

The linux kernel has very strong ABI guarantees (modulo bugs, but even then the kernel folks try to provide workarounds). It's very sad to see that these ABI guarantees do not extend to the software layers running on top of the kernel. It's more of a cultural problem than a technical one.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 4:38 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (10 responses)

>No, I'm sorry, but CentOS and RHEL do not do that. RHEL and CentOS do not provide guarantees of stable API and ABI between two major releases.

As has already been pointed, this isn't correct

https://access.redhat.com/articles/rhel-abi-compatibility

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 5:41 UTC (Thu) by mchapman (subscriber, #66589) [Link] (2 responses)

> As has already been pointed, this isn't correct

"Is not correct any more", perhaps? That document talks about compatibility across three major releases starting from RHEL 7, and I don't remember seeing a similar document for earlier releases.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 6:19 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Umm.

"Note: this article discusses Application Compatibility for Red Hat Enterprise Linux 7. For Red Hat Enterprise Linux 6 please see the attached PDF file (rhel6_app_compatibility_wp.pdf)."

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 6:26 UTC (Thu) by mchapman (subscriber, #66589) [Link]

Thankyou. I hadn't seen that before.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 7:06 UTC (Thu) by torquay (guest, #92428) [Link] (6 responses)

From the above site:

Compatibility level 1: APIs and ABIs are stable across three major releases (starting with RHEL 7)

alsa-lib, krb5-libs, elfutils-libelf, libgcc, glibc, libgfortran, glibc-utils, libgomp, gtk2, libstdc++, hesiod, libtbb, libtbbmalloc, libtbbmalloc-proxy, libtopology, libusb, libvirt-client, libxml2, libxslt, mesa-libGL, mesa-libGLU, motif, pam, SDL

ie. out of all the stuff that makes up RHEL, only 24 packages are considered as being stable across major versions. While certainly better than nothing, is this set of packages large enough to be considered as the base of an operating system? There's a curious absence of pulseaudio, gstreamer, qt, and any Gnome related packages (not taking into account gtk2).

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 7:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

PulseAudio is covered by alsa-lib. Native PA interface might graduate to super-ABI-stable stage, but not right now.

Expecting QT to be maintained across multiple ABI releases (5-10 years) is probably way too optimistic.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 16, 2014 5:36 UTC (Sun) by torquay (guest, #92428) [Link] (2 responses)

Expecting QT to be maintained across multiple ABI releases (5-10 years) is probably way too optimistic.

Then it's not clear why is GTK2 included in the list of super-stable ABI packages, while Qt4 isn't. Both aren't "changing", in the sense that all the breakage is occurring in GTK3, and Qt5 is now the main QT series.

Isn't Qt4 part of RHEL 7, which will be maintained for 10 years? RHEL 8 (and probably RHEL 9) will be released within the lifetime of RHEL 7, so why isn't it possible to include the Qt4 package in RHEL 8 and 9 ?

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 16, 2014 5:49 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's likely because GTK2 is mostly dead so it's very stable that way. Kinda like Motif and CDE.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 16, 2014 8:59 UTC (Sun) by torquay (guest, #92428) [Link]

This is a sad indictment of the open source community (excluding the kernel folks) -- for something to be considered stable, it has to be dead.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 16, 2014 14:38 UTC (Sun) by foom (subscriber, #14868) [Link] (1 responses)

Hah...Hesiod?? Now that's a stable-as-in-dead technology if I've ever seen one. :)

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 18, 2014 17:53 UTC (Tue) by nix (subscriber, #2304) [Link]

hesiod, but none of the X11 libraries, which really are insanely API-and-ABI-stable. I guess the assumption is that server apps won't care, but in that case why is Gtk in there? After all, even now a lot of Gtk apps link against libX11 too...

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 4:47 UTC (Thu) by drag (guest, #31333) [Link]

> I think one of the root cause is more that we have more people who code than people who do the rest so this mean there is more software to package than what we can package and maintain properly.

Well one of the problems is that with each Distro being unique enough to cause compatibility issues you'd see that for every one common set of packages you have dozens of people packaging it. Instead of sharing the work they each do their own thing..

Also another aspect is that different software projects have different time tables and different desires then the distros that package them.

The OwnCloud vs Ubuntu LTS is a perfect example of this. It's really a impedance mismatch.

There is no right or wrong way to handle APIs or ABIs versioning, release timetables, or support time-lines... All that exists is some approaches are more desirable then others _depending heavly_ on the specific goals of the developers and the expectations of users.

For example: It's perfectly fine if some software library has major API changes between each 2 month release... if you want to have a library that maintains a stable API for 3 years then you better use something else or fork it! That project does not have your use case in mind!

How distributions handle their release and support policies are incredibly arbitrary. 'Oh all the software that gets released and packaged in the first quarter of 2013 will exist in perfect maintainership until 2020',.. 'oh we release every 6 months, except when we don't. Then we shoot for 8 months'... 'well we only support the latest package and we release new packages every week. If you have a bug upgrade first or otherwise don't bother us with it'

How this this realistic? For some software it is, for many others it is not! Is it wrong for distributions to choose these sorts of releases? No.. they are trying to meet the needs of their users. It's important for them to release how and when they do (or use rolling releases or whatever).

Like I said before: Impedance mismatch. There isn't a solution except to break software packages away from OS releases and even then that comes with it's own set of problems.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 9:01 UTC (Thu) by jengelh (subscriber, #33263) [Link] (2 responses)

>All other software would be an add-on, downloadable directly from the vendor, not through an intermediary channel known as a distro.

Truth is, most vendors do a bad packaging job, or at least a mediocre one that works but does not integrate well with the distro. Like, with nvidiagfx. It is no wonder if users choose to go with a distro rewrap of some particuar software.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 14, 2014 13:33 UTC (Fri) by krake (guest, #55996) [Link] (1 responses)

I think the idea here is that the vendor packages would not end up being processed by the distribution's package handling system.

That would be way to risky, not just because of bad packaging but because the systtem's package manager had, due to its need, access to high levels of priviledges.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 16, 2014 20:08 UTC (Sun) by JanC_ (subscriber, #34940) [Link]

Not using the distro's packaging system doesn't fix bad packaging or bad installers from the vendor... (quite contrary).

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 10:47 UTC (Thu) by etienne (guest, #25256) [Link] (1 responses)

> All other software would be an add-on, downloadable directly from the vendor, not through an intermediary channel known as a distro.

And then the application decides to self-upgrade because a new version is available, so that application needs root access.
That may be fine, that is the way of mobile phones, and that at least leads to the application developer (who works hard) to be paid for his work - for instance by selling (to third parties) adds-on forcibly installed.
The problem is, as always, application developers who do not work too hard to produce flying pigs animations in 3D, and install their stuff by overwriting vital components of the system - rendering the base system un-supportable.
Another problem is libraries updates which breaks someone else application.
Also this method only works for some time, when you have accumulated too much "stuff", you have to throw away your device - like you do with mobile phones. The "application uninstaller" has long been subverted not to remove adds-on.
In short, distro are not so bad considering alternatives - their problem is a lot of hard working developers do not receive a penny to keep their users happy...

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 14:46 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Do you have a smart phone?

Because your description doesn't sound like anybody who has even tried to figure out how they work by observation, let alone the insider view.

The _vast_ majority of smart phone apps aren't permitted to be at all invasive. They don't have permission to self-upgrade. The most they can do if they're even permitted Internet access is to prompt the user to authorise an upgrade, which will then be performed out-of-band by the phone OS.

A proposed policy to remove unfixable packages from Ubuntu

Posted Nov 13, 2014 14:08 UTC (Thu) by danieldk (guest, #27876) [Link]

> All other software would be an add-on, downloadable directly from the vendor,

I think the BSD model is a good compromise: have a small, API/ABI-stable and reliable base system. The software outside the base system is offered in a repository that does not see releases like the base system, but is more of a rolling release.

Of course, the downside is that non-base system packages upgrade more often, but it reduces the burden of the maintainers compared to the distribution model and it reduces the maintenance burden of users compared to the 'obtain your software from the vendor and ensure you apply security updates yourself'-model.