aurbuild: allow to skip packages on error

[AladW]

In particular "a package was already built" errors.

[rmarquis]

Or better: check if the package is already available in your cache before starting the build.

[AladW]

Hm, this should be doable with makepkg --packagelist, or did you have something else in mind?

[rmarquis]

Depends on what you want to achieve. If you succeed in compiling the package the first time and put in a local repository (with repose), that error shouldn't even happen I guess.

Otherwise, yes, you can check the build directory content using --packagelist and appending the extension.

[AladW]

Rather than use --packagelist (and possibly add logic to find out the architecture), I've copied makepkg output, and run grep on that. Even with LC_MESSAGES=C set, it's not very nice, but with #17 it's about all I can do.

I'm not sure how using repose would prevent this error though; PKGDEST was set to the local repository pool in 7660f1a (and should match it otherwise), and makepkg checks for built packages there.

[rmarquis]

Shouldn't aurchain ignore the package if it found in the local repository? It shouldn't be seen by aurbuild in the first place, or I am missing something here?

[AladW]

Well, unlike aurqueue (though see #5 - I'm unsure it's a good idea to have the queue file influenced by local packages, if only for later package upgrades), aurchain has no repository check logic. Right now it only relies on RPC results to write the queue file.

That said, maybe it's better to still move this logic elsewhere? (perhaps aurbob)

[rmarquis]

Sorry, I indeed meant aurqueue. Yes, the drawback of using a local repository is that checking update in AUR isn't straightforward anymore (but that's about the only downside I can imagine).
I do feel the issue should be fixed in aurqueue though, as catching the error later in the whole automated process looks more like a dirty workaround than a real fix imho.

Btw, I feel aurbob is a terrible name, but maybe that's just me :)

[AladW]

You're right, another drawback is twiddling thumbs when many packages in the queue are built already (plus piping makepkg through tee messes with provider choices)

As to aurbob, the name was taken from the kids' show ("Working together, we get the job done"), but I'm open to suggestions. ;)

[AladW]

Here's the prototype:

# Update pkgver for VCS sources
makepkg --verifysource --nobuild
mksrcinfo

# No split package support
while read -r key _ val; do
    case "$key" in
        pkgbase) pkgbase=$val ;;
        pkgver)  pkgver=$val  ;;
        pkgrel)  pkgrel=$val  ;;
    esac
done < ./.SRCINFO

# Multiple packages could be queried
fullver=$(expac -S '%v' "$pkgbase")
compare=$(vercmp "$pkgver-$pkgrel" "$fullver")

if ((compare)); then
    msg "$pkgbase: $fullver -> $pkgver-$pkgrel"
    exit 1
else
    msg "$pkgbase does not need updating"
fi

I decided against using --packagelist, as it's 2x as slow as mksrcinfo and
outputs arch values not relevant to the system (note how repose assumes a repo
holds at most one arch per package).

VCS are a bit annoying since you have to update pkgver, here done via makepkg --verifysource.

This and aurbob probably belong to (the renamed) aursync, as git clone/pull,
inspection and upgrades are closely related.

[rmarquis]

@AladW I don't know that show, so I obviously miss the reference. The name if fine if you like it :)
The proto looks good at first sight. Note split package support shouldn't be required here as all PKGBUILD have only one pkgbase, pkgver and pkgrel.

[AladW]

Fair point, though there's some weird cases like libdbusmenu where pkgname differs from pkgbase (see #36). pacsift could work though:

archie@thinkpad /home/aur/libdbusmenu
 % custom
adding libdbusmenu-glib 12.10.3.15.04.20150410.2-2
adding libdbusmenu-gtk3 12.10.3.15.04.20150410.2-2
adding libdbusmenu-gtk2 12.10.3.15.04.20150410.2-2
writing custom.db...
writing custom.files...
archie@thinkpad /home/aur/libdbusmenu
 % sudo pacsync custom
downloading custom.db (502784/502784) 100%
archie@thinkpad /home/aur/libdbusmenu
 % expac -S '%v' libdbusmenu
archie@thinkpad /home/aur/libdbusmenu
 % pacsift -S --base=libdbusmenu
extra/libdbusmenu-qt4
extra/libdbusmenu-qt5
custom/libdbusmenu-glib
custom/libdbusmenu-gtk2
custom/libdbusmenu-gtk3

[AladW]

Bad news: makepkg errors not only when all members of a split package are built, but also when only some are. And of course, it has the same exit code for both. 👿 (a patch was put on the backburner)

Rather than wait on upstream to get their act together, I guess I could write a wrapper which returns a unique exit code for each error/warning. Or just dump the whole idea.

[rmarquis]

@AladW I feel I'm out of the loop here, but does that change anything? A split package is, by definition, a unique build that is then compressed in many subpackages. If the build fails, then no supackages are created.

[AladW]

As I understand it, there's multiple scenarios:

• An updated package is available, skip building (makepkg error: "A package is already built")
• An updated package group is available, skip building (makepkg error: "A package group is already built")
• An updated package group is available, but some packages are missing (makepkg error: "Part of a package group is already built")

Arguably you should pass makepkg -f in the third case. But it's a contrived scenario: as you say, on failure no packages are created, so you'd have to succeed and go and delete some.

Fair enough to let the user get himself out of that hole he digged?

[rmarquis]

Fair enough to let the user get himself out of that hole he digged?

Yeah, absolutely. However, you might want to add some --rebuild flag to bypass the error with makepkg -f. This can be useful in case of soname bump.

[AladW]

Implemented with the above commit, I'll open a new issue for a --rebuild flag.