Talk:Arch User Repository

From ArchWiki
Revision as of 16:31, 10 June 2019 by Alad (talk | contribs) (Revert to 03.02.2019 revision: add)
Jump to navigation Jump to search

contribute to existing package

what is the best way to contribute to an existing AUR package? i cloned one and tried to push but it gave me a permission error --Soloturn (talk) 16:04, 28 January 2019 (UTC)

Users are not allowed to modify something owned by another user. It's no different from cloning a Github repository and trying to push to that. The equivalent of submitting an issue would be leaving a comment with a patch file. The AUR platform in particular allows collaboration features -- you may request that a maintainer grant you push access by adding your name as a co-maintainer. If the package is broken or out of date, see Arch User Repository#Foo in the AUR is outdated; what should I do?
This is possibly something that we should make clear in a FAQ entry. -- Eschwartz (talk) 19:49, 28 January 2019 (UTC)
I was thinking about this while writing a proposal regarding "Other requests". It is possible to request a package be disowned with "Orphan"; why not add "Co-maintain" to send a request to ask for permission to assist with a package's maintenance? Of course, it would not be unnecessary to send that request to the mailing list, and there's always the AUR comments or the forums for users to contact a maintainer otherwise; but having the feature built in to the AUR would allow us to add a fourth subsection here to recommend ground rules and possibly expedite the process of adding co-maintainers when packagers are interested in doing so. quequotion (talk) 14:45, 6 February 2019 (UTC)
Rather than an FAQ, maybe add a bullet point under "Maintaining packages". Question: Who has the right to use "Manage Co-Maintainers"? quequotion (talk) 15:07, 27 May 2019 (UTC)
Closing proposal below, now implemented. Leaving discussion open: in the future, we may want to break long bulleted lists like "Rules of Submission" and "Maintaining Packages" into subsections. This would make it more convenient to link to specific points in the list, which in turn would be convenient if we still want an FAQ such as "How can I contribute to an existing package?" (which should link to adopting orphaned packages, commenting on a package, and adding co-maintainters) quequotion (talk) 09:31, 4 June 2019 (UTC)

Proposal: Maintaining packages (Add co-maintainers)

  • Additional maintainers can be added to or removed from a package by clicking "Manage Co-Maintainers" under "Package Actions" on the right of its AUR page and editing the list.

Proposal: How can I contribute to an existing package?

If the package is orphaned you may adopt it, otherwise you may post your idea in its comments or ask to be appointed as a co-maintainer.

Reduce FAQ content

Truncate FAQs' answers as much as possible, linking to an appropriate page or (proposed) section of the AUR page. Only FAQs with changes proposed are listed; unlisted FAQs remain as they are. quequotion (talk) 15:02, 27 May 2019 (UTC)

Proposal: FAQ

What is the AUR?

Comment: Proposing to delete this FAQ entirely. I can find no reason for this to be here; the answer is the page header. Is it possible that someone would read this page and still have this question to ask? quequotion (talk) 14:47, 12 February 2019 (UTC)

What is a Trusted User (TU)?

The Trusted Users are elected to oversee the AUR and maintain the community repository.

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

Many AUR packages come in "stable release" and "unstable development" versions. Development packages usually have a suffix denoting their Version Control System and are not intended for regular use, but may offer new features or bugfixes.

See also System maintenance#Use proven software packages and VCS package guidelines.

Comment: These changes are essentially complete, but could be improved with Talk:VCS package guidelines#Proposal: Package naming (to have a more specific link to "suffix".

How can I obtain a list of all AUR packages?

Comment: Adding a word here, to soften the blow. quequotion (talk) 14:27, 27 May 2019 (UTC)

Improve "Rules of submission" section

This section is a lengthy list of bullet points; breaking it down into subsections would make it much more navigable; this may escalate into that later. For now, only rules with changes proposed are listed; unlisted rules remain as they are. quequotion (talk) 14:51, 27 May 2019 (UTC)

Proposal: Rules of submission

  • Submitted PKGBUILDs must not duplicate applications in any of the official repositories. Check the official package database; if the package exists, do not submit a duplicate. If the official package is out-of-date, flag it as such. If the official package is broken, or lacking a standard feature, please file a bug report.
The only exception to this is for packages with extra features enabled and/or patches in comparison to the official ones, in which case pkgbase should be different to express that.
Comment: Offload some text and make a more far-reaching policy statement via Talk:Arch package guidelines#Proposal: Unofficial packages quequotion (talk) 14:51, 27 May 2019 (UTC)
  • Do not use replaces in an AUR PKGBUILD unless the package has been renamed or deprecates another, for example when Ethereal became Wireshark. If a package is an alternate version of an existing package, use conflicts (and provides when the offending package has dependents).
Note: replaces forces pacman to install the replacement package as an upgrade of the offending package, while conflicts tells pacman to remove the offending package only if the conflicting package is to be installed.
Comment: Although the place to explain replaces is really the PKGBUILD article, I see the need for this blurb with this rule. I think it could be done better though. Particularly I'd like to remove the implication that pacman -Sy is to be used for any purpose. quequotion (talk) 14:51, 27 May 2019 (UTC)
Changes to this bullet point are completed. quequotion (talk) 09:09, 4 June 2019 (UTC)

Removal of SSH key tutorial

What is this about? Are you sure those AUR-specific tutorials should be removed? Don't get me wrong, I'm all for minimizing any section of the page that safely can be, but it seems like this edit leaves out some important information (like specifying a corresponding private key configured for the host). quequotion (talk) 12:44, 22 February 2019 (UTC)

My edit was motivated by strong disagreement with the statement "You should create a new key pair rather than use an existing one, so that you can selectively revoke the keys should something happen". Imho it is misleading to imply any security benefit resulting from creating per-target-host SSH client key pairs. If anything, this bad habit complicates revoking compromised keys. Adding a Host-section to the SSH client configuration file is unneccessary if you only have a single SSH client key pair, as it will be selected automatically. Pyropeter (talk) 02:11, 23 February 2019 (UTC)

the wording around pkgbase is unclear

In Creating_package_repositories, some people might end running the exact command below even if they do not copy-paste commands blindly:

git clone ssh://

This part is unclear: "establish a local Git repository and an AUR remote by cloning the intended pkgbase.": some readers might think that here pkgbase is not a PKGBUILD variable but instead describe the name of a repository that has a template for creating packages.

Several people already pushed their packages in this pkgbase repository.

So it would be best to make sure that the people reading this understand that the pkgbase refers to the PKGBUILD variable and not to a PKGBUILD template. As the pkgbase variable is often not defined explicitely in PKGBUILDS, readers don't necessarily have that variable in mind at the time of reading that section.

Maybe the following would be more clear:

If you are creating a new package from scratch, establish a local Git repository and an AUR remote by cloning the package's repository which is located at ssh:// Replace PKGBASE by your package's pkgbase.

GNUtoo (talk) 15:15, 31 March 2019 (UTC)

This is why it is italicized; it should be clear that it represents a variable. It would be more clear if users have read the PKGBUILD page first, which they should. Maybe it would be better to block packages from being uploaded to 'pkgbase' in the AUR. quequotion (talk) 00:42, 1 April 2019 (UTC)
In the paragraph quoted above, "pkgbase" is a link to the section of PKGBUILD explaining what it is. Not sure if that was done after this discussion or before, but I think it resolves the issue--readers who don't understand the meaning of pkgbase should click here and find out. quequotion (talk) 09:40, 4 June 2019 (UTC)

Adopting orphaned packages

Although adoption by a new maintainer is mentioned several times in the article, how this is done is not explicitly stated. The procedure is the same as for creating a new package (clone from ssh source, or set source url to ssh if cloned from https). quequotion (talk) 20:00, 19 May 2019 (UTC)

Might also be a good idea to mention where the "adopt package" button is on the AUR web interface. Curious though, if it is really necessary to click this, or if pushing to an orphaned repository will automatically adopt it. quequotion (talk) 15:13, 20 May 2019 (UTC)
Implemented. quequotion (talk) 09:20, 4 June 2019 (UTC)

Previous: Creating package repositories

If you are creating a new package from scratch, establish a local Git repository and an AUR remote by cloning the intended pkgbase. If the package does not yet exist, the following warning is expected:

Proposal: Creating or adopting package repositories

If you are creating a new package from scratch, or adopting an orphaned package, establish a local Git repository and an AUR remote by cloning the intended pkgbase. If the package does not yet exist, the following warning is expected:

Proposal: Maintaining packages (Adopt packages)

Comment: An additional bullet point for this subsection. quequotion (talk) 15:32, 20 May 2019 (UTC)
  • Orphaned packges can be adopted by clicking on the "Adopt Package" link under "Package Actions" on the right of its AUR page.

Revert to 03.02.2019 revision

After discussing the many changes to this article, me and the TU team agreed to revert this page to the 03.02.2019 revision. Besides that most of the changes were one-sided, many of them change meaning or add incorrect information (such as the article mentioning that adopting an orphaned package allows to push changes, while the mere fact of pushing to an orphaned package automatically adopts it) or reduce clarity (such as the rewording on .SRCINFO regeneration or the "source format" term in Arch_User_Repository#What_is_the_difference_between_the_Arch_User_Repository_and_the_community_repository?).

To avoid this in future, I've moved the content in AUR#Sharing and submitting packages to a seperate protected page: AUR submission guidelines. That way the official guidelines for package submission cannot be changed without prior notice, while content related to retrieval and installation of AUR packages may still be edited freely. If there are suggestions to make new changes to AUR submission guidelines, please create a draft page and post it on the talk page of that article. The same holds for any other proposed changes to the AUR article, especially if major. -- Alad (talk) 16:29, 10 June 2019 (UTC)