[aur-general] AUR mass deletion, why?

Tue May 4 13:07:35 UTC 2021

Am Di, 4. Mai 2021 um 07:49:33 -0400 schrieb Eli Schwartz via 
aur-general <aur-general at lists.archlinux.org>:
> On 5/4/21 3:52 AM, 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>:
>>>  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 rules of submission which you were pointed at, do not say "can't 
> be
> specific to your system", so keeping it "generic" is not sufficient.
> 
> The rules say "Will anyone else want to use this package? Is it
> extremely specialized?"

Hello. Yes, you're of course right. It just seems to be not to clear on 
what point "extremely specialized" starts. I'm pretty much confused. 
Can I give an example? (If not, please just ignore)
I got it now that pre-configurations are not OK and should stay on the 
wiki. What if I build a shellscript, pkgbuild this up and send it to 
the AUR, where a user installes and runs it later on? It will add the 
same configuration as my pkgbuild right now. In my mind that would also 
be not OK, because it's pretty much the same. Now I also add more 
configurations to this script, for printer setup, hardwareacceleration 
in browsers and whatever. Would it be OK in that case to put it to the 
AUR? I don't want to be rude in any way, I really really do not 
understand this one.

> 
> George was probably concerned that it was too personal and specific to
> one person.

This is OK. Thats why I'm here, asking about it.

> 
> I don't know why the nobeep package exists either, feel free to 
> request
> it's removal. Please don't justify one package that doesn't meet the
> submission guidelines, simply because someone else did something 
> similar
> and didn't get noticed.

That's a bad behavoir, sorry.

> 
>>  * https://aur.archlinux.org/pkgbase/fabiscafe-keyring/
>>  Is a pubkey, that is important to have signed packages active for 
>> our
>>  GNOME-unstable repo: see 
>> https://gitlab.com/fabis_cafe/gnome-unstable,
>>  and in future maybe also gnome-oldstable, see:
>>  https://gitlab.com/fabis_cafe/gnome-oldstable I dont know for sure 
>> if
>>  this was OK to be in the AUR, but since
>>  
>> https://aur.archlinux.org/packages/?O=0&SeB=nd&K=keyring&outdated=&SB=n&SO=a&PP=50&do_Search=Go
>>  archlinuxarm,32, even chaotic-aur and a lot more are there, I never 
>> saw
>>  a problem with that one.
> 
> For keyring packages... please consider the point of a pacman keyring 
> is
> to manage and distribute a web of trust. Arch Linux, as well as Arch
> Linux ARM and Arch Linux 32, have multiple packaging keys to manage, 
> so
> adding them is more complicated than simply pacman-key -r <keyid> &&
> pacman-key -l <keyid>; particularly, they actually need to make use of
> pacman-key's master key list, or revocation list.
> 
> I didn't check any others.
> 
> I'm not sure whether such packages are needed for one key, but I'm a 
> bit
> skeptical.

I know this is OT, but is there an alternative to a pkgbuild to add the 
key? What would be the optimal way tell pacman that packages of repo XY 
can be trusted?

> 
>>  * https://aur.archlinux.org/pkgbase/preconf-cups-desktop/
>>  Is a preconfiguration that enabled and installed printer support for
>>  desktops. Also not specific for me, just easy access.
> 
> We can tell what it is, yes. That's the problem. This PKGBUILD does
> nothing other than enable the systemd units from the cups package. 
> It's
> explicitly a problem -- do not reupload it under any circumstances.

I will not upload anything again until I am sure what's OK and what's 
not.

> Regardless of any other problems...
> 
> install=$(/usr/bin/tail -n 1 /usr/lib/os-release | /usr/bin/cut -d=
> -f2).install
> 
> This is not ok.

I'm with you on this. At some point all my packages have had that one. 
Most of them where changed back.

> 
>>  * https://aur.archlinux.org/pkgbase/game-devices-udev/
>>  This one adds udev rules for a lot of gaming controllers who might
>>  otherwise not work on your system. It's not really a 
>> preconfiguration.
>>  So also in here I dont understand why this was removed at all.
> 
> This one seems like it should be ok, I guess...
> 
>>  * https://aur.archlinux.org/pkgbase/unlock-pacman/
>>  This one just removes to pacman-lock at startup, in case it's there.
> 
> "this one just X"
> 
> You think "it just" is an explanation several times here, but no, you
> can't "just" because there are rules and you need to follow them.
> 
> A package to remove the pacman database lock on every boot is 
> definitely
> not useful to more than one person, in large part because IT IS
> BASICALLY MALWARE.
> 
> Do not recommend people break their systems. Do not recommend people
> with critically damaged systems, remove the lockfile that is supposed 
> to
> both point this out, and prevent them from breaking it even further.
> That lockfile means something -- it means you need to fix your system
> and if you don't know why then you need to ask for help.
> 
> You cannot normally get this lockfile unless pacman segfaulted halfway
> through an update -- or the entire operating system segfaulted, or
> abnormally powered off.

Got this. Yes it's a bad idea there is nothing more to say about it.

> 
>>  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.
> 
> 
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
> 