Talk:Arch User Repository: Difference between revisions

From ArchWiki
(Creating a new package: uploading an existing package to AUR: Re: regenerate .SRCINFO)
(→‎Proposal: Publishing new package content: break out SRCINFO note to its own bullet. This is necessary irrespective of the version changing (although of course the version should always change in such cases))
Line 97: Line 97:
{{Tip|To keep the working directory and commits as clean as possible, create a {{ic|.gitignore}} that [[dotfiles#Using gitignore|excludes all files]] and force-add files as needed.}}
{{Tip|To keep the working directory and commits as clean as possible, create a {{ic|.gitignore}} that [[dotfiles#Using gitignore|excludes all files]] and force-add files as needed.}}


{{Note|When updating a package, except for very minor changes (such as fixing a typo) that would not require re-installation of the package, update its [[PKGBUILD#Version|version]] accordingly and be sure to regenerate {{ic|.SRCINFO}} for publishing any such metadata updates in the AUR.}}
{{Note|
* When updating a package, except for very minor changes (such as fixing a typo) that would not require re-installation of the package, be sure to update its [[PKGBUILD#Version|version]] accordingly.
* Remember to regenerate {{ic|.SRCINFO}} on every update to the PKGBUILD; otherwise the AUR will not show updated version numbers or other metadata changes.}}


For example:
For example:

Revision as of 03:14, 20 January 2019

What is the correct AUR forum section?

Arch_User_Repository#Submitting_packages says it's [1], but we also have [2]. One of them should be added to Arch_User_Repository#I_have_a_PKGBUILD_I_would_like_to_submit.3B_can_someone_check_it_to_see_if_there_are_any_errors.3F. -- Karol (talk) 12:30, 7 August 2015 (UTC)Reply[reply]

Markdown Syntax

Should there be a Markdown syntax section? [3][4] All those seem to work: linkDettalk 16:24, 5 December 2017 (UTC)Reply[reply]

Oh wow, yes please. I had no idea that this was possible. And it's still unclear to me what syntax it uses. —Ostiensis (talk) 20:52, 5 December 2017 (UTC)Reply[reply]
Well, there's a preliminary section: Arch_User_Repository#Comment_syntax. --Dettalk 22:28, 13 December 2017 (UTC)Reply[reply]
[5] Well, I don't know how to do that, since they only implemented a small part of it? --Dettalk 22:35, 13 December 2017 (UTC)Reply[reply]
Here they use the Python-Markdown library, which "is almost completely compliant with the reference implementation, though there are a few very minor differences." -- Lahwaacz (talk) 22:50, 13 December 2017 (UTC)Reply[reply]
Thanks for that. FWIW I've never seen that multiline code syntax before, so I wonder if it *is* some strange home-brew markdown. —Ostiensis (talk) 22:37, 13 December 2017 (UTC)Reply[reply]

FAQ - outdated package

Do you understand what the comment means "When we are talking about a package which is flagged out of date for more than 3 months and is in general not updated for a long time, please add this in your orphan request. " ? Kewl (talk) 15:49, 13 January 2018 (UTC)Reply[reply]

When people request a package to be orphaned because the current maintainer does not respond to out-of-date notifications, it should be clarified in the request to speed up the resolution. -- Lahwaacz (talk) 18:05, 13 January 2018 (UTC)Reply[reply]
Yes indeed and what about the 2 weeks vs the 3 months difference in the comments? This is what I don't get, if this is more than 3 months we should say in the comments "it has been 4 months" but if it has been let say 2 months we should not mention it? The rule is not clear and I am wondering if it is more urgent to find an adopter for a package that has not been updated for 2 years or for 3 weeks. In the latter case it does seem more urgent, rather the opposite then. Kewl (talk) 18:57, 13 January 2018 (UTC)Reply[reply]
I think that the 2 weeks are for the maintainers to react to the request, even if it is not due to out-of-date package. Anyway, the FAQ entries are not strict, I doubt that the 3 months are obligatory. -- Lahwaacz (talk) 19:15, 13 January 2018 (UTC)Reply[reply]
I have rephrased providing some more details in line with the AUR request template. The 3 months does not seems to be anything official, the 2 weeks neither but sounds reasonable. Feel free to amend or revert. Kewl (talk) 19:41, 13 January 2018 (UTC)Reply[reply]

Creating a new package: uploading an existing package to AUR

I have some issues with the new language introduced here, primarily that it is overly verbose, see inline comments. quequotion (talk) 16:28, 6 January 2019 (UTC)Reply[reply]

I understand you'd prefer more time to debate, but I did consider this a minor correction as much of the language is redundant and technically inaccurate. quequotion (talk) 19:36, 6 January 2019 (UTC)Reply[reply]
But it included multiple changes, including both the minor merging of redundant content and the non-minor removal of a policy recommendation using an edit message that was marked as minor and only specified the former... -- Eschwartz (talk) 19:57, 6 January 2019 (UTC)Reply[reply]
If there are no objections, I plan to merge this proposal soon. quequotion (talk) 16:36, 15 January 2019 (UTC)Reply[reply]
This makes 3 changes. Change #1, specifying PKGBUILD#Version and merging up "otherwise the AUR will not show updated version numbers", I am okay with. Change #2, relegating minor changes to a tip, I haven't changed my mind on -- I still think it should be a "do not" rather than a "you don't have to if you don't want to", and thus disagree with the change. Change #3, linkifying PKGBUILD and .SRCINFO, is confusing since now the latter is linkified twice, and the former is only linkified because the first reference to the PKGBUILD has disappeared from the preceding paragraph. -- Eschwartz (talk) 17:11, 15 January 2019 (UTC)Reply[reply]
Thanks for the feedback. I've reintegrated the tip with the paragraph; still avoiding explicitly saying "do not", but meaning the same thing. Regarding the links, I feel like the best way to resolve that is to move "When updating.." to a Template:Note (because it is an aside; not required for every update) below "To upload..", which comes almost full circle to combining it with the note about retroactively adding .SRCINFO to the first commit. If Since we are keeping the git tutorial, it makes sense for it to be between them, as the second note is relevant to when this procedure fails in the case that .SRCINFO is missing from the initial commit.
Also, not terribly important, but the tip about .gitignore fits more logically under "To upload..." than at the end of the section. This is a complex change in the draft, but of course I would do this in stages on the actual article. quequotion (talk) 03:41, 16 January 2019 (UTC)Reply[reply]
"update its version accordingly and regenerate .SRCINFO; otherwise the AUR will not show updated version numbers" -- this sort of sounds like failure to show updated version numbers is also the issue with not updating the PKGBUILD version. I guess this is not an issue if people think that, but it's awkward wording nevertheless. -- Eschwartz (talk) 04:11, 16 January 2019 (UTC)Reply[reply]
Once again, thank you for the feedback. I thought of a lot of other ways to word this, but I kept coming around to the best solution being to delete this line and let users read this stuff on the PKGBUILD and .SRCINFO pages. Since we're not doing that, my compromise is to reword it as a positive course of action (rather than a warning) and try to be slightly more informative as well (version is not the only thing that may need updating in .SRCINFO) quequotion (talk) 14:22, 19 January 2019 (UTC)Reply[reply]

Current: Publishing new package content

Warning: Your commits will be authored with your global Git name and email address. It is very difficult to change commits after pushing them (FS#45425). If you want to push to the AUR under different credentials, you can change them per package with git config user.name "..." and git config user.email "...".

When releasing a new version of the packaged software,

Comment: To be technically correct, only pkgver should be updated when releasing a new version of the packaged software and pkgrel should be updated when releasing a new version of the PKGBUILD. This is documented on the PKGBUILD page, so I'd rather remove this than be more specific here.

update the pkgver or pkgrel variables

Comment: I'm tempted to link to PKGBUILD#Version here instead, so as not to ignore epoch (even if it should only rarely be used), and to encourage users to thoroughly read these sections on the PKGBUILD page.

to notify all users that an upgrade is needed.

Comment:

The AUR does not send notifications out; users have to check for updates.

That sounds needlessly semantic since users checking for updates will be notified by the fact that the pkgver/pkgrel has been updated, which was how I understood the wiki anyway. -- Eschwartz (talk) 18:49, 6 January 2019 (UTC)Reply[reply]
I disagree, but more importantly its redundant with "otherwise the AUR will not show updated version numbers". The statements about updating pkgver/pkgrel and regenerating .SRCINFO can be merged, and removing a technical inaccuracy while reducing redundancy seems like a good idea to me. quequotion (talk) 19:36, 6 January 2019 (UTC)Reply[reply]
Then that's a much better rationale (although I still don't see it as a technical inaccuracy) and should have been specified in the first place. I'm not sure why it needs to be repeated in a new paragraph, maybe to highlight the need? If so, could it be reworded to only mention this in the second paragraph? Kynikos, what was your motivation for that specific wording? -- Eschwartz (talk) 20:00, 6 January 2019 (UTC)Reply[reply]

Do not update

Comment:

I don't feel comfortable explicitly telling people not to update for any particular reason. As I said, it is convenient that this is optional, but if people want to update pkgrel to fix a typo, that's fine too. I worry saying "Do not..." here will lead to someone spending too much time wondering if the changes they've made to their package are worth an update or not, and/or not updating when it would be advisable to do so. Rather than specify a policy, I think it's better to let users figure out they can do this on their own.

We specifically added this by request in #Current: Uploading packages and I agree with the rationale there. -- Eschwartz (talk) 18:46, 6 January 2019 (UTC)Reply[reply]
If it is necessary to mention this at all, it would be better to say "It is not necessary to update", except that it is long. I feel "Do not" makes a policy statement we could come to regret. I should add, I was surprised to see this particular advice on the page at all; my interpretation of the discussion was that Kynikos's priority was to have a suggestion to update pkgver and pkgrel on the page, and that my bringing up that this can be avoided for convenience was an aside and not meant to shape policy. Ergo, I have relegated that point to a Template:Tip where I think it belongs. quequotion (talk) 17:05, 11 January 2019 (UTC)Reply[reply]

those values if only minor changes to the PKGBUILD such as the correction of a typo are being published.

Be sure to regenerate .SRCINFO whenever PKGBUILD metadata changes, such as pkgver() updates; otherwise the AUR will not show updated version numbers.

Comment: I think these can be combined and would be better placed after the following, which describes process for both the initial upload and subsequent updates.

To upload or update a package, add at least PKGBUILD and .SRCINFO, then any additional new or modified helper files (such as .install files or local source files such as patches), commit with a meaningful commit message, and finally push the changes to the AUR.

Comment:

I might consider agreeing on a more schematic wording as a compromise, to clarify which are supposed to be the separate commands to run; for example:

To upload a new or updated package:
  1. Regenerate .SRCINFO;
  2. Add at least PKGBUILD and .SRCINFO to the repository index;
  3. Commit with a meaningful commit message;
  4. Push the changes to the AUR.
-- Kynikos (talk) 18:26, 7 December 2018 (UTC)Reply[reply]

For example:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push
Note: If .SRCINFO was not included in your first commit, add it by rebasing with --root or filtering the tree so the AUR will permit your initial push.
Tip: To keep the working directory and commits as clean as possible, create a .gitignore that excludes all files and force-add files as needed.

Proposal: Publishing new package content

Warning: Your commits will be authored with your global Git name and email address. It is very difficult to change commits after pushing them (FS#45425). If you want to push to the AUR under different credentials, you can change them per package with git config user.name "..." and git config user.email "...".

To upload or update a package, add at least PKGBUILD and .SRCINFO, then any additional new or modified helper files (such as .install files or local source files such as patches), commit with a meaningful commit message, and finally push the changes to the AUR.

Tip: To keep the working directory and commits as clean as possible, create a .gitignore that excludes all files and force-add files as needed.
Note:
  • When updating a package, except for very minor changes (such as fixing a typo) that would not require re-installation of the package, be sure to update its version accordingly.
  • Remember to regenerate .SRCINFO on every update to the PKGBUILD; otherwise the AUR will not show updated version numbers or other metadata changes.

For example:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "useful commit message"
$ git push
Note: If .SRCINFO was not included in your first commit, add it by rebasing with --root or filtering the tree so the AUR will permit your initial push.