[macports-ports] branch master updated: cpan2port: fetch from github, use perl5.26

[Mojca Miklavec]

On 28 February 2018 at 16:23, Ryan Schmidt wrote:
> On Feb 28, 2018, at 08:13, Mojca Miklavec wrote:
>
>> +set git_shasum      4207b22
>> +set git_date        20180228
>> +
>> +github.setup        macports macports-contrib ${git_shasum}
>
> I'd like to discourage the practice of ports defining their own variables for things which already exist as standard variables. You're meant to specify the version or git committish as the third argument to github.setup, e.g.:
>
> github.setup        macports macports-contrib 4207b227800b8ce6ba7db02641a1b1a66b3218de
>
> It doesn't look like you need to refer to this value elsewhere in the port, but if you did, you would be able to do so using the standard MacPorts variable ${git.branch}.

OK. I'll fix this. I planned to use it in the version, but then the
version would be too long.

> I guess there's a difference of opinion about whether the committish should be abbreviated or not. I see no reason to abbreviate it, and some reason not to abbreviate it: The github portgroup is programmed to recognize version strings composed of 9 or more hexadecimal characters as a git committish, so a git committish should not be abbreviated to fewer than 9 characters. (The portgroup currently restricts this detection to 9 or more characters so as not to misidentify YYYYMMDD version numbers as a committish. This could possibly be improved to allow shorter hex strings to be recognized, provided they are not composed entirely of decimal digits.)

OK, I can use the full string.

> It's pretty crappy that we have to fetch the entire contrib repository just to get one of its subdirectories. I guess contrib is still pretty small so it's not a huge problem yet.

I could not agree more, but I saw no easy and sane way to do it
otherwise. I could perhaps fetch these two files separately:
    https://raw.githubusercontent.com/macports/macports-contrib/4207b227800b8ce6ba7db02641a1b1a66b3218de/cpan2port/cpan2port
    https://raw.githubusercontent.com/macports/macports-contrib/4207b227800b8ce6ba7db02641a1b1a66b3218de/cpan2port/COPYING
even though this solution does not really scale well.

> But if this is how we're going to handle it, let's at least use "dist_subdir macports-contrib" so that all the ports for contrib software fetch to the same place, and there's at least a chance that two contrib ports might use the same git committish and thus the same distfile.

Let me know if you have a better idea, else I'll indeed fetch to
macports-contrib.


>>  destroot {
>> -    xinstall -m 755 ${worksrcpath}/${name} ${destroot}${prefix}/bin/${name}
>> +    xinstall -m 755 ${worksrcpath}/${name}/${name} ${destroot}${prefix}/bin/${name}
>>      xinstall -d ${destroot}${prefix}/share/doc/${name}
>> -    xinstall -m 644 ${worksrcpath}/COPYING ${destroot}${prefix}/share/doc/${name}/COPYING
>> +    xinstall -m 644 ${worksrcpath}/${name}/COPYING ${destroot}${prefix}/share/doc/${name}/COPYING
>>  }
>>
>
> Rather than replacing every occurrence of "${worksrcpath}" in the Portfile with "${worksrcpath}/${name}", isn't it better to set "worksrcdir ${worksrcdir}/${name}"?

Thanks, it didn't occur to me that I could use this recursively.

>> -# TODO: check the latest svn revision of the file
>> +# TODO: check the latest revision of the file
>>  livecheck.type      none
>
> The livecheck would be fixed by removing this line, and using the full git committish.

I guess it would not. In my experience one simply gets alphabetic
comparison of shasums which is pretty useless. I didn't test it here.

I guess that many of the problems that surfaced in this commit (I
would have updated the port much earlier and didn't do it exactly for
the numerous "problems" and questions which bothered me) would vanish
if we created a standalone repository for cpan2port and made proper
versioned tags for it etc.

Mojca