[build2] Forcibly using new revision
Boris Kolpackov
boris at codesynthesis.com
Tue Oct 9 13:45:41 UTC 2018
Per Edin <per.edin at sequence-point.se> writes:
> I created a build2 wrapper library for libasio*, similar to how it's done
> for libpq. I tagged the first release as v1.12.0 but didn't realize until
> later when I tried to use the library that it's an error to exclude
> "license:" from manifest.
>
> Hence I added "license:" to manifest and bumped the version numebr, tagged
> that commit as v1.12.0+1 and updated the manifest of my program using
> libasio to use v1.12.0+1 explicitly in its manifest file.
This should generally work. However:
> But no luck. I can't get bdep to check out the new tag. It still
> attempts to checkout v1.12.0 and bails with the message "error:
> no project license specified".
What happens here is bpkg tries to examine the v1.12.0 tag as a
package (because it is part of the default set) and fails to parse
its manifest. Here is an illustration:
$ bpkg rep-info https://github.com/sequence-point/extpack-libasio.git
/tmp/bpkg-17003-0/64908ae64371/manifest:7:1: error: no project license specified
info: package in repository https://github.com/sequence-point/extpack-libasio.git tags/v1.12.0
In other words, if v1.12.0 were a valid package, you would have
gotten the expected behavior.
The way I would resolve this is by deleting the v1.12.0 tag (since
it is not usable anyway).
In fact, I would probably go further and change the v1.12.0 tag
to point to the v1.12.0+1 commit. Since a +N package is always
assumed to be "better", I don't see a reason to keep the previous
tag. But some might feel this is going a bit too far.
More information about the users
mailing list