User talk:Quequotion/Arch User Repository

From ArchWiki
< User talk:Quequotion
Revision as of 09:49, 2 October 2019 by Quequotion (talk | contribs) (→‎Page header: Clearing closed section.)
Jump to navigation Jump to search

Breakdown of changes

I've been told my changes are hard to follow, and this--in part--led to the reversion of several months' work on the AUR page and splitting half of it into a protected page. I will try here to describe the changes as best I can. Nonetheless, if you are looking to compare the draft to the current page that is what you should do; rather than digging through edit histories, compare the two at their current state (just like you would two drafts of a physical document), and leave feedback from this comparison.

As some changes depend on others, this breakdown will be in the order such changes are intended to be made.

FAQ

Most of these changes are to reduce FAQ answers to the shortest possible statements with links to appropriate tutorials and information elsewhere. Much of their of content is duplicated from pages like PKGBUILD and Makepkg; some FAQs sequester information that should have a relevant section on either the User:Quequotion/Arch User Repository or User:Quequotion/AUR submission guidelines pages.

How do I create a PKGBUILD?

This could be less verbose; which is what I attempted to achieve here.

A more extreme option would be to reduce this to just "See creating packages." and trust the reader to have read the User:Quequotion/AUR submission guidelines#Rules of submission.

I don't see removing the link to the instructions on creating a PKGBUILD an advance. Jasonwryan (talk) 20:55, 21 July 2019 (UTC)
That link is still there! Only superfluous text was removed. quequotion (talk) 02:31, 22 July 2019 (UTC)
While waiting for jasonwryan to revise his review, I've come up with a better version.
Obviously I do not intend to link to a draft proposal on the actual AUR page (this would become a link to AUR submission guidelines#Rules of submission), but I would like to remind readers that this proposal is also in need of review. quequotion (talk) 16:37, 24 August 2019 (UTC)

What is a Trusted User (TU)?

It isn't necessary to explain in so much detail here, as this FAQ already links to pages with more details. Furthermore, I'd rather use a different format for the title of this FAQ. See Special:Diff/574544

Removing the reference to [community] is not that helpful: it is central to an understanding of the TU role. Jasonwryan (talk) 20:58, 21 July 2019 (UTC)
There is still a link to the community repository page in a sentence that describes the TU role in that repository. Is this insufficient? quequotion (talk) 02:38, 22 July 2019 (UTC)
It is not as clear that they are responsible for [community] as well is what I meant (and expressed badly). Jasonwryan (talk) 02:41, 22 July 2019 (UTC)
I see what you mean, and have reworded to clarify the two-fold role TUs play in community. quequotion (talk) 06:41, 22 July 2019 (UTC)
Looks OK to me, but a TU should make the final call (on most of these changes, really). Jasonwryan (talk) 07:01, 22 July 2019 (UTC)
Considering how much hounding, hassling, and time it took to get this review, moving the goalpost that far out of field will likely delay this several years. I think your approval is consensus enough, but I will allow one more week for refutation before I implement this change. quequotion (talk) 15:36, 24 August 2019 (UTC)
The original revision is definitely not perfect. The proposed one, however, only removes details (like "popular" AUR packages constitute the majority of community packages by definition) and tacks on a second "also" sentence because the first did not suffice.
I'm also tired of your melodrama and suggest you leave it at home. -- Alad (talk) 17:15, 24 August 2019 (UTC)
How about this version? The issue with the "also" part, (now "as well as") is trying to express the three aspects of their role in one sentence with sound grammar: to say they oversee the AUR and community, in addition to saying they maintain community packages, without accidentally implying that they maintain packages in AUR.
The original version of this used the word "popular" to describe the packages in community without explaining that it meant popular AUR packages promoted to community, besides which, the detail is extraneous: what this FAQ should do is identify the TUs, as breifly as possible explaining what they do, linking to details elsewhere.
See User:Quequotion/AUR submission guidelines#Promoting packages to the community repository for a more appropriate subsection dedicated to explaining how AUR packages may enter community, and User_talk:Quequotion/AUR submission guidelines#Promoting packages to the community repository to discuss it. quequotion (talk) 19:19, 24 August 2019 (UTC)

Feedback

Note: From this point on, the changes become more interdependent and their order more critical. The revised "Feedback" section, for example, links to User:Quequotion/AUR submission guidelines#Orphan rather than have its own embedded tutorial on the matter.

There is a separate section on the page for "Comment syntax" two subsections below the section about comments. It stands to reason these related sections should be merged, or at least put in sequential order.

The "Feedback" section, as of February 3rd, covers comments and voting, but not flagging packages out-of-date, which is tied up in an FAQ that contains redundant information about orphan requests. There's even another FAQ about voting for packages that features a bit of a tutorial on the AUR Web Interface.

All of this can be combined into a much less redundant, one-stop-shop "Feedback" section covering all three types of feedback users can send to AUR package maintainers, with less to read on the page as a whole.

This was done over six sequential edits, starting here.

A seventh, non-sequential edit was made to make "Commenting on packages" less pedantic.

Debugging packages

Note: With the package maintainer-oriented and user-oriented parts of the page split across two pages, so this section needs to be split. See User:Quequotion/AUR submission guidelines#Verifying packages for the package maintainer-oriented content.

Package verifying and debugging information is scattered across both pages. Although such information can be found by reading Creating packages, Makepkg, PKGBUILD, and DeveloperWiki:Building in a clean chroot, some of the information is AUR-specific (such as which forums to ask for help in, linking to IRC, etc).

Most of the information comes from Arch User Repository#Foo in the AUR does not compile when I run makepkg; what should I do?, Arch User Repository#I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors? and the header of AUR submission guidelines#Submitting packages. Combining these sections allowed for several simplifications in addition to taking advantage of existing tutorials in other articles and linking to them rather than duplicating them on these pages.

This was done in six sequential edits, with some error in execution of the fourth (content was copied from the "Submitting packages" header but not deleted there with other simultaneous changes occurring), starting from here.

To reduce the wall-of-text effect, several some parts of this section were elevated to bullet points in a later edit.

Installing packages

I understand that this change was cited in the discussion that precipitated the reversion for removing "The AUR is unsupported".

As noted by Alad above, the unsupported status of AUR packages should be well established in readers' minds by this point.

This warning creates ambiguity about pacman. The (technical) reason pacman does not get AUR updates is not because AUR is unsupported, but because pacman can only interface with repositories of prebuilt packages--including unsupported, third-party repositories. My rewording was intended to clarify that pacman is not capable of discovering AUR package updates, and it still states that it is the user's responsibility to check for them.

Acquire build files

The last two of my edits before the reversion, sequentially from here, are an attempt to minimize this subsection by combining the two bullet points regarding downloading a package description tarball and taking an alternative approach to Gcb's idea (note that Gcb specifies only "Option 1" and "Option 2" for three bullet points).