Remove Debian dependency libappindicator3-1

[hiqua]

libappindicator has been deprecated by Debian (0) and will not be shipped from
Debian Bullseye on.

This library is supposed to enable the system tray icon to work, but it actually works fine without it on the two systems I've been able to test (xfce / i3). At the same time, this dependency prevents users from installing element-desktop on Debian Bullseye.

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

[t3chguy]

Without this dependency older systems had incorrect click behaviour. Where left clicking would open a context menu (same as right clicking) but left clicking the tray icon should show/hide the window instead.

[hiqua]

Ok, then I can just move it to a recommends section, would that be fine for you? And the package should be installable on Debian Bullseye with this, if I'm not missing anything.

[hiqua]

@t3chguy let me know if this works better for you.

[SimonBrandner]

This might fix #16174

[hiqua]

This might fix #16174

Yes that's exactly the point, sorry I should have looked for a corresponding issue.

To be clear, I cannot reproduce the issue @t3chguy is mentioning. Since it's not such a big issue, IMHO it would be fair to apply the fix I'm suggesting and see if the old issue is indeed still here on systems without libappindicator (provided you, like me, cannot reproduce it right now).

If you're interested in technical details, I wrote a bit there: signalapp/Signal-Desktop#5031 (comment)

But in any case I think the point remains that having the app installable with a tiny bug (if at all, again I don't have it) with the currently suggested procedure is better than having it fail / suggesting to download a .deb manually and use dpkg, leading to an orphan dependency on user systems.

[daenney]

I don't think recommends is entirely appropriate. The purpose of recommends is to indicate a dependency that in all but the most unusual installations should be present. Though appindicator support is useful, the application functions perfectly fine without it and only serves to provide a relatively minor enhancement in desktop environments. None of the functionality of Element is absent when appindicator support isn't present on the system. That fits much better with the definition of suggests:

Suggests
This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable.

https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

[hiqua]

@daenney if it were just me we'd remove it altogether, for the reasons you mentioned, and the fact that I cannot reproduce the bug mentioned (so IME the dependency is useless). But putting it as a recommends means the change is minimal (and I hope easier to accept for the maintainers). suggests is one step further.

In practice, it makes little difference anyway, and it's bound to be removed completely eventually.

[daenney]

This won't work as intended, with it being in recommends. As of Debian Lucid, recommends are installed by default by apt. So if libappindicator3-1 isn't packaged in Bullseye at all, then putting it in recommends will still break on any installation, unless the owner has explicitly set apt::install-recommends "false"; which is typically only done for headless machines.

Looking at the package it seems odd that Debian has it in Buster and Sid, but that it's missing from Bullseye:

Package libappindicator3-1
    jessie (oldoldstable) (libs): allow applications to export a menu into the panel -- GTK3 version
    0.4.92-3.1: amd64 armel armhf i386
    stretch (oldstable) (libs): allow applications to export a menu into the panel -- GTK3 version
    0.4.92-4: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
    buster (stable) (libs): allow applications to export a menu into the panel -- GTK3 version
    0.4.92-7: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
    sid (unstable) (oldlibs): allow applications to export a menu into the panel -- GTK3 version
    0.4.92-8: alpha amd64 arm64 armel armhf hppa i386 m68k mips64el mipsel ppc64 ppc64el riscv64 s390x sh4 sparc64 x32

This would probably warrant reaching out to the Debian project instead. The library being present in Buster and Sid but missing in Bullseye is rather strange. If it is available in Sid, it should naturally roll down to Bullseye/testing.

[daenney]

With libappindicator being in oldlibs, it might just be that they'd like to switch to https://packages.debian.org/bullseye/libayatana-appindicator3-1

[hiqua]

if libappindicator3-1 isn't packaged in Bullseye at all, then putting it in recommends will still break on any installation, unless the owner has explicitly set apt::install-recommends "false";

You're 100% sure about this? I think it will at least depend on the frontend, for instance aptitude will likely prompts the user about whether they want to proceed without the dependency.

I couldn't really find doc about what would /should happen exactly in case of missing recommends dep, with apt / apt-get. I had thought that they would just be skipped, but I might be mistaken.

But let's assume you're right anyway, would it then be fine to just have this dependency as a suggests?

My only goal here is to have element installable on Debian Bullseye without any friction. Anything that makes it possible is fine by me.

[daenney]

if libappindicator3-1 isn't packaged in Bullseye at all, then putting it in recommends will still break on any installation, unless the owner has explicitly set apt::install-recommends "false";

You're 100% sure about this? I think it will at least depend on the frontend, for instance aptitude will likely prompts the user about whether they want to proceed without the dependency.

Positive, says so in the apt source code: https://github.com/Debian/apt/blob/master/apt-pkg/init.cc#L132. It's possible that aptitude ignores that or prompts anyway, but it's unlikely people would uncheck recommends. First time around it would most likely still result in an installation error.

I couldn't really find doc about what would /should happen exactly in case of missing recommends dep, with apt / apt-get. I had thought that they would just be skipped, but I might be mistaken.

In both cases they'll be skipped, unless explicitly asked to be included. Since apt defaults to including recommends, it will try to find that package, fail to do so and abort the installation as it won't be able to resolve a package you're asking to be installed.

But let's assume you're right anyway, would it then be fine to just have this dependency as a suggests?

My only goal here is to have element installable on Debian Bullseye without any friction. Anything that makes it possible is fine by me.

Moving to suggests should be fine, since apt never defaults to installing suggests by default. Semantically I also think that's more correct.

[daenney]

Based on https://www.debian.org/doc/manuals/aptitude/ch02s05s05.en.html it also seems Aptitude will mark recommended packages for installation based on Install-Recommends, if Aptitude::Auto-Install is true, which is the default.

[hiqua]

To clarify, I created a repo with an empty package to play with Depends vs Recommends: https://github.com/hiqua/DebianMissingRecommendsDependency

Using this, I can say that it:

1. does not install with an unknown package (called some-unknown-package) in Depends (as we both expect)
2. does install with an unknown package in Recommends. It even mentions it during install, this is the output:

sudo apt install ./pack_99_all.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'pack' instead of './pack_99_all.deb'
Recommended packages:
  some-unknown-package
The following NEW packages will be installed:
  pack
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/2,176 B of archives.
After this operation, 9,216 B of additional disk space will be used.
Get:1 /home/hiq/deb_equivs/some_package_missing_recomm/DebianMissingRecommendsDependency/pack_99_all.deb pack all 99:99 [2,176 B]
Selecting previously unselected package pack.
(Reading database ... 682075 files and directories currently installed.)
Preparing to unpack .../pack_99_all.deb ...
Unpacking pack (99:99) ...
Setting up pack (99:99) ...

This is using apt-get, but I just had the same results using apt. I assume aptitude is the same.

Am I still missing something?

This is on Debian Bullseye. I assume that the result will be similar on Ubuntu, but you're welcome to reproduce this if you have the time.

This means that it would be fine to leave in Recommends. Again, I don't particularly care either way, so if somebody who's able to merge can just tell me what they want, I'll do it without further question.

[daenney]

Strange, I don't recall apt be OK with references to non-existing packages in recommends. But I can indeed reproduce your behaviour on a fresh testing install.