AUR has a bug in the way it versions packages. [WORKED AROUND]

deltaecho · 2009-09-13 16:57:23

If you check out my PKGBUILD in the AUR (http://aur.archlinux.org/packages.php?ID=29410), you'll notice its version on the page is "smooth-tasks-pkgver.txt", while the ${pkgver} variable in its PKGBUILD is "wip_2009_09_13". `smooth-tasks-pkgver.txt' is a file the PKGBUILD uses to temporarily store the correct ${pkgver} of the package (not its mercurial revision), which is then used to update the arch package and PKGBUILD.

It was an experiment to see how I could manipulate makepkg's standard versioning scheme to reflect the actual author's package version rather than the mercurial revision, and it works! AUR just seems to have an issue with the way it parses the PKGBUILD.

I figured it would be best to discuss this on the forums before filing an actual bug report.

EDIT: changed the title from "... names packages" to "... versions packages", and edited the post body to correct my original misconception the bug lies in how the AUR names packages, and not versions them.

Last edited by deltaecho (2009-09-13 21:48:06)

Snowman · 2009-09-13 19:19:36

For security reasons, AUR doesn't source PKGBUILD. It only replaces pkgname and pkgver by their literal values. That's why you have this problem.

deltaecho · 2009-09-13 19:43:49

That would make since, but I still think there is a bug somewhere; here is the relative portion of the PKGBUILD:

pkgname=smooth-tasks
pkgver=wip_2009_09_13

Why would the AUR read the ${pkgver} variable as `smooth-tasks-pkgver.txt'? Especially since that file name is generated dynamically (via `${pkgname}-pkgver.txt') and not explicitly specified anywhere in the script? I have another revision of this script that doesn't use the temporary file, which may fix the issue, but I wanted to see if this bug could be located first. Should I go ahead and upload it?

Snowman · 2009-09-13 20:31:59

I've never seen the AUR code so I don't really know how it works. Therefore, I might be wrong. But, in you PKGBUILD, you define pkgver several times. The last definition is in your package function:
pkgver="$(cat ${pkgname}-pkgver.txt)"
It's probably that value that it is used for the info in the AUR interface as there is a '.txt' in the pkgver on the interface. I'm guessing that AUR greps the PKGBUILD for the pkgver and use the last definition.

You could try your other revision but if
pkgver=wip_2009_09_13
is not the last definition of pkgver, then it probably won't work.

You could post on the aur-dev ML to get the input of the people who actually work on the AUR backend code.

tomk · 2009-09-13 20:38:05

deltaecho wrote:

It was an experiment to see how I could manipulate makepkg's standard versioning scheme to reflect the actual author's package version rather than the mercurial revision, and it works!

Interesting experiment, but the fact is you have submitted a PKGBUILD which does not follow the guidelines for SCM builds. The AUR can process any PKGBUILD that complies with the guidelines - unfortunately, yours does not.

deltaecho · 2009-09-13 21:04:37

@Snowman -- I think your right, AUR now lists the ${pkgver} variable as " -n 1 ChangeLog | perl -pe s|^.*"

It makes me sad, but I think I will have to go back to the old, boring, static way of creating PKGBUILDs (unless the AUR devs would like to grep for the 1st instance of the ${pkgver} declaration, which would make me happy again).

deltaecho · 2009-09-13 21:12:43

Ah Check this out:

:<<-'EOF'
pkgver=wip_2009_09_14
EOF

Does the trick nicely!

xduugu · 2009-09-13 22:56:41

I use

[ 1 ] && pkgver=wip_2009_09_14

which works too and seems a little bit easier to me than your solution.

deltaecho · 2009-09-13 23:16:55

I don't understand your logic, what is `[ 1 ]' for? It reminds me of the pieces of code I occasionally come across that look something like:

if (true) { 
    /* Do something here */ 
}

I reckon it makes since to someone, I've just never understood the logic behind such blocks.

The above snippet of code is one way of creating a block comment within Bash scripts, since whatever is located between the `EOF' tags is piped to nowhere (and thus isn't displayed); by placing a block comment at the end of the PKGBUILD containing an explicit ${pkgver} declaration, I am able to dictate to the AUR what the package version should be, and still have the segment of code ignored by `makepkg' when the script is executed.

EDIT: Unless, you mean to use something like `(( 0 ))', which Bash will evaluate to false and thus ignore the proposition. That would indeed make since, but, in my opinion, isn't really any clearer than my implementation.

Last edited by deltaecho (2009-09-13 23:22:10)

Xyne · 2009-09-13 23:26:17

The "[ 1 ] &&" prevents the AUR PKGBUILD parser from detecting the command after it while guaranteeing that it will be executed.

xduugu · 2009-09-13 23:34:59

Oops, I missed the point. I thought you tried to *prevent* AUR from setting the pkgver to wip_2009_09_14, which is what my snippet does.

In your case, you would have to replace the two assignment of pkgver in your functions with [ 1 ] && pkgver=..., because the AUR uses a regex similar to ^\s*\w=.* that to find variables.

I should read more carefully at night, sorry.

deltaecho · 2009-09-13 23:43:57

Got you (that makes a lot more since). My purpose wasn't to have the block of code executed, but rather to have the AUR display the correct ${pkgver}. The author of the Smooth Tasks plasmoid has a different development cycle than most developers; he releases each revision he makes to the mercurial tree to the general public, with the versioning scheme: wip YYYY-MM-DD.

The whole experiment came about when one of the PKGBUILD's consumers stated some of the code I implemented should be taken care of by the PKGBUILD, and was kind enough to point me to the author's bitbucket website where I found the plasmoid's mercurial repository and its ChangeLog. The top line of the ChangeLog contains the most up-to-date package version the author has released, and I've decided to use that package version in the PKGBUILD. The way I've designed it, the PKGBUILD updates itself with the latest version, much the same way `makepkg' does when the '_hgroot' and '_hgrepo' variables are specified, but uses the author's versioning scheme rather than repository's mercurial revision.

xduugu · 2009-09-14 00:07:40

Yeah, got it. Your approach confused me a bit, 'cause all PKGBUILDs I read up to now are doing it the other way round. I usually don't care about the PKGBUILD pkgver as long as it increases in newer PKGBUILDs (so that AUR wrapper can easily recognize updates), only about the pkgver of the resulting package. Therefore, I use an ordinary development PKGBUILD and update the pkgver afterwards which results in a much cleaner PKGBUILD. But in this way, you don't get the "real" pkgver written into the PKGBUILD itself.

An example:

pkgname=smooth-tasks-hg
pkgver=20090914
pkgrel=1

...

build() 
{

...
    [ 1 ] && pkgver=wip_2009_09_14
...
}

...

Last edited by xduugu (2009-09-14 00:10:24)

Arch Linux

#1 2009-09-13 16:57:23

AUR has a bug in the way it versions packages. [WORKED AROUND]

#2 2009-09-13 19:19:36

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#3 2009-09-13 19:43:49

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#4 2009-09-13 20:31:59

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#5 2009-09-13 20:38:05

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#6 2009-09-13 21:04:37

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#7 2009-09-13 21:12:43

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#8 2009-09-13 22:56:41

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#9 2009-09-13 23:16:55

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#10 2009-09-13 23:26:17

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#11 2009-09-13 23:34:59

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#12 2009-09-13 23:43:57

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

#13 2009-09-14 00:07:40

Re: AUR has a bug in the way it versions packages. [WORKED AROUND]

Board footer