Hello,

(Disclaimer: I'm just an AUR user and maintain a couple of packages, not a PM/TU and not associated with the Arch team)

> I was able to find an email address of the TU and sent him a response

This is not how one should oppose a deletion request and not how AUR works. A merge/deletion/orphan request could be opened by any registered user against any AUR package. A email is then automatically generated with associated info and sent to the aur-requests public list. Anyone subscribed to the list would get that mail delivered, and those not subscribed could check the list archive by themselves. The "anyone" here includes any user, and any PM (previously named TU). The initial mail in the thread does not carry any metadata of any PM, but rather just the no-reply sender, and the maintainers and the requester as the recipients.

At this point (mail describing the request sent to aur-requests list), no PM is associated with that request except the maintainer(s) themselves and the requester. Any one of the more than 60 PMs could come to their duty and accept the request to keep the AUR packages tidy and clean. So unless you've really made a good point to the exact PM you were sending mail to and they decided to refuse request, the only possible result is another PM that didn't read your private mail (which is not available in the public thread) decided to accept/refuse it based on what's available publicly.

See, you've made the situation worse by not opposing in the thread but only privately with one particular PM. Please, the way one should continue a discussion/thread and potentially express their thoughts against the request, is to reply to the thread. The other posters could be included in the CC list, but should not be the only one the mail is delivered to.

> I prefer automated updates over pushing repetitive git commits

But that's not how AUR and further how PKGBUILD should work. 

Yes, PKGBUILD is a Bash script under the hood but it's not just a Bash script. Its syntax is well-documented in PKGBUILD(5) and a well-formatted PKGBUILD is nearly always expected by the makepkg routine. Furthermore, a PKGBUILD itself should've defined a stable state of source(s) that should (at least try its best to) deliver a reproducible package on any builder/user. Your PKGBUILD however did some things on the other hand that one would never expect in a PKGBUILD:

• It relies on network access to yield proper data structures. Without network it does not even work. If I run `unshare -fmp --net --map-current-user` then `makepkg` then the PKGBUILD is completely broken since it could not get those data you expected to be always available. It I do `printsrcinfo` then it gives an interesting broken `url = https://packages.debian.org/source//linux-signed-amd64`.
  
• It could yield different data each time itself is parsed. Keep in mind that during the makepkg routine the PKGBUILD needs to be parsed more than once. What if the upstream updated their releases? Not only could this result in different packages built in different runs, this could also result in corrupted packages built (or not even build-able) in the same run.
• It does things unexpected in a PKGBUILD and makes itself a dangerous Bash script just like any other script you get from Internet and breaks the safety assumption about PKGBUILDs by the build systems. Yes one should always check PKGBUILDs but yours effectively makes it more hard that one needs to check not only the essential functions but also a lot of things you do outside those mandatory functions. Any one of those places you do `curl` and pipe around could become a vulnerability to shell injection.
  
• It writes to the current work directory which is a big no-go for PKGBUILDs. The work directory is expected to never be touched by the in-PKGBUILD routine but only makepkg itself. On the other hand your `linux-bin` PKGBUILD tries to create a `linux2.install`. It does not only dynamically generates code under the current work directory but also one that should be released statically alongside the PKGBUILD itself.
• It does some dirty parsing to get something already pre-defined by the makepkg routine, namely trying to manually get the arch when it should always be defined as CARCH in makepkg.conf and read by makepkg, etc.
  
• It slows down the whole building process a lot by assembling itself dynamically. On a normal PKGBUILD the `makepkg --printsrcinfo` usually only take ~2.1s but yours take ~11.26s. I have an optimized PKGBUILD parsing library (7Ji/pkgbuild-rs) which parses any PKGBUILD in merely a couple milliseconds but yours take a whopping 7.12 seconds, which is almost the time needed to parse 12406 official Arch PKGBUILDs when multi-threaded by the library.

If you do need dynamically generated PKGBUILD, at least make the dynamical part not a part of PKGBUILD itself. A lot of packagers do this to their AUR packages. E.g. a lot of third-party repo maintainers also post their PKGBUILDs on AUR with automatically generated commit message, of which the generator itself is not committed as part of the AUR history.

> make a note about the difference in the package comments section

Comments section is for note and for those who do check the AUR pages. Keep in mind a lot of users just use an AUR helper and never check the page. Your decision to keep the name misleading and not adding a descriptive pkgdesc is a no-go. When someone using AUR helpers dedicatedly without using Pacman itself searchs a kernel, this would appear to be a pre-built alternative to linux but is really not, and that is already troublesome as it could lead to some user installing it and bricking their system.

> I'm being attacked for my effort to resolve issues

As mentioned above, your "effort to resolve issues" were never posted to public list and those are not considered to even exist by any other trying to get what has happened. From my point of view and potentially others, what you did was repeatedly uploading the `linux-bin` package without properly fixing it and communicating with the community. And you only jumped out to the aur-general list after doing this three times and finally got your account suspended.

> not broken any of the rules despite being accused of doing so

Well if you do think you didn't break any rules, at least try to fix your package when informed to do so, instead of posting the broken PKGBUILD again and again. Posting a deleted package to AUR automatically revives it and considered an objection to the previous accepted deletion request. That itself is breaking the rules.

Please, calm down when you posting and tone like that is really not helpful.

Yours,

Guoxin Pu (7Ji)