pg github: create new 1.1 version

[jasonliu-- (Jason Liu)]

I'm proposing that we create a new github 1.1 PortGroup that lives along-side the existing github 1.0 PortGroup. The only difference is to set the default tarball_from to be archive, so that Portfile writers don't need to add an extra tarball_from archive line to their portfiles just to achieve what should be the default behavior. By making it a new 1.1 PortGroup and also keeping the 1.0 PortGroup around, it maintains backwards compatibility, so that we don't break the checksums for dozens, maybe hundreds of existing ports that are using the 1.0 PortGroup and may still be fetching from the legacy/dummy URLs.

[jasonliu-- (Jason Liu)]

I'd be willing to create the pull request, if the general consensus is that create a 1.1 PortGroup is a good idea.

[breun (Nils Breunese)]

I don't know if there is a particular versioning scheme for PortGroups, but I prefer semantic versioning in general, and under that scheme a backwards incompatible change would require bumping the major version.

[chrstphrchvz (Christopher Chavez)]

My guess is that portgroup version increases have usually only been done after major rewrites which essentially deprecate the old portgroup. But portgroup default option changes and even major rewrites have been done before with no version increase, and seemingly no portgroup has gone beyond version 1.1.

I think it is better to not introduce another portgroup, especially if it is mostly the same as an existing one, just to avoid there being changes made to one which should instead be made to both.

If I have counted correctly, the github 1.0 portgroup is used 3393 times. And for github.tarball_from, archive is used 1278 times, releases 428 times, and downloads 11 times. So presumably github.tarball_from tarball is used (implicitly or explicitly) 1676 times.

[mascguy (Christopher Nielsen)]

This doesn't seem like a strong justification to create a new version of the portgroup.

If it were to simplify things to such an extent, that 5-ish (or more) lines could be eliminated... that's one thing. But not to save one line.

[jasonliu-- (Jason Liu)]

One line, 1278 times. Actually, theoretically it's closer to 1278 + 1676 = 2954 times, if you also want all of the tarball_from tarballs to be forced to use tarball_from archive instead.

[halostatue (Austin Ziegler)]

Shouldn't the default be releases instead of tarball (the current default) or archive? The comment I got on ​#21117 was:

please add "github.tarball_from" and set it to "releases" (preferred, if upstream supports this) or to "archive". In either case you will need to update the "checksums". ​reneeotten

[mascguy (Christopher Nielsen)]

Jason, just curious: So is your plan to copy-pasta the existing pg, with just one line being different from the original?

[ryandesign (Ryan Carsten Schmidt)]

Austin, the default cannot be releases because many projects do not offer release downloads. Ports should use releases when a project offers them.

The default should indeed be archive, since GitHub offers that automatically on behalf of all projects, but switching it would break all of the ports using the current default of tarball.

I agree something needs to be done because I continue to see new ports created that use the obsolete tarball setting. I was planning to revise port lint to warn on ports that do not set github.tarball_from, and perhaps a second warning for those that set it to tarball. My only hesitation with the latter is the mongo-tools port where I deliberately use the tarball setting.

I am against the extreme proliferation of new portgroups in recent years. I would favor a solution that allows the current portgroup to continue to be used. The solution would include adding the line github.tarball_from tarball to all existing ports that do not set that option so that they do not break but there is an additional wrinkle of ports that use the github portgroup indirectly, such as many ports that use the golang portgroup. yq is an example of that, picked at random.