Talk:AUR submission guidelines

From ArchWiki
Jump to navigation Jump to search

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)

If you'd like to see how this page should look, and get a history without other changes, I've made a full page draft. quequotion (talk) 09:55, 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)
Well, I went to WP:BB it on VCS package guidelines, but turns out I can’t edit the page to begin with, so someone else will have to do this. —Freso (talk) 07:57, 26 April 2021 (UTC)
I have been waiting a terribly long time for anyone with the authority to make the necessary changes to complete the work of splitting the maintainer-oriented and user-oriented content from Arch User Repository, which was done just after months of mine and several other authors' work on that page was reverted (this page was set up for the maintainer oriented content, but half of it was left in the other page's FAQ and scattered warnings like this one). I have made many a desperate plea for the necessary changes, which I have had duely laid out in a draft page for quite some, to be made; or to promote me to editor if it is really the case that no one else has time no matter how many years go by. Instead, the line we have been discussing was reverted--to the maintainer-oriented statement about VCS packages--and I'm sure has become another nail in the coffin of my attempt to improve these pages. However, I have no intention of of giving up. quequotion (talk) 08:40, 16 August 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.

however, being more explicit does not hurt. Related discussion: [1] -- Alad (talk) 12:18, 4 May 2021 (UTC)

Sounds good to me.
-- NetSysFire (talk) 12:25, 4 May 2021 (UTC)
What about packages providing simple pacman hooks, systemd services, udev rules and similar things copy-pasted from the wiki? E.g. [2], [3], [4], [5].
What about [6]?
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)

Explicit mention of pushing to the master branch of AUR repositories

Nowadays the default branch name of git is usually main instead of master. As the AUR still expects pushing to a master branch, it might be better that we add some notes on this. GuDzpoz (talk) 06:30, 16 August 2021 (UTC)