[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