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
OpenPGP_signature
Description: OpenPGP digital signature
