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:
> =====
> 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:
> pugixml-1.8
> and presumably should have been
> pugixml-1.8.1
> 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.

Reply via email to