Talk:AUR submission guidelines
Improvements from the AUR page that was reverted
It was in grievous error that this page was created from the version of the AUR page that it was reverted to, and not the version that it was reverted from. Not only has it made this content more difficult to navigate, but left the AUR page in a broken state with maintainer-oriented FAQs, etc that now have no place there. Several issues with the page that had been discussed and resolved have been restored to a broken state as well (which forum should users or maintainers use; policy on packages shipping binaries, etc). quequotion (talk) 04:42, 11 June 2019 (UTC)
- There are a lot of changes to review; so I've compiled a rundown of them on the talk page of the draft. quequotion (talk) 13:48, 14 June 2019 (UTC)
- Please keep the draft on the User:Quequotion/AUR submission guidelines. Using this talk page for three purposes - article discussion, draft, and draft discussion - makes it extremely hard to follow, as made obvious by the stalling discussions in Talk:Arch User Repository and the following mass adoption of content without prior consensus. Closing the subsections below (#Proposals) hence. -- Alad (talk) 13:16, 11 June 2019 (UTC)
- I'd like to post a reminder that these proposals still stand. If anyone in a position to review the changes and comment, or implement them, feels overwhelmed: I ask you to consider that you are making it hard on yourself. Pick any one section of the breakdown, read the reasons I give for the changes I have made, follow the link at the end of the section to see the specific changes, leave a comment. Each section--including the specific changes--should only take a few minutes to read. There's no need to go through the whole set of proposals at once. Start somewhere, please. The page needs these changes. quequotion (talk) 15:47, 5 January 2021 (UTC)
Explicit statement about source hosting in AUR
Sometimes users tend to include little scripts in the AUR package itself and not use external hosting. As far as I understand this is not welcome, but I could not find any source for that. I propose adding a statement to the rules making this rule clear (if it is indeed valid). Fordprefect (talk) 09:41, 4 June 2020 (UTC)
Updating VCS packages’ $pkgver every 2–3 commits
I feel like this policy used to be mentioned on the wiki? Or at least has been mentioned a few times on the mailing list(s). Anyway, currently I can find no mention on the wiki about the policy/guideline to not push new PKGBUILDs to the AUR that simply update the
$pkgver of VCS packages, esp. when it’s done every 2 or 3 commits. Is this mentioned somewhere I couldn’t find? Is it not actually official guideline/policy but just preference of some TUs on the mailing list(s)? —Freso (talk) 00:55, 11 February 2021 (UTC)
The VCS package guidelines advise against ever updating pkgver deliberately, with explanation. Perhaps we could do a better job of linking AUR submission guidelines to Creating packages and/or the former. quequotion (talk) 17:38, 13 February 2021 (UTC)
- I just looked over the VCS package guidelines a couple of times, and I cannot find where it “advise[s] against ever updating pkgver deliberately, with explanation.” I may totally be just glossing over it. Can you tell me the specific part of those guidelines that mention this? 🙇 —Freso (talk) 22:53, 13 February 2021 (UTC)
- Sorry about that, seems my memories are mixed up too.
- Have a look at this discussion regarding pkgver policy on the VCS package guidelines' talk page.
- What's left of this warning is on the AUR wiki page, as a note attached to Arch User Repository#Flagging packages out-of-date. The wording has been changed, probably by me. The way it reads now doesn't communicate "don't bump pkgver for VCS packages" like it used to. The problem with having the original wording on the AUR page is that it became a user-oriented page (so it tells users not to fret if their pkgver is newer than the AUR's), while this page (AUR submission guidelines) took over the content for AUR package maintainers. There should probably be an explicit warning on this page or the VCS package guidelines page. quequotion (talk) 00:12, 14 February 2021 (UTC)
- “There should probably be an explicit warning on this page or the VCS package guidelines page.” is pretty much what I was asking for/about in my original comment. :p Should I just WP:BB and try and write something, should it go through more of a process, or should I leave it to a TU or similar? —Freso (talk) 11:00, 14 February 2021 (UTC)
Explicit mention of hosting configuration files
Packages which only include configuration (files or commands) are usually not allowed on the AUR, because they are already documented on the wiki with the necessary context. This holds especially when the configuration is straightforward to use outside of a package, e.g. enabling a service or blacklisting a module. It can be seen as a specific version of:
- Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.
- What about packages providing simple pacman hooks, systemd services, udev rules and similar things copy-pasted from the wiki? E.g. , , , .
- What about ?
- — Lahwaacz (talk) 07:49, 5 May 2021 (UTC)
- I personally and very selfishly hope these are allowed to stay. While I could make those files myself, I really appreciate them being tracked by the package manager, especially in cases where they have dependencies on other packages (e.g., the dash hook wouldn’t work very well without dash installed), and it seems like a lot of wasted effort to make my own PKGBUILD for this knowing that others have already done this. —Freso (talk) 08:06, 5 May 2021 (UTC)