[aur-general] AUR mass deletion, why?

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20210504/f6bb92be/attachment-0001.sig>