User talk:Quequotion/Arch User Repository

From ArchWiki
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.

Page header

Added "with no official support" to the warning, to be extra explicit that there is no safety net here.

Against this change, user content is unsupported by definition so anything added is redundant. More so with "at your own risk" which follows. -- Alad (talk) 12:59, 13 June 2019 (UTC)
I'm not so committed to this one; thought it might serve to balance the removal of "the AUR is unsupported"'s misplaced sentiment, but it isn't all that important if readers are going to understand this is what is meant by "user produced content". quequotion (talk) 11:25, 29 June 2019 (UTC)

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.

ERROR: One or more PGP signatures could not be verified!; what should I do?

This error is not at all limited to AUR packages, and is better placed in Makepkg#Troubleshooting (which is already done).

Original edit

Since the makepkg article already has makepkg#Signature checking, I've removed makepkg#ERROR:_One_or_more_PGP_signatures_could_not_be_verified! instead. Special:Diff/575350 -- Alad (talk) 13:05, 13 June 2019 (UTC)
In which case, could the FAQ be simplified to this one-liner? quequotion (talk) 13:41, 14 June 2019 (UTC)
Reduced it with [1] -- Alad (talk) 07:57, 24 June 2019 (UTC)
Looks good to me. quequotion (talk) 14:11, 24 June 2019 (UTC)

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.

What is the difference between foo and foo-git packages?

This could be less technical and verbose. Rather than explain everything here, it should link to VCS package guidelines and Version Control System for further details. This was attempted here.

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

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).