Talk:AUR submission guidelines

From ArchWiki

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)
Nobody is making it hard on themselves, merely we are volounteers and don't have the time to review a complete overhaul of one of the most central articles in the wiki. Since people complained about the protection status, though, I am wondering if you still plan on going ahead and push your changes at will, given the opportunity, or wait for consensus like any other wiki editor. -- Alad (talk) 22:00, 13 January 2022 (UTC)
I have always been willing to get consensus. In almost every case, and remember the initial effort was dozens of small edits and never monolithic, I attempted to start a discussion before making changes. In some cases, I had that discussion in IRC and proceeded with what I perceived as approval from Trusted Users; I now understand that only discussions on talk pages "count". In some cases, I waited several months to make relatively trivial changes and then made them anyway; I got into a habit of asking for approval, waiting for someone to say no, and going ahead when it became clear that no one was interested in addressing the issues. I understand that a lack of disapproval is not equivalent to approval, just as I did then, but we need to address the facts that most changes to the wiki are made without discussion at all, proposals can languish on talk pages for years before someone realizes they are worth talking about, and the only way to actually start the discussion is often to have one's changes reverted. This workflow needs improvement even more than this page.
I understand that everyone is a volunteer, so am I. I am willing to do the work if anyone is willing to engage. I didn't propose or make these changes just to satisfy my vanity, and I won't say I am right about everything, but these changes are an earnest attempt to help not only readers of this wiki but the Archlinux project as a whole. I would love to discuss each and every proposed change, get your input, and make improvements wherever possible. We can do it in any order you like, and any time you like, if you (or any one else who's consent is sufficient) are ready to talk about them. quequotion (talk) 10:13, 14 January 2022 (UTC)
Considering most TUs are inactive on the wiki, maybe you could improve your chances at review by using the new "RFC" process: [1]
Note that an RFC needs at least one developer or TU that supports it. I'm not TU anymore, so you should open a discussion first in [2] or some other place like aur-general. -- Alad (talk) 14:32, 15 January 2022 (UTC)
To note an alternative, you could also apply as TU. That way you're sure to reach the people you want to reach. This needs 2 sponsors and basic qualifications explained in Trusted User. -- Alad (talk) 14:40, 15 January 2022 (UTC)
I'd like to start moving forward. One change that would be very helpful for this page, as well as the AUR page, is to upgrade the bulleted list of requests that can be made on the AUR web interface into individual subsections. The benefit here is for navigation on this page (readers will be able to select a type of request they need to know more about from the table of contents) and navigation from the AUR page (where sections refrence one of the requests specifically, they will be able to link to it directly rather than the enitre "requests" subsection). Here is what that will look like. This small change will do a great deal of good for navigation and readability across two of the most critical pages in the wiki. Please respond. quequotion (talk) 14:25, 19 April 2022 (UTC)
It's short list of points, a transformation to a section with subsection and Notes seems a bit much. Someone skipping from the table of contents would only skip a few sentences, and knowing about 1 type of request without knowing of the other two is not that useful for AUR users. -- Alad (talk) 23:04, 19 April 2022 (UTC)
Thank you for your response. I understand it doesn't seem like much information to be concerned about how accesible it is, or how well it is organized. It is not the amount that warrants this, but the importance of the information. It will also be helpul for a link or two on the AUR page to navigate here. As you say, the content is not lengthy, skipping to a specific will not prohibit readers from discovering what is directly above or below it: people will still be able to learn about all the requests just as easily as they will be able to look up a particular one. The notes are warranted in part by text already in the section ("Note this...", "Note that...") and also to distinguish information that is not critical to making a request (such as that packages git repositories continue to exist after deletion delists them in the AUR) or that explains the reasons for requirements (such as the deletion request in the AUR mailing list being the only available record after the request is granted).
The goal here is for the page to be as readable as possible, and that includes fixing issues like having a bulleted list inside a bulleted list. The easier this text is to internalize, the fewer people will make mistakes for lack of having understood it or ask questions it should have already answered for them. There were also a number of fixes to the text itself in my original draft, but those can be saved for later if there is some debate to be had over them; I note there may also be new information since that draft was written which I will of course incorporate.
Keep in mind, now that we are no longer dealing with a protected page I can do the work. I would not offer to do it if it were not worth doing. Improving readability, in ways both big and small, is worth doing. quequotion (talk) 14:40, 20 April 2022 (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)
I also was looking for it. Thanks for pointing out that it was mentioned in flagging packages out of date. The topic was discussed here. Now the VCS_package_guidelines#Guidelines explicitly contains that rule. I am closing this discussion now. Ashark (talk) 19:38, 20 June 2022 (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: [3] -- 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. [4], [5], [6], [7].
What about [8]?
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)

Yes; I second that. Why nothing has been done about that ? A simple note for the time being that we need to use git push origin main:master for the non git-hackers. A bigger fix would be that AUR use main by default to avoid this problem. But still working with older master branch of old aur packages solsTiCe (talk) 23:04, 26 January 2022 (UTC)

The git package still uses master as the initial branch when you git init. Unless you configured it to use main instead, in which case you should already know about the problem and how to solve it. — Lahwaacz (talk) 09:10, 29 January 2022 (UTC)
oh my, I forgot it was me that changed the default branch name /o\ —This unsigned comment is by Solstice (talk) 09:18, 29 January 2022 (UTC). Please sign your posts with ~~~~!