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
