[PRQ#48514] Deletion Request for mailx-git
MarsSeed [1] filed a deletion request for mailx-git [2]: Unused, unmaintained VCS package from 2015. Does not declare provides + conflicts, and does not install the custom license. Upstream not developed since 2014. [a] [a]: https://repo.or.cz/mailx.git/shortlog [1] https://aur.archlinux.org/account/MarsSeed/ [2] https://aur.archlinux.org/pkgbase/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.
Request #48514 has been Rejected by muflone [1]: until this is broken, there's no reason to delete it. not providing mailx is not a valid reason to delete it [1] https://aur.archlinux.org/account/muflone/
On 27 February 2024 00:14:49 GMT+01:00, notify@aur.archlinux.org wrote:
Request #48514 has been Rejected by muflone [1]:
until this is broken, there's no reason to delete it. not providing mailx is not a valid reason to delete it
@Muflone, didn't you read my followup message? Not only it is broken, but if fixed and installed, it would break downstream dependents.
Request #48514 has been Rejected by muflone [1]:
until this is broken, there's no reason to delete it. not providing mailx is not a valid reason to delete it
@Muflone, didn't you read my followup message?
No, what made you think I read the messages? I only press random buttons until something happens
Not only it is broken, but if fixed and installed, it would break downstream dependents.
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 best regards -- Fabio Castelli aka Muflone
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.meszaros@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.
@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])
This is a severe thing I didn't wanted to read at this time (1.50 AM). I've just suspended @aksr for 1 week @aksr make sure this type of offenses never happen again in the Arch Linux communities. Further messages like [1] would cause longer or a definitive suspension from AUR or others Arch Linux communities. In the meanwhile make sure to read the Arch Linux Code of Conduct [2] Best regards [1] https://aur.archlinux.org/cgit/aur.git/commit/?h=newsqueak&id=6cc244be051f09... [2] https://terms.archlinux.org/docs/code-of-conduct/ -- Fabio Castelli aka Muflone
Back to the topic of this package, I am observing a bit of a mixed / confused standard. Many times you said if a package is not broken, it can stay. Then when my additional message stated that this is indeed broken, you said I didn't say how it is broken. But I did say what are the reasons behind it. And I'd like to point out that we are talking about an AUR package that has 0 votes or comments, and which had violated VCS package guidelines f8r68 years by not declaring its provides & conflicts, and only I gave feedback to maintainer about it a few months ago, for which in response they made the package worse than it was, and also pushed a defunct update. I do think that we also have to keep in mind the part of the AUR submission guidelines that say that packages here should be useful to more than a few people, and evaluate if this particular package is usable or not and in demand or not by fellow AUR users. Otherwise if you always favor the maintainers, even if they keep their unused and unusable pet packages on AUR for themselves only (or not even for themselves, in case of defunct PKGBUILDs), then the AUR will just accumulate more spammy mess as opposed to functioning builds that are well-attended.
Hi Marcell Sorry for the delay but I had healthy issues.
Back to the topic of this package, I am observing a bit of a mixed / confused standard.
Many times you said if a package is not broken, it can stay. Then when my additional message stated that this is indeed broken, you said I didn't say how it is broken. But I did say what are the reasons behind it.
The package builds fine and it seems to me to work fine. Does this match the reality? Some days have passed and I don't remember the details
And I'd like to point out that we are talking about an AUR package that has 0 votes or comments, and which had violated VCS package guidelines f8r68 years by not declaring its provides & conflicts, and only I gave feedback to maintainer about it a few months ago, for which in response they made the package worse than it was, and also pushed a defunct update.
The maintainer hasn't abandoned the package, or better he has updated it recently. Are you arguing he's not skilled/good enough to maintain the package at the best standards possible? It may be Still, I cannot find a valid reason to delete the package
I do think that we also have to keep in mind the part of the AUR submission guidelines that say that packages here should be useful to more than a few people, and evaluate if this particular package is usable or not and in demand or not by fellow AUR users.
Otherwise if you always favor the maintainers, even if they keep their unused and unusable pet packages on AUR for themselves only (or not even for themselves, in case of defunct PKGBUILDs), then the AUR will just accumulate more spammy mess as opposed to functioning builds that are well-attended.
This is an unfair discussion, I don't want the AUR to have only high standards packages, simply the opposite, I don't want to remove any packages with minor issues. AUR must continue to exist, with all its packages, until they are broken, invalid, superseded or replaced by something else. So please, stop chasing minor bugs in order to ask the package deletion as this is not a valid reason to delete. Also, this is an important point, your so frequent requests require a lot of time to process, so more requests you do more time you ask us to dedicate to you. Also, more time is needed to explain you the rationale about a decision, it's more time dedicated to you. This type of activity is not sustainable at all. Let's write to avoid to forget, also PMs can be wrong or they can take decisions different than your point of view. I (or others) can consider a package as useful while you can consider it a waste of disk space. This is not the point, the point is the ever-increasing time these answers require to discuss with you. Do you see I'm spending my time in trying to communicate with you? It's part of my role but please, don't discuss about any tiny aspect where you disagree and avoid us to explain every single bit and accept a point can be disagreed. I have done a couple/lot of errors evaluating some of the over 10k requests I processed in these years (I'm not refering to mailx-git), maintaining a so high volume of requests is a heavy work, please be comprehensive and give people the chance to do the work at the best way the can, instead of pointing and requiring more and more time to discuss every details about any request. I cannot sustain these rhythms forever and as you can see the number of pending requests is still very high, also if you're canceling many of them. Please collaborate with the team, help the team to operate at the better, the PMs are your allies, players in the same team. Help them and respect the work they try to do, at the best they are able to do, including the eventual errors they might do. Thank you (sorry for the errors but English is not my language) -- Fabio Castelli aka Muflone
participants (4)
-
Marcell Meszaros
-
Marcell Mészáros
-
Muflone
-
notify＠aur.archlinux.org