Packaging status

[tim77]

Sorry if this duplicate but i didn't found global tracking packaging status or something like that. Just FYI: compton (new version) packaged for Fedora, but under new package name compton-ng.

• Package start page (buggy, not showing at this time)
• Source

How to install:

sudo dnf install compton-ng

[yshui]

Alright, let's turn this into a packaging status ticket.

From what I know, this compton is also officially packaged in:

• ArchLinux
• VoidLinux
• NixOS
• NetBSD

Don't know if I am missing any.

[rbtylee]

I package it for Bodhi Linux.

• 5.x
• 6.x 64 bit only

[jenav]

Well, I'm keeping personal builds of stable and git releases for openSUSE 15.0, 15.1 and Tumbleweed on OBS:

• compton
• picom-git

Edit: update urls after package rename

[CamilleScholtz]

I'm keeping personal builds (based on git master) for CRUX: https://github.com/onodera-punpun/crux-ports/tree/master/compton

[ncmprhnsbl]

handy resource:
https://repology.org/projects/?search=compton
https://repology.org/project/compton/versions
https://repology.org/project/compton/packages

[yshui]

@ncmprhnsbl that's very helpful, thanks

[Vladimir-csp]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908533

[avindra]

For the record, I'm looking into replacing the compton package in openSUSE with the builds that @jenav has been maintaining : https://build.opensuse.org/request/show/729602

(i.e., no -ng suffix).

[yshui]

@tim77 I really appreciate the effort you took to package this compton for Fedora.

I am not fond of the -ng suffix, but that's my own fault to not take the initiative and rename this fork sooner.

There's really no need to say such things about each other.

[kgilmer]

I am not an official packager, however I have your variant of Compton here:

https://github.com/regolith-linux/speed-ricer
https://launchpad.net/~kgilmer/+archive/ubuntu/speed-ricer/

It is also shipped by default in Regolith Linux R1.2: https://regolith-linux.org

[jbeich]

Given #222 and #207 should downstream package v7.4 (pre-rename) as compton update or (wait for v8) as new picom package? From FreeBSD POV if compton package is left as is there's no need to worry how breaking changes may affect consumers (e.g., compton-conf, lumina-session) or old graphics drivers.

[yshui]

@jbeich I don't think there is a need to retroactively rename older packages. Newer packages should ideally be renamed right away (package managers with functionalities like pacman's replace, should use that to update user to the new name), but it's also OK as long as they complete the rename before v10

[jbeich]

... update user to the new name)

The question is whether to inherit users from chjj's compton or not. Before this fork was renamed some distributions have already switched existing package to yshui's compton (the new upstream). However, those that didn't can maintain both picom and compton. Once breaking changes land and things stabilize again (a la mplayer->mplayer2->mpv) the old package can be removed if no one wants to maintains it.

Currently, the latest release here uses the old name, complicating import as separate package from the start.

[yshui]

those that didn't can maintain both picom and compton.

Yes, that's one of the points of this rename. However, those distros that have already made this switch probably won't be able to go back to chjj's compton. They probably have to wait a period of time after renaming to picom, before they can reintroduce the compton package.