[aur-general] Review and a bit of other help request

[Konstantin Gizdov]

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 at 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
>
>