On Thu, Sep 1, 2016 at 2:38 PM, Eli Schwartz via arch-general <arch-general@xxxxxxxxxxxxx> wrote: > On 09/01/2016 12:54 PM, Diego Viola wrote: >> I actually know that, yes. My point is that there can be bad PKGBUILDs >> out there that could fetch the bitcoin-qt binary from somewhere else, >> which means I'll need to review the PKGBUILD beforehand or write my >> own. >> >> I admit to not use the AUR a lot (I stick mostly to packages from the >> repos), but I understand how the AUR works. > > Well, that is good, especially since I was joking. > > But you do realize that the idea of "bad PKGBUILDs out there" is a > known, fundamental part of the AUR and you are *always* advised to read > what you run before running it? Yes, I'm aware of that. > > ... with the exception of any particular maintainers who you may or may > not have a specific reason to trust. e.g. The Arch Developers and > Trusted Users, many of whom also maintain AUR packages. > > You can also check a *-git PKGBUILD once, save it and re-run periodically. > Or use the AUR git support to see what a maintainer has changed in their > latest push to the AUR. Some AUR helpers even remember your packages and > show you the diff of what changed... > Or use Xyne's "bauerbill"[1] AUR helper which can track who you trust > and/or which AUR upload dates you trust, individually or together (and > otherwise prompt you to review the PKGBUILD). > > ... > > Reading a PKGBUILD does not take a lot of time, why do you consider it > such a horrible burden that complaining on the mailing list about > "irresponsible" maintainers is more efficient? > > -- > Eli Schwartz > > > [1] https://bbs.archlinux.org/viewtopic.php?id=205834 Well, I understand maintainers are busy, but it is your job as a maintainer to communicate effectively, if I put some package up for others to use it, it is MY responsibility to tell users I won't be able to update or respond quickly. You can't expect all your users to maintain their own PKGBUILD for outdated packages just because some maintainer is busy or being lazy. Diego