Am Di, 4. Mai 2021 um 14:27:59 -0400 schrieb Eli Schwartz via aur-general <aur-general@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