[aur-general] AUR mass deletion, why?

[Fabian Bornschein]

Am Di, 4. Mai 2021 um 14:27:59 -0400 schrieb Eli Schwartz via 
aur-general <aur-general at lists.archlinux.org>:
> On 5/4/21 9:07 AM, Fabian Bornschein via aur-general wrote:
>>  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.
> 
> Sounds like it would still ultimately be user configurations through 
> and
> through... it's fine to have a PKGBUILD for user configs, the question
> is whether they're useful in the AUR.
> 
> I'd recommend doing something like this:
> 
> https://github.com/Earnestly/pkgbuilds/blob/master/system-config/PKGBUILD
> 
> And then documenting it, using factored-out *.d/ directory dropins 
> where
> possibble, and so on, in order to let people take inspiration from 
> you,
> but keep it out of the AUR.
> 
> Maybe start a wiki page similar to the dotfiles one:
> https://wiki.archlinux.org/title/Dotfiles
> 
> Then people can both share tips on designing their system config
> packaging, and share their actual configuration as examples.
> 
>>>  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?
> 
> Sure. a pacman keyring compiles a known collection of keys as a 
> shortcut
> to, again, using
> 
> sudo pacman-key --recv-keys <keyid>
> sudo pacman-key --lsign-key <keyid>
> 
> But mostly it is there to help manage pinning a collection of them as
> "master keys" which are lsigned, and other keys which are not but use
> Web of Trust.
> 
> For a single user key, I'd recommend using the recv-keys && lsign-key
> route. Simply document on the page describing the repository, that the
> key needs to be added. For example, on the wiki page:
> https://wiki.archlinux.org/title/Unofficial_user_repositories
> 
> There is a template for listing the Key-ID needed, and the page has a
> preamble describing how to enable those keys. It works for 64 
> different
> publicly listed user repositories as of right now.
> 
> 
> Use a keyring package if you have more complicated requirements
> including key rotation and delegated trust. Unless you're managing an
> organization such as a CPU port of all of Arch Linux (like the i686
> port, or the ARM port), you probably do not need this.
> 
>>>  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.
> 
> Thank you. Remember that the aur-general mailing list, the freenode 
> IRC
> channel #archlinux-aur, and the official forum's dedicated AUR 
> subforum,
> are all available to anyone who wants help creating packages *or* a
> friendly set of eyes to review a package before upload. If in doubt,
> feel free to ask, we won't bite people asking honest questions and 
> being
> careful. :)
> 
> (It is possible we might bite if a package was mistakenly uploaded 
> which
> should not be -- but that would be tied to individual reactions on
> failure to ask first and the resulting work it causes. :p)
> 
>>>  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.
> 
> Ok, good -- please do fix up any remaining ones. :D
> 
> 
> --
> Eli Schwartz
> Bug Wrangler and Trusted User


I have to thank you (everyone on here) to be so patient and helpful. 
I'll rearrenge, drop and fix things up.
Thanks for this conversation. :D