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)
