On Feb 13, 2018, at 12:23, Ken Cunningham wrote:
> On 2018-02-13, at 4:54 AM, Ryan Schmidt wrote:
>>> -github.setup zeux pugixml 1.7 v
>>> -github.tarball_from releases
>>> +github.setup zeux pugixml 1.8.1 v
>> Why no longer use the release download? If a developer goes to the effort of
>> providing a release download, we should prefer to use that.
> Advice requested. Here's why I changed it:
> Using the tarball_from releases with v 1.8.1 generates this error:
> github PortGroup: Error: tarball name is not as expected. This might mean
> that the repository name is different than set in the Portfile. Please review
> and try to correct.
> This occurs presumably because the name of the directory does not match the
> version correctly, and is:
> and presumably should have been
> To fix this, you can force the worksrcdir in the Portfile, and this works:
> github.setup zeux pugixml 1.8.1 v
> github.tarball_from releases
> set worksrcdir pugixml-1.8
> But then you'd have to do an extra step to keep an eye on this going forward
> forever, as someday we'd see 1.9, 1.9.1, etc.
> I know some of you know some fancy regex and might come up with a regex line
> that could fix this, but I don't grok that so well.
> So given the directory name is not going to match the version correctly, I
> decided instead to just make it a normal git tarball, and then it will work
> correctly forever, I figured.
> What do you think?
If the port is working now, I wouldn't change it now. But I would change it at
the next release. If the developer has gone to the effort of providing a
manually-created source code tarball, there must be a good reason, and we
should use that instead of the automatically-generated one. For example, in an
autotools project, the manually-created tarball would contain the configure
script, while the automatically-generated one would not. I realize pugixml is
not an autotools project so that reason does not apply.
The feature of the github portgroup that automatically renames the directory
extracted out of the tarball exists because the automatically-generated
tarballs contain directory names that include the git commit hash, a value that
is not typically in the portfile. I wanted to avoid consumers of the portgroup
having to figure out and specify the git commit hash along with the version
every time such a port is updated.
When changing github.tarball_from away from its default value, the automatic
renaming feature is not longer used.
The related feature that provides a sanity check that the directory name
matches what's specified in the portfile is still happening, perhaps
unnecessarily, though it did point out the error in your portfile, namely that
you didn't set worksrcdir to match the directory name in the tarball. Setting
worksrcdir is the solution.
I wouldn't worry about needing to keep an eye on this "forever". I'd assume the
developer will not make the same mistake in the future, and the worksrcdir
override would disappear with the next release.