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.