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
