github port group

[Ryan Schmidt]

Sorry, I missed your latest comments in the ticket.


On Apr 21, 2012, at 20:30, Sean Farley wrote:

>> I think the git.branch can be used interchangeably: it's both a tag or a hash.
> 
> You mean having code that would look the following?
> 
> github.setup        williamh dotconf 1.3 v

If the author is williamh, and the project name is dotconf, and the version number is 1.3, and the tag prefix is v, then yes.

> github.branch       6382711e9b0060bbd0408df512e48b2ce9cdb3be #needs to
> be the whole hash so livecheck will work

There's no such variable. Just use git.branch, same as if you weren't using the github portgroup.

> Which then will use the zip / tarball download by default

I didn't think github had automated downloads available except for tags.

If github has automated downloads available for any tag/branch as well, then we would need to verify that they always have the same checksums, and are not generated on the fly. I'm pretty sure that bitbucket, for example, generates them on the fly, meaning different users requesting them at different times will get different checksums, which means they're not suitable for use as master_sites in MacPorts.


>> I think setting livecheck.url to the RSS file and livecheck.regex to an appropriate pattern should suffice.
> 
> One of my goals for this patch was to do this automatically (by
> default) so that each port didn't have to monkey around with regexes.

Sure.


> The current patch has livecheck logic like:
> 
> if github.version.length = 40, then assume it's a "devel" port and
> only check the rss feed for the first item's commit hash

As I explained in the ticket already, the decision of whether to use the rss feed for livecheck should be based on whether git.branch has been set, not on the length of the version. It does not make sense to set the version to the git hash for the reasons I explained in the ticket.


> Alternatively, the port group could use something like:
> 
> github.date 20120622
> 
> but then a new commit on the same day would fail to livecheck
> (probably not a big deal).

That's a possibility.


> Unfortunately, this wouldn't work (unless
> someone can come up with a fancy regex?) for a bitbucket port group
> because the rss / atom date is given as "Fri, 27 Jan 2012" as seen
> here:
> 
> https://bitbucket.org/durin42/hg-git/atom
> 
> I wanted to try to keep the bitbucket and github port groups as
> similar as possible.

I didn't know that we had, or that anyone was working on, a bitbucket portgroup. Is there a ticket already?


>> I think it's acceptable as long as its not HEAD and it works for the maintainer. It could be an incrementing number, it can be a date, it can be some version/date combo like you suggest. For PSPP-devel I use ${version}-g${git.branch}.
>> 
>>> Open question: what to do about projects that never version? Assign a
>>> dummy version? Stick with just date?
>> 
>> Up to the maintainer. No harm in doing your suggestion for 3 above.
> 
> So, how about (as for having a similar default for both github and bitbucket):
> 
> If version exists (how to check, though?): ${version}-${date}
> else: ${date}

What do you mean, "if version exists"? The third parameter of github.setup, which is currently not optional, is the version number you want to assign to this port.