[aur-general] AUR mass deletion, why?

[alad]

On 04/05/2021 14:04, Fabian Bornschein via aur-general wrote:
>
> 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.

Sounds reasonable -- I will add an item to the wiki discussion page later.

Alad


>
>>
>> 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
>
>
>