Hi Eli and Sebastian, OK, I see the orphan request got approved. Certainly, wasn't looking to draw outrage, but get advice on what the appropriate action. I will update the relevant pythia, xrootd and submit deletion request myself for the others. As to the package signing, I already know how to detach sign. I also know about the source signing. What is not clear to me is repo-add --sign. The docs say it will update 'the package database'. Which package database? Does AUR keep such info? I though that was for Trusted Users and official repos. What I want to do is essentially to provide a convenient way for people to build or directly download pre-built packages, if they choose to, and be able to verify them, without too much hassle. What do you recommend? Should I just make a *-bin version on AUR with my signature and detach sign the binaries on my own repo? I thought this was also not the AUR way? Could I get someone's workflow for signed packages as an example? Regards, Konstantin On Fri, Mar 17, 2017 at 5:28 PM, Eli Schwartz via aur-general < aur-general@archlinux.org> wrote:
On 03/17/2017 09:48 AM, Konstantin Gizdov wrote:
xrootd-abi0 (this exists as a work around for other maintainer not updating package)
Don't do this. It violates the rules of the AUR and now that you have drawn our attention to it, expect someone to file a deletion request.
[...] Pythia, XRootD, Unuran are such extensions which were not available or broken in Arch. So I had to make 'pythia8' and 'xrootd-abi0' as workarounds. I have now finally been able to adopt 'pythia' and plan on making a major re-write and optimization. I still have to keep 'xrootd-abi0' as the current maintainer does not really update or fix his package when new versions/problems arise. I do not plan on making an orphan request, as I do not want to cause trouble for people.
However, I do wish to make the current environment as good as possible for the people that actually use it and would welcome any input from you. Thanks in advance.
What you say makes no sense. You want it to work well, but the current maintainer[s] is not actually maintaining the package[s]? And yet you don't want to file an orphan request because somehow, in some unidentified manner, an abandoned package getting a new maintainer constitutes "trouble for people"?
So instead you violate the rules of the AUR by making forked packages and confusing people about what is actually needed or available, you trick people into potentially using the *real* but non-working packages, and fail dismally at "mak[ing] the current environment as good as possible".
Good job! /s
...
Now, go ahead and file that orphan request you should have filed a long time ago, apparently.
Apart from that I wanted to understand better if and how package signing works with AUR. I tried the wiki and a bit of Google, but so far it seems package signing is only for official repos/trusted users. I did not want to try it out myself before getting some advice as I was afraid messing up will prevent people from installing them.
Signing is for anyone who wants to sign things. The real question is, what are you trying to sign?
- Built packages ==> `makepkg --sign`, or retroactively there is always `gpg --detach-sign builtpkg-1.0-1-any.pkg.tar.xz` - self-hosted package repository ==> repo-add --sign - PKGBUILD ==> they don't need to be signed since users are expected to read them... but there is always `git config commit.gpgsign true` which users are free to check although AUR helpers certainly won't - PKGBUILD source=() downloads ==> convince upstream to sign their release tarballs
-- Eli Schwartz