[aur-general] AUR mass deletion, why?

[Fabian Bornschein]

Am Di, 4. Mai 2021 um 13:30:04 +0200 schrieb alad via aur-general 
<aur-general at lists.archlinux.org>:
> On 04/05/2021 09:52, Fabian Bornschein via aur-general wrote:
>> 
>> Am Di, 4. Mai 2021 um 07:01:54 +0000 schrieb George Rawlinson via 
>> aur-general <aur-general at lists.archlinux.org 
>> <mailto:aur-general at lists.archlinux.org>>:
>>> On 21-05-04 08:23, Fabian Bornschein via aur-general wrote:
>>>>  For fcgu-keyring I have had filled a removal request, so this one 
>>>> was
>>>>  deliberate to be erased. For everything else it would be nice to 
>>>> know the
>>>>  reason for this, in case I do something essential wrong.
>>>> 
>>>>  Thank you.
>>> 
>>> Hi Fabian,
>>> 
>>> As per my previous email; while responding to your removal request, 
>>> I
>>> had a look at your other packages and noticed that a lot of them are
>>> packages shipping custom configurations.
>>> 
>>> The AUR is not meant to be a repository for personal items and as 
>>> such,
>>> the packages shipping dotfiles were deleted. Please read the AUR
>>> submission guidelines, found here:
>>> 
>>> <https://wiki.archlinux.org/title/AUR_submission_guidelines>
>>> 
>>> --
>>> George Rawlinson
>> 
>> 
>> Hi George,
>> it looks like GMail doesn't like EMails. I've got the deletion 
>> notification but no other EMail. (Not even in spam). Strange, but 
>> back to topic.
>> 
>> Yes, many of them where preconfigurations of some sort, but not in a 
>> "specific for me system"-way, but kept generic so everyone can use 
>> them. In fact, I barely use any of them myself, but kept them up 
>> because someone asked me to keep them around.
> 
> The wiki specifically documents configurations so users can 
> understand what they do and adapt them as they wish. They don't 
> belong as separate packages in the AUR. This especially holds for 
> trivial changes such as blacklisting modules or enabling systemd 
> services.

Hi and thanks for this answer. I think this part would be welcome in 
the AUR submission guidelines, as there are a lot of packages starting 
from direct configurations like my packages and ending with 
applications who create the configuration later on. Because It's in my 
opinion not apparent that this kind of packages are not welcome in any 
way.

> 
> Some other remarks:
> 
> unlock-pacman: if there's a stale pacman lock that means the user 
> should investigate why it happened (e.g. interruption during an 
> update) rather than automatically delete it. Packages offering this 
> kind of functionality should never be uploaded.
> 
> Keyrings: Grey area as some are directly related to building packages 
> (eg. debian-keyring, archlinuxarm-keyring) while others are purely to 
> support users of an unofficial repo unrelated to the AUR (eg. 
> chaotic-keyring).
> 
>> 
>> None of them are in my opinion really specialized or specific for me 
>> alone and almost all of them add something of value to a users 
>> system. I can't find something that preconfigurations, wallpapers, 
>> udev-rules or "keyrings" are not allowed on the AUR either in 
>> <https://wiki.archlinux.org/title/AUR_submission_guidelines>. So 
>> I'm a pretty shocked by that move.
> 
> Common sense is advised. When you upload packages with things like
> 
> post_upgrade() { printf "\nThanks for still using my pkg 😊\n\n"; } 
> or
> 
> post_install() { printf "This is for Testing RN; please report 
> back\n\n"; }
> 
> in the install script it should be no surprise these packages are 
> treated with suspicion and eventually deleted.

OK, thats true. Sorry for these mistakes.

> However, requests are used to leave a paper trail and (egregious 
> cases aside) leave the maintainer some time to respond. I'd suggest 
> anyone to use that system where they are able.
> 
> Alad