I have not created signal-desktop because of its unnecessary dependencies but because of the lack of maintanership of 'signal' for weeks until it got a new maintainer. I thought it would be a good idea to keep a security-related package up-to-date. It wasn't.

If those warnings are valuable, why doesn't the signal package have them? Rather than uploading a ragefork.

Again, I've not uploaded this "ragefork" (whatever that means) because of a lack of warnings. In contrast to many other maintainers including the one of 'signal', I always test my packages on fresh installations of all major desktops and discovered the problems myself. Sorry again for this unprofessional approach. Therefore, please delete this package as soon as possible. Eli Schwartz wrote on 06.02.2018 14:23:

On 02/06/2018 07:27 AM, mrxx wrote:

...

'signal-desktop' is not a duplicate of 'signal' but does some things quite differently. Only really needed dependencies are installed, resulting in a much smaller download and disk footprint.

If signal, has unnecessary dependencies, then it should not be forked to fix that. Ask the maintainer to fix it rather than uploading a ragefork.

...

'signal-desktop' also auto-detects a Gnome environment and helps the user to make use of the tray icon functionality of Signal-Desktop. It also checks for libraries which impair the functionality of the tray icon when using KDE and instructs the user to remove them if they are not required by any other package.

Yes, historically you have run pacman in the post_install script. This is the kind of bad judgment that played a part in my desire to see this package removed, as I do not trust your capacity as a maintainer.

If those warnings are valuable, why doesn't the signal package have them? Rather than uploading a ragefork.

...

Last, but not least the package name seems more consistent to me for a program called 'Signal-Desktop' (AUR also provides 'signal-desktop-bin' and 'signal-desktop-beta').

The signal package predates all three. If you felt the signal package should have been renamed, you should not have uploaded a ragefork, but asked for the original package to be renamed.

...

tl;dr

Don't upload rageforks to the AUR as a substandard solution for your disagreement with a package maintainer's choices.

That is what orphan requests are for. Not cluttering the AUR I agree I should have filed an orphan request in the first place.

Ah, so you would say there is no reason to ever use the signal package? No, that's not my intention. I just think maintainers should also test their releases in environments different from their own before uploading them.

One last thing about "I do not trust your capacity as a maintainer" because of using pacman in post_install. The idea was to circumvent a limitation in the PKGBUILD: there is no proper way how to handle potentially conflicting packages. The only possibility is to put them into the 'conflicts' array. Unfortunately, this gives the user only one option if there are still packages which depend on them: remove them altogether or abort installing. But what if the undesired library (libappindicator-gtk2) is only a problem in special cases (e.g. when starting in tray-mode in KDE)? I tried to solve this by checking if the library was still required by any other package, only removing it if it was obsolete (assuming it was installed by an earlier version of signal-desktop or having been left from a make-only dependency), but keeping it if there were dependencies. This allowed signal-desktop to co-exist with them. (A check in the start script of signal-desktop made sure it was always started the right way.) I soon removed this after a user complained, just printing instructions how to remove the potentially conflicting library. I also wrote an extensive post explaining the motivation to do so as I did above. I never had the intention to to "ugly" things behind the user's backs. Eli Schwartz wrote on 06.02.2018 16:56:

On 02/06/2018 08:56 AM, mrxx wrote:

...

I have not created signal-desktop because of its unnecessary dependencies but because of the lack of maintanership of 'signal' for weeks until it got a new maintainer. I thought it would be a good idea to keep a security-related package up-to-date. It wasn't.

That is what orphan requests are for. Not cluttering the AUR with duplicate packages that both claim to be the exact same thing, except one is maintained and one isn't.

...

...

If those warnings are valuable, why doesn't the signal package have them? Rather than uploading a ragefork.

Again, I've not uploaded this "ragefork" (whatever that means) because of a lack of warnings. In contrast to many other maintainers including the one of 'signal', I always test my packages on fresh installations of all major desktops and discovered the problems myself. Sorry again for this unprofessional approach.

Ah, so you would say there is no reason to ever use the signal package? Again, if it needed to be fixed in either one, it should have been fixed in the existing package rather than forking it.

Thanks for the explanation and sharing the insights, learned a lot, won't happen again. Do you have any suggestions on how to handle a situation like the one I explained the correct (Arch) way, apart from putting it into the 'conflicts' array? Eli Schwartz wrote on 06.02.2018 23:08:

On 02/06/2018 02:42 PM, mrxx wrote:

...

I tried to solve this by checking if the library was still required by any other package, only removing it if it was obsolete (assuming it was installed by an earlier version of signal-desktop or having been left from a make-only dependency), but keeping it if there were dependencies. This allowed signal-desktop to co-exist with them. (A check in the start script of signal-desktop made sure it was always started the right way.)

I soon removed this after a user complained, just printing instructions how to remove the potentially conflicting library. I also wrote an extensive post explaining the motivation to do so as I did above. I never had the intention to to "ugly" things behind the user's backs.

Yes, and it is *scary* that you thought it was a good idea to recursively run pacman like that. This sort of nonsense is one of the top contenders for why we as a community disapprove of Manjaro. It can seriously mess up your system if you modify the pacman database mid-transaction, and pacman isn't aware of the changes. That's why there is a lock to begin with...

But yes, once people complained you reverted it.