1) you request hasn't reported the package was broken >2) also your reply doesn't report what's broken > >that's what I told you, until it's not broken there's no reason to delete it. >not providing the mailx binary is not a reason to delete it
Muflone, my followup message did report what's broken. Two things, the checksum verification, and the lack of mailx executable, despite pkg declaring it provides mailx. Plus, a decades-ababdoned code is not really necessary to keep on AUR when there is a maintained package in repo that provides the same functionality from a newer codebase. > not providing the mailx binary is not a reason to delete it This just shows 1) the incompetence and uncaring attitude of maintainer (who has exhibited this pattern with a large number of their packages), and 2) it is a rationale for deletion, because a package that should carry mailx but doesn't just breaks reverse dependencies that want to use mailx. @aksr is also extremely hostile, it is not much fruitful for me to communicate with him. I would just receive more personal attacks and slurs from him, even in places where I can't respond (see [a]) [a]: https://aur.archlinux.org/cgit/aur.git/log/?h=newsqueak -------- Original Message -------- From: Marcell Meszaros <marcell.mesza...@runbox.eu> Sent: 31 December 2023 13:29:35 GMT+01:00 To: aur-requests@lists.archlinux.org Subject: Re: [PRQ#48514] Deletion Request for mailx-git Not just EOL since 2014, but also still fails source checksum verification after the last update. In addition, it erroneously declares it provides 'mailx', which it does not. It only provides 'neatmailx'. Therefore it would just break downstream dependents that require 'mailx'. Meanwhile, [core] repo's s-nail package does carry the 'mailx' executable, and it declares the same in its provides field.
