Pacaur and depot-tools

[DonOregano]

This is really more of a support request than a bug report, so feel free to close the issue in anger if that is completely wrong :-)

I'm maintaining an AUR package (https://aur.archlinux.org/packages/google-breakpad-git/) that uses googles depot-tools to get hold of the source code. But since I have to use this tool to fetch the source I can't be a "real" git package, which causes issues with SRCINFO. For example, if you try to build the current version of the package using pacaur you will get SRCINFO version mismatches, even though what is in the repo is correct (I believe).

I'm a bit of a noob regarding AUR packages, so it may be something obvious that I'm doing wrong. I would be very grateful for some hints about how to solve this, since I'm getting lots of reports about my package being broken...

[rmarquis]

See https://wiki.archlinux.org/index.php/VCS_package_guidelines.

[vith]

What part of the VCS package guidelines are being violated here?

I can't figure it out either (this package still fails to install).

The .SRCINFO and PKGBUILD versions are in sync on AUR; makepkg bumps only the latter apparently.

I was going to try renaming the package to not end with -git to see if that's why pacaur gets confused but I can't find any way to get pacaur to build from a local directory for testing.

Only other idea I have is to run mksrcinfo automatically in the PKGBUILD but I don't know if that's a good idea and it doesn't seem to be what you were implying by linking that wiki page.

makepkg --packagelist does return the new version numbers though, which seems to be what pacaur looks at? But it appears it only looks before building and not after, so I don't know how it could ever work. I must be looking at the wrong spot.

[rmarquis]

Use regular git instead of depot-tools for fetching source...

[DonOregano]

Ugh, but that seems pretty difficult. And I'm not even sure all the dependencies (that are fetched by depot tools) are git repos. Some may be using SVN and other tools.

[lindhe]

Is this what breaks Telegram compilation for me??

[Avinash-Bhat]

This doesn't seems to be an issue with git, it happens with the yadm package. It fails with the message

package(s) failed to install. Check .SRCINFO for mismatching data with PKGBUILD.

whereas yaourt or manually installing with makepkg -i doesn't cause issues.

Note that pacaur exits with normal exit code, instead of an abnormal exit.

[rmarquis]

@Avinash-Bhat The yadm package is actually a git package, but does not follow the convention of using -git extension in its name. As a result, the specific commands required for the VCS packages aren't applied (see #612 for a similar issue). See #364 for the reason makepkg -i cannot be used without breaking a whole other set of packages.

The exit code for .SRCINFO mismatch has been fixed in 623710da5bb4da2b6aa3584941823284c998ed18.

[Avinash-Bhat]

@rmarquis great to know that it is not an issue with pacaur, I changed the PKGBUILD, with the -git prefix in the name (and committed it locally so that it'd reflect). But the error has not yet changed. Actually the SRCINFO was generated using makepkg --printsrcinfo > .SRCINFO just to make it shut up about it :-)

Is there any other way to see what is happening? when running pacaur using the -x bash option, the last line has changed from

+ [[ -n '' ]]
+ [[ -n '' ]]

to

+ [[ -n '' ]]
+ [[ -n yadm ]]

Any idea what causes this?

[rmarquis]

@Avinash-Bhat Pacaur uses the online RPC interface to retrieve AUR info, so it won't work until you upload it in the AUR. Another popular package that is broken the same way is packer.

I could technically workaround that issue by reverting the upstream patch and shipping a modified makepkg with pacaur (as bauerbill does), but this is something that is plain ugly and I don't want to workaround it that way. Modifying the global design to use an intermediary local repo could be another possibility (see #643), but this is still a workaround for something that should eventually be fixed by the maintainer.