Talk:Arch User Repository: Difference between revisions
Quequotion (talk | contribs) (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 | {{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)
Markdown Syntax
Should there be a Markdown syntax section? [3][4] All those seem to work: link —Dettalk 16:24, 5 December 2017 (UTC)
- 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)
- Well, there's a preliminary section: Arch_User_Repository#Comment_syntax. --Dettalk 22:28, 13 December 2017 (UTC)
- [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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- If there are no objections, I plan to merge this proposal soon. quequotion (talk) 16:36, 15 January 2019 (UTC)
- 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)
- 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.IfSince 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)
- 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
- 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)
- If there are no objections, I plan to merge this proposal soon. quequotion (talk) 16:36, 15 January 2019 (UTC)
- 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)
- "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)
- 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)
- 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
- "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)
Current: Publishing new package content
git config user.name "..."
and git config user.email "..."
.When releasing a new version of the packaged software,
update the pkgver or pkgrel variables
to notify all users that an upgrade is needed.
Do not update
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.
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.
For example:
$ makepkg --printsrcinfo > .SRCINFO $ git add PKGBUILD .SRCINFO $ git commit -m "useful commit message" $ git push
.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..gitignore
that excludes all files and force-add files as needed.Proposal: Publishing new package content
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.
.gitignore
that excludes all files and force-add files as needed.- 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
.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.