Nixpkgs: Deprecate KDE 4

[ttuegel]

After #15357 is resolved, we should deprecate KDE 4. KDE 4 is not being updated upstream except for critical security vulnerabilities in kdelibs; other applications are probably vulnerable. NixOS has had a reliable KDE 5 desktop in the last two releases.

[grahamc]

Do you think we can remove KDE4 in this release? It hasn't had a release in almost 2 years now.

[domenkozar]

Same should be for Gnome 2, but that's another issue.

[vcunat]

I thought we deprecated gnome2 long ago. EDIT: I wouldn't even expect it to work anymore.

[grahamc]

• [x] default to kde5 / sddm
• [x] add deprecation notices to kde4 / kdm
• [x] remove module support for kdm
• [x] remove module support for kde4
• [ ] remove kdm
• [ ] remove kde4

Anything I missed in what I assume is an incredibly naive todo?

[ttuegel]

Anything I missed in what I assume is an incredibly naive todo?

Per our unofficial policy, we can't do the last four items on your list without a deprecation period so as not to break users' configurations. It's impossible to have a deprecation period because you can't deprecate packages in Nix.

[globin]

I'm not opposed to removing kde4, but after looking at it a bit it doesn't seem to be that easy as a lot of other packages reach into the kde4 stuff. If someone manages to remove it without breaking the world I'd appreciate that, but it does not look easy.

[maurer]

While deprecating KDE4 as a DM seems warranted, I expect that removing it from repos may take a little while if we want to avoid application breakage. KDE5 Plasma only had their first LTS (5.8) in October 2016 (only ~4 months ago), and Solid's API was only fully broken out into KDE5 Frameworks reached what appears to be feature parity about a year go.

I haven't searched the packages to find out how much is updatable, but I'd expect:

• Some projects will be abandoned, and we'll either have to dump them or keep KDE4, since the API change is nontrivial. I think it'd make sense to just dump these as soon as this is clear.
• Some projects will intend to continue to depend on KDE4, for a variety of reasons. We'll have to decide whether any of these are worth keeping KDE4 for.
• Some projects will still be in the progress of updating to KDE5. I think it'd make sense to give these some amount of wiggle room with regards to depending on KDE4, since there will eventually be a path for NixOS users to keep using this application while still removing KDE5.
• Some may just be directly updatable, and should be updated :)

I think that probably the most important step moving forward would be for someone (not volunteering, sorry, busy) to triage dependent packages into these categories. A second step would be to take any packages in the second category (still maintained packages which intend to continue to depend on KDE4) and see if we can get stats from cache.nixos.org for how often they're still fetched to see how important they are to people, and whether any of them might merit keeping kde4.

Just glancing through the list of things @grahamc had to remove in his WIP attempt:

• Calligra dropped support for four of its applications in its KDE 5 release (for reasons unrelated to KDE 5)
• If even one person is using kmymoney, and we nuke it, that person will probably be very cross with us.
• If kdenlive is dependent on KDE 4, we're shipping an outdated version.

tl;dr:
I think we need to check impact methodically per package before just trying to pull KDE 4-as-a-dependency.

[ttuegel]

@grahamc asked me to take a look at this since I'm the maintainer for KDE 5. I hope to tackle this over the weekend. The main problem we have is that all the KDE 4 stuff is unmaintained so there is no person who is responsible to either keep things updated or remove them. I intend to force the issue by:

• removing the unmaintained KDE 4 packages
• removing third-party packages that do not build against the kdelibs4 version provided by KDE 5
• tagging the maintainers of all these packages in a PR, and
• releasing a list of to-be-removed packages to the mailing list.

Hopefully, some person or persons who is losing their favorite package will step forward to maintain it and its dependencies. If nobody does and a user loses their favorite package, that's tough. This is an open source project; we work _with_ each other, not _for_ anyone. Sometimes you have to step up and maintain a package yourself. If nobody steps up, then the packages I will be removing are unmaintained de facto. Outdated, insecure, and unmaintained packages are a drain on our cognitive and computational resources. Nothing of value will be lost by removing them.

Besides, users can always install lost packages from an old release. Since the packages don't receive security updates anyway, this isn't a problem.

[globin]

@ttuegel thanks for taking this on.

[grahamc]

@ttuegel++ for all of that.
On Thu, Feb 16, 2017 at 11:51 AM Robin Gloster [e-mail]
wrote:

@ttuegel https://github.com/ttuegel thanks for taking this on.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/issues/15866#issuecomment-280388673,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAErrDFW_SX7CknArG1yKUDXYDkYbwKbks5rdH6fgaJpZM4Iqt7V
.

[ttuegel]

@grahamc I've made a first pass of the packages that need attention. Could you check my triage logic?

1. Remove the KDE 4 desktop itself, because the NixOS module for KDE 4 is gone. Keep the core libraries for the 17.03 release.
2. Remove third-party KDE 4 packages that provide plugins--e.g. control panel modules, widgets, themes--because they are not useful anymore.
3. Remove KDE 4 packages with updated releases for KDE 5 already in Nixpkgs.
4. Remove any KDE 4 package that doesn't have ongoing upstream development, i.e. a release or non-automated commit since Jan 1 2016. These will probably never be updated, so I don't see a reason to keep them.
5. Remove KDE 4 packages that do not have a maintainer in Nixpkgs, but alert the mailing list before merging the PR.
6. Keep KDE 4 packages that have KDE 5-based releases that are not in Nixpkgs yet, to maintain continuity while we wait for their maintainers to update them.
7. Keep KDE 4 packages with ongoing upstream development, even if they have not made a KDE 5 release yet. Ask the maintainer to package a development version if possible. These will probably be updated eventually, so it would be good to maintain continuity.

Sound good?

[grahamc]

👍 this looks like a very well thought out and thorough plan, I like it a lot.

[grahamc]

re: the issues you're opening, is there a list you're going off? I'd be happy to help triage.

[ttuegel]

re: the issues you're opening, is there a list you're going off? I'd be happy to help triage.

Nope, I'm just going down the list of things that depend on KDE 4 and applying the criteria in that list! I'm actually done with filing issues and removing packages. Now I'm down to polishing the PR and writing mail for the list.

[grahamc]

You're amazing! 😻

[vcunat]

I think this is fixed now.