Evaluation of my packages

ewaller · 2018-07-20 20:17:55

A while back, escharwtz provided critique of my AUR packages and much of what was said about git tags, and lack thereof. And, it also sailed over my head.

The original critique https://bbs.archlinux.org/viewtopic.php … 8#p1796698

I have been off learning about git tags and wanted someone to see if I understood. Could someone take a look at the following and see I have understood what I set out to learn? I started with the dup.py package:
https://aur.archlinux.org/packages/dup.py/

Once I am sure I am back on target, I will update the others.

Thanks.

Trilby · 2018-07-20 21:01:46

While I cannot speak for Eli, I interpretted the comment about tags to refer to two different things. First, there was an apparent lack of tagged releases in your source repo. Using tagged releases is good, but not really necessary (I don't/didn't use them in my git repos). They can make version numbers look a little nicer. I suspect there may be some who would passionately argue that this is important - but no one should claim it is necessary, nor is not having tags 'wrong'.

However, the second meaning I inferred from the critique was that you were cloning from git master, but the package name does not have the appropriate -git suffix. The package name should be 'dup.py-git' or you should clone from a fixed tag/hash/whatever. Using a dynamic VCS source, you should (read 'must') use an appropriate suffix for the package name. Not doing so is 'wrong' per AUR packaging guidelines.

WorMzy · 2018-07-20 21:03:48

If you're going to track the head of a branch, then you should rename the package to add the -git suffix (change the pkgname, re-upload, and file a merge request)

If you want to build from the tagged commit, then you don't need a pkgver function, you just need to specify the tag name in the source declaration.

See

man PKGBUILD | less -p "USING VCS SOURCES"

and/or https://wiki.archlinux.org/index.php/VC … guidelines

EDIT: Beaten by Trilby

Last edited by WorMzy (2018-07-20 21:04:52)

ewaller · 2018-07-20 21:11:37

Got it. This package should be *-git. As it is not, I should be building against a specific commit. How does one do that? do you use git checkout in build() ?

Or is that what fragment is for?

Last edited by ewaller (2018-07-20 21:13:32)

loqs · 2018-07-20 21:22:57

#tag=$tag
#commit=$commit

Alad · 2018-07-20 21:41:37

Most obvious one: quote pkgdir

ewaller · 2018-07-20 22:49:23

Alad wrote:

Most obvious one: quote pkgdir

Defensive programming in Bash still hurts my brain. We are talking the two instances in install in package(), right?

Updated AUR <edit>for dup.py

Also, I have pushed a cleaned up version of hpfall, so feel free to comment on that as well. </edit>

Last edited by ewaller (2018-07-20 23:30:39)

ewaller · 2018-07-20 23:37:13

loqs wrote:

#tag=$tag
#commit=$commit

are those not comments ? Can someone point me at a good example of something built from a git repo that does not build at master?

Trilby · 2018-07-21 00:13:10

I don't know of any examples off hand, but they are not comments, they are meant to be url fragment identifiers

source=('git+https://your.domain.tld/subdir/project.git#tag=sometag')

jasonwryan · 2018-07-21 00:17:34

source=(git://git.suckless.org/dmenu#commit=5ed5e90bf)

loqs · 2018-07-21 00:25:31

_tag=v4.18-rc5
source=("git+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#tag=${_tag}?signed"

ewaller · 2018-07-21 00:29:41

Copy that. Thanks gents. I clearly need to go do some more reading. I presume those urls are passed straight to git, and git hands back a pruned tree?

Edit: IOW, this is not makepkg PFM

Last edited by ewaller (2018-07-21 00:30:49)

Trilby · 2018-07-21 00:35:26

~~Correct, as far as makepkg is concerned, it's just part of the source url, just like it was a fragment identifier in any other url.~~

EDIT: loqs post below would suggest I actually have it completely backwards ... I need to test with git directly. EDIT 2: yup, I was completely wrong, and am completely surprised.

Last edited by Trilby (2018-07-21 00:40:21)

loqs · 2018-07-21 00:36:56

From /usr/share/makepkg/source/git.sh

git checkout --force --no-track -B makepkg $ref

ewaller · 2018-07-21 01:03:27

Okay, so the mechanism is git checkout, but I don't implement it in the PKGBUILD. Using #tag=xyzzy, we grab the entire git repository, then if it is not looking for "origin/HEAD", makepkg subsequently checks out that commit which was passed in and fails unceremoniously when it does not exist.

It is makepkg PFM

Last edited by ewaller (2018-07-21 01:03:53)

eschwartz · 2018-07-22 05:58:26

As was mentioned in this thread, my intent was that you should make a choice to either do a -git package which can track master, or do a stable release package, in which case it should pin the sources used.

Since your PKGBUILD declared itself to be version 1.0, it would seem logical to tag a commit as 1.0 and just use that.
That being said, it is of course perfectly fine to pin a commit hash instead, though in that case I'd expect a pkgver value of e.g. "r4" representing the four commits in that repo.

Since you likely don't expect new versions of code you have not needed to update in nearly two years, I would not bother with the administrivium of creating a new -git package and getting the current package merged and renamed. It's probably sufficient to just use makepkg's internal specifier to pin a commit hash or newly-tagged release.

Note that your current tag is referencing the first commit, so you probably don't want to pin that tag due to it resulting in these commits not being available to people building this: https://github.com/ewwaller/dup.py/compare/1.0...master. However you could of course pin commit 2b6b18ce5d0f53cbe4f0b348400328b8dfe1e80f and just hardcode the pkgver=1.0.r3.g2b6b18c which is currently there.

Side note on pkgver() functions in packages with pinned commits: they're almost but not quite completely useless. I say almost, because they can be convenient for calculating the new pkgver when the maintainer updates the pinned commit, despite essentially doing nothing in between standard runs. See for example their use in most/all of the PKGBUILDs for the gnome packages in [extra].

ewaller wrote:

Okay, so the mechanism is git checkout, but I don't implement it in the PKGBUILD. Using #tag=xyzzy, we grab the entire git repository, then if it is not looking for "origin/HEAD", makepkg subsequently checks out that commit which was passed in and fails unceremoniously when it does not exist.
It is makepkg PFM

s/commit/commit-or-tag-or-branch/ but yes

ewaller · 2018-07-22 14:32:49

Thanks Eli. I am still reading up on how all this works. Last night I had read the source for makepkg, including the files that are sourced down under /usr/share/makepkg/. Interesting read.

I was a bit surprised when it appeared that makepkg actually changes the PKGBUILD in response to the result of pkgver(); so much so that I had to try it. I was really not expecting the pkgver variable and the pkgrel of the input file to change. The documentation says

       pkgver
           The version of the software as released from the author (e.g., 2.7.1). The variable is not allowed to
           contain colons, forward slashes, hyphens or whitespace.

           The pkgver variable can be automatically updated by providing a pkgver() function in the PKGBUILD that
           outputs the new package version. This is run after downloading and extracting the sources and running
           the prepare() function (if present), so it can use those files in determining the new pkgver. This is
           most useful when used with sources from version control systems (see below).

       pkgrel
           This is the release number specific to the Arch Linux release. This allows package maintainers to make
           updates to the package’s configure flags, for example. This is typically set to 1 for each new
           upstream software release and incremented for intermediate PKGBUILD updates. The variable is not
           allowed to contain hyphens.

I took that to mean that the package file could have a different name; not that the PKGBUILD itself would be updated to reflect the as built. And there is no mention of the pkgver being automatically reset to 1 when pkgver() updates the pkgver variable.

My plan for this file, before having read your response this morning, was to not change it to a -git (as you suggest), but I was going to nail down the most recent commit in the pkgver variable and include the fragment in the source url. I wrote all of that last night when I got sidetracked evaluating the effects of pkgver().

When I first wrote these, I had a nagging feeling I was willfully ignoring the need to specify a branch. Thank you (all) for your feedback.

eschwartz · 2018-07-22 16:11:26

Not specifying a branch, has the effect of using whichever branch the upstream repository has configured as the default (i.e. what you see when you do a plain git clone).

And yes, makepkg will (by design) update the PKGBUILD itself with the results of running the pkgver() function. It's assumed to be more useful than trying to update this by hand separately from running makepkg

e.g. if you update the PKGBUILD due to new upstream commits modifying the build process, this should likely be indicated in the version specifier too.

ewaller wrote:

Thanks Eli. I am still reading up on how all this works. Last night I had read the source for makepkg, including the files that are sourced down under /usr/share/makepkg/. Interesting read.

Excellent, you're now more qualified than most to help improve it with patches.

Arch Linux

#1 2018-07-20 20:17:55

Evaluation of my packages

#2 2018-07-20 21:01:46

Re: Evaluation of my packages

#3 2018-07-20 21:03:48

Re: Evaluation of my packages

#4 2018-07-20 21:11:37

Re: Evaluation of my packages

#5 2018-07-20 21:22:57

Re: Evaluation of my packages

#6 2018-07-20 21:41:37

Re: Evaluation of my packages

#7 2018-07-20 22:49:23

Re: Evaluation of my packages

#8 2018-07-20 23:37:13

Re: Evaluation of my packages

#9 2018-07-21 00:13:10

Re: Evaluation of my packages

#10 2018-07-21 00:17:34

Re: Evaluation of my packages

#11 2018-07-21 00:25:31

Re: Evaluation of my packages

#12 2018-07-21 00:29:41

Re: Evaluation of my packages

#13 2018-07-21 00:35:26

Re: Evaluation of my packages

#14 2018-07-21 00:36:56

Re: Evaluation of my packages

#15 2018-07-21 01:03:27

Re: Evaluation of my packages

#16 2018-07-22 05:58:26

Re: Evaluation of my packages

#17 2018-07-22 14:32:49

Re: Evaluation of my packages

#18 2018-07-22 16:11:26

Re: Evaluation of my packages

Board footer