On 2/28/19 8:58 AM, Jerome Leclanche wrote:
On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl <josef@miegl.cz> wrote:
Although I don't have high expectations when dealing with AUR packages, it is absolutely the maintainers job to keep track of upstream updates. This mindset is probably the reason why there is so much out of date stuff on the AUR. It strikes me that a maintainer who doesn't keep track of his own packages wants to become a TU.
No, it is not, and please don't expect this of volunteers. The responsibility goes as far as security (being made aware ASAP of security issues in packages), but knowing in general when a release happens is not (and/or shouldn't be) the TU's responsibility. Most TUs do know when a release happens in at least a portion of their packages, by nature of often maintaining packages they have some working relationship with. But the flagging system is very useful in crowdsourcing the non-security-sensitive portion of package maintenance.
As for being frustrated with the OOD packages on the AUR, I encourage you to make use of the flagging system yourself. It's present there as well. And if you think you can do better than the package's maintainer, ask to co-maintain it, or adopt it if it's abandoned. And in the mean time, you get to be able to download the PKGBUILD and modify it to your liking, that's the whole point of that system. If this sounds pointed, that's because I'm not amused by this idea that anyone who puts a package on the AUR should be at the service of those who download it. Arch philosophy goes above and beyond to drive in people's heads that the AUR is unsupported, to the point of rejecting any AUR helper in official packages. Expectations should be set accordingly.
I'm less concerned about people who don't keep track of OOD packages in the AUR, and more concerned about: "I respectfully disagree. The barrier to entry for the AUR is almost nonexistent and there's no expectation of support or quality - from Arch Linux or from the maintainers." This would be because I, um, respectfully disagree and believe that the memetic lack of quality in the AUR is something to be overcome by a community working together, not something to brag about. It is generally assumed that someone maintains a package because they care about it at least somewhat. An out od date package in the official repos *or* in the AUR, probably at least still works, right? -ENOTENOUGHTIME is an understandable issue to have. Quality of the package is a different story, though, and it likewise (IMO) applies in all cases. - Do we actually *want* people to say "I don't dare trust AUR packages to even build correctly without personal scrutiny"? - One of the purposes of the AUR is to serve as an initial testing ground so good, popular packages can be elevated to community. It's depressing when in order to move nice software to community, the AUR PKGBUILD needs to be thrown in the dumpster and rewritten from scratch. It is, contrarily, pleasant when the PKGBUILD is well-written and can be copied to community intact (with #Contributor lines etc.). Moreover, TUs are meant to be an example to the community: what does it say if a TU candidate has packages that are a bad example, not because they are a constantly-improving work in progress and one or two mistakes were made across most packages, but because: "I take some degree of personal pride in having nice AUR packages, but I also have a limited amount of time. Of course, I take my responsibility as maintainer much more seriously when working with packages in official repos." This feels like totally the wrong attitude to approach anything. It reads as though the limited amount of time has resulted in a belief that "I feel proud if my packages are quality, but if they're not, I won't try to make them better without being bugged by someone else, because I have better things to do with my time". Disclaimer: when I initially mentioned I generally admire Drew's open-source work, this did not take into account his AUR packaging standards, as I had not looked at any of them. I can 100% see why people are looking at this and wondering if maybe his impressive work elsewhere in the Linux community is only impressive elsewhere, where he feels his time is a worthwhile investment. I'm sure most if not all Devs and TUs can tell similar stories about being overworked. I would hope that we all still invested in devoting at least some of that time to improving our packages even when they're not official repo candidates. After all, packaging, and being a good example of it, is ostensibly one of the jobs of a TU. There is a reason the job description includes "people who oversee the AUR".
On Thu, Feb 28, 2019 at 2:16 PM alad via aur-general <aur-general@archlinux.org> wrote:
Generally, while expectations are naturally not as high as with community packages, lacking quality of PKGBUILDs in AUR remains problematic when trying to promote AUR packages to community. Due to this, a complete rewrite of the PKGBUILD is usually required, rather than making some minor adjustments.
https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html
OT: We should maybe have the AUR lint PKGBUILDs on git push (and reject really bad ones) if we want to improve that situation.
I would eagerly welcome any way to reliably do exactly that in an automated fashion, with the caveat that doing so more or less inevitably involves arbitrary code execution -- this is the reason why we in fact do not read the PKGBUILD at all, but created the .SRCINFO instead. I see no reason why we should allow packages that do not actually build correctly at the time of submission, except the fact that it has thus far proven to be programmatically infeasible. -- Eli Schwartz Bug Wrangler and Trusted User