[aur-requests] [PRQ#10498] Deletion Request for signal-desktop

[mrxx]

 > 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.
>