You are not logged in.
How to make a PKGBUILD which always use latest tag from given branch? I want it to handle stable versions of my projects.
Last edited by rilian-la-te (2018-08-24 21:47:56)
Offline
Offline
Thanks)
Offline
Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.
Offline
JWR, that will just construct a version number using the most recent tag in it.
rilian-la-te, if you want to use the code from a tagged commit, specify the tag in the source array:
source=('git+https://your.domain.tld/subdir/project.git#tag=sometag')
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I want to use a code from most recent git tag.
Offline
That's not really an option - at least not without some ugly acrobatics in the PKGBUILD. Regardless it is not a good option. What would the name of such a package be?
You can make a pkgname-git that pulls the most recent code, and/or a pkgname that pulls a stable tag. In the latter case, the tag should be in pkgver. This makes it easy to update the PKGBUILD as you'd just increment pkgver and you'd be set. But this is still a static package that builds from a set source.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
If you are the owner of the git repository, then you could publish a branch that is on the same commit as the most recent tag.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
I do not like an idea of updating all PKGBUILDs with a release. I want to create a package which pulls latest semi-stable tag from git.
Offline
I want a pony.
If you add the acrobatics needed to do this to the PKGBUILD, the result will be a PKGBUILD that pulls a static source, but yet can't have a checksum, and cant be represented properly on the AUR web interface, and is - in general - less convenient for all of the users.
Alll this just so you don't have to periodically push a minimally revised PKGBUILD to the AUR?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Yes, because I am so lazy to push tag on GitLab, then write a release notes, then wait for tarballs to build, and then push new PKGBUILD (and count checksum).
And I do not mention periodically mirroring to GitHub)
I want black magic to have an AUR package with latest semi-stable release always)
Last edited by rilian-la-te (2018-08-24 21:47:01)
Offline
I didn't intend to imply you are lazy. Anyone who contributes to arch with software that can be in the AUR, AUR packages, etc, are all highly valued. Thank you for what you are doing.
I'm just having trouble understanding why you would be averse to a very trivial addition to what you are already doing that would be a good benefit to all of the users of your software in addition to being in line with AUR procedures and precedents.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Because I do not use semi-stable package myself, I always use a latest master (maybe ninja installed), so, my pacman shows me a *-git packages for this. And I am happy with this.
And magic with checksums and keys - I do not like it) Git cloning can be assumed as safe as check SHA1 checksum, so, losing a checksum is a no-brainer for me.
Offline
There is absolutely no reason you cannot use the git protocol for downloading a pinned tag. So go right ahead if you want to do that.
Nevertheless, packages that download stable versions are by definition not *-git packages which dynamically pull new versions on their own.
Either you use pinned sources (whether that is a checksummed tarball or a git repository using an url fragment to check out a specific tag/commit, is irrelevant), *or* you use a -git package that checks out the latest commit on a given branch.
It's pretty simple to update that pkgver= in the stable PKGBUILD, via a deploy hook as part of your software build if that's what you want. Or, you could just do it at the same time you push the tag to gitlab -- not sure why you need to wait for tarballs to build if you use git sources.
...
It is *not* possible to express "check out whichever tag is the latest tag" in a PKGBUILD source array. Given the prepare() function can be whatever arbitrary bash scripting you want, I guess you could do, as Trilby put it, "ugly acrobatics in the PKGBUILD. Regardless it is not a good option". But I feel like this would be against the rules of submission for the AUR, so it would have to be a personal PKGBUILD only.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Assuming a -git named package, why not use prepare() to checkout the desired tag?
Below, I checkout the latest non-alpha tag:
# Get the tag of the commit to use
# Separated out to allow for `makepkg -e` not running prepare()
_get_tag() {
_tag=$(git tag --list | grep '^v' | grep -v alpha | tail -n1)
echo "Selected git tag: $_tag" >&2 # To STDERR as called from pkgver()
}
prepare() {
cd "$srcdir/$_pkgname"
_get_tag
git reset --hard "$_tag"
}
pkgver() {
cd "$srcdir/$_pkgname"
[[ -z ${_tag-} ]] && _get_tag
# Example: v2.1.0-beta-3 -> 2.1.0.beta.r3
# Version specification: https://github.com/robert7/nixnote2/issues/28
echo "$_tag" | sed -E 's/^v//;s/-?([0-9]+)$/.r\1/;s/-/./'
}
Last edited by Ataraxy (2018-10-05 07:35:44)
Offline
Assuming a -git named package, why not use prepare() to checkout the desired tag?
Non git-named. Git named always get latest revision)
Offline
Assuming a -git named package, why not use prepare() to checkout the desired tag?
Let's fix that sentence.
"Assuming a -git named package, why not use prepare() to do the thing we already mentioned in this thread, but asserted is a bad idea and additionally breaks the rules of submission for the Arch User Repository?"
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
I just want to create package which can upgrade its version without my attempt, and is not -git package (it can be a -git, but how I can made a 2 -git packages for same software)?
If 2 -git package is possible, then yes, let's made it -git.
Also latest tag now is not mandatory - If it is possible, we can check gitlab and download latest tarballs instead.
But idea stays the same - have PKGBUILD for latest stable version and do not care about version number.
Offline
And not putting it in the AUR, right?
Offline
Is it so difficult to create a script that checks the release on gitlab, fills in a PKGBUILD template, tries to build it in a clean chroot, creates SRCINFO and then commits and pushes to the aur git on success?
Last edited by progandy (2018-10-05 23:48:23)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Online
It is possible, yes. But I do not think than AUR will happily accept such packages from GitLab runners.
Offline
Either you will follow the AUR standards or you wont, that's really up to you (though your package may be deleted if you chose the latter). In either case continuing with a question that has been asked and answered half a dozen times in this thread will not result in a new answer.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It is possible, yes. But I do not think than AUR will happily accept such packages from GitLab runners.
Why not?
If your gitlab runner makes sure the package builds successfully, I see no problem here. In fact, that would make your automated package updates *better* than some packages I've seen.
But you do need to be careful. I've seen AUR packages maintained by someone's gross bot, which somehow managed to *delete* the checksum array from the PKGBUILD, and not only did the maintainer not respond to AUR comments, he pushed a second update two months later with the same problem. This would have been trivially detected by running makepkg --verifysource or actually trying to build the package, both of which can be done in a bot...
At the end of the day, we don't really care how you maintain your package, as long as you don't do anything dangerous or illegal, and as long as you actually pay attention if a user leaves a comment on the package details page saying "the package is broken, please fix it".
In another case, an open-source on github had an automated task to upload an AUR package repacking their prebuilt binaries. The only reason this wasn't perfectly okay is because there was a discussion that resulted in the package being deleted and moved to a -bin package... because it did not build from source... and then the bot went ahead and re-uploaded it because no one actually paid attention to what it did.
If you want to see one case of it being done right, see the keybase-bin package, defined here: https://github.com/keybase/client/tree/ … linux/arch
It's updated quite often by their CI, but at least one keybase developer is extremely available and is quite fast to respond to comments on the package details, and ensure everything continues to run smoothly and fix it if it doesn't.
Last edited by eschwartz (2018-10-07 01:37:00)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Ataraxy wrote:Assuming a -git named package, why not use prepare() to checkout the desired tag?
Let's fix that sentence.
"Assuming a -git named package, why not use prepare() to do the thing we already mentioned in this thread, but asserted is a bad idea and additionally breaks the rules of submission for the Arch User Repository?"
I've read all of the above and the Rules for packages at both:
I want a pony.
https://www.archlinux.org/packages/comm … y/ponysay/
Here is my understanding of the customs for packages (please correct me if needed).
There are two types of packages:
-{git,svn,hg,...} packages
Are expected to build from the latest commit of the default branch of the remote repository
Do not require checksums:
sha256sums=('SKIP')
Pinned packages
Are expected to include a fixed version number
Require checksums
It is *not* possible to express "check out whichever tag is the latest tag" in a PKGBUILD source array. Given the prepare() function can be whatever arbitrary bash scripting you want, I guess you could do, as Trilby put it, "ugly acrobatics in the PKGBUILD. Regardless it is not a good option". But I feel like this would be against the rules of submission for the AUR, so it would have to be a personal PKGBUILD only.
To me, it seems the -{git,svn,hg,...} is a convention. A well-followed convention with clearly defined expectations, which I don't intend break.
What if we were to find an new appropriate -extension to denote a package which:
Determines the tag to build (eg non-alpha releases)
Determines the pkgver from the tag
Does not require checksums
I can't see it being against the rules I linked to above. I'm happy to not break the convention of -git extensions. Why not create a new convention? How about this code:
_branch=$(get_tag_or_branch_to_build)
source=("project_name::git+http://project_url#branch=${_branch}")
I'd suggest -dynamic or -dyn for the package name extension.
If you add the acrobatics needed to do this to the PKGBUILD, the result will be a PKGBUILD that pulls a static source, but yet can't have a checksum, and cant be represented properly on the AUR web interface, and is - in general - less convenient for all of the users.
What does "represented properly" in the AUR mean? Why couldn't a dynamic package be represented using the same fields as a -git package? What would be lost or misrepresented, given an appropriate extension and description?
Alll this just so you don't have to periodically push a minimally revised PKGBUILD to the AUR?
Laziness is a virtue to which I also aspire.
Offline
I'd suggest -dynamic or -dyn for the package name extension.
It will be good, but I want such -dyn packages to allow always cally the latest tag (or latest from selected tags), not just specific tag.
Offline