Re: Fix mk/fetch/github.mk

[Greg Troxel <gdt%lexort.com@localhost>]

pin <voidpin%protonmail.com@localhost> writes:

> On Tuesday, February 13th, 2024 at 11:49 AM, pin <voidpin%protonmail.com@localhost> wrote:
>
>> > In x11/alacritty/Makefile, this is wrong:
>> > 
>> > GITHUB_TAG= refs/tags/v${PKGVERSION_NOREV}
>> > 
>> > has to be changed to:
>> > 
>> > GITHUB_TAG= v${PKGVERSION_NOREV}
>
> Ok, since you found it, I've now fixed it in x11/alacritty
>
>> This is not x11/alacritty, it's wip/alacritty-dev.
>> The same happens on wip/elvish-dev.
>> 
>> It breaks all my packages that I run from the dev branches.
>
> We still need a solution for these.
> It's not only wip/alacritty-dev and wip/elvish-dev, I run several other packages (not in wip) from the dev-branches, all of them fail to build.

(individual hat on only!)

I think we need to look to what is documented and what ought to be.  I
am not 100% clear on this.  I have myself written GITHUB_TAG to be
refs/tags/${ACTUAL_TAG} in order to get things to work, and found that
to be kludgy.

Looking at mk/fetch/github.mk, it is underdocumented, but
suggests that GITHUB_TAG be

  # GITHUB_TAG            defaults to PKGVERSION_NOREV                                                                                                                                                                       
  #                       sometimes you want to override with v${PKGVERSION_NOREV}                                                                                                                                           
  #                       SHA-1 commit ids are also acceptable                                                                                                                                                               

which I find sensible; it should contain something that you hand to
git as a tag

But then subtype says

  # "tag"                                                                                                                                                                                                                    
  # This is the default when GITHUB_RELEASE is not defined. Example URL:                                                                                                                                                     
  # http://github.com/acct/${GITHUB_PROJECT}/archive/{GITHUB_TAG}.tar.gz                                                                                                                                                     

which is apparently not what the code does now.  But, I think that URL
does *not* fetch a tag.  And it's not the URL that is now fetched.

So at the very least, the recent commit did not update the
documentation.

> I've reverted your change locally in order to update my packages but,
> this is not a viable permanent solution.

I am not following your logic.   The question is how to get to a state
where we can express what we need and everything makes sense.

If it means basically

  change
    GITHUB_TAG= refs/tags/v${PKGVERSION_NOREV}
  to
    GITHUB_TAG= v${PKGVERSION_NOREV}
  
then that seems an ok outcome.

(If you are complaining that the code to fetch was changed, but not the
doc, and that the users of the variable that had a workaround were not
adjusted, that's a fair complaint, but that's not how I read your mail.)


There's a secondary issue which is that submodules use this same
pattern, and haven't been adjusted.  (That's good, given that that the
expressions of submodules have not been adjusted either!)


To me the really big question (about the outcome, not about the process
and how we try to work cooperatively towards the common goal of
improving pkgsrc) is whether people need to fetch from github using
other than how the tag type does now.  Still, even if we do, I would
lead to adding a new GITHUB_TYPE tagpath that one is expected to place
the partial URL  folowing /archive/ to be used in exceptional
situations.

The root cause of this trouble is of course github culture, where
upstreams expect people to run things that are not releases, using tags
instead of making actual releases.  (There is also running from a commit
hash, which is reasonable for foo-snapshot/foo-devel.)


So to pin@:

  If you drop refs/tags/ from all our GITHUB_TAG definitions, are things
  OK?

  If not, what's wrong?

And to adam@:

  You said you tested, but how could *anything* that uses GITHUB_TAG
  have worked?  Is my analysis above wrong?

  What is your plan to fix the unintended consequences of your change?