Handling update check for packages using untagged commits?

[triallax]

there are a bunch of templates (e.g. user/plan9port) using untagged git versions, and it's very easy for us to forget to update these because they usually don't show up in cports-updates.txt, what do you think about adding a custom update check for them somehow so we know when there are new commits?

[q66]

i'm not really interested in adding special noisy handling for something that we generally shouldn't be doing in the first place

[triallax]

it's unavoidable for certain things, and i think it sucks that they will only get updated whenever somebody randomly remembers to do it or they start causing issues

[nekopsykose]

sounds fine as a separate update-check argument that is not ran by default

not sure what it should look like though

[triallax]

sounds fine as a separate update-check argument that is not ran by default

why should it be a separate argument? we could just print the latest commit so it doesn't get too noisy

[q66]

is there like, anything that meaningfully benefits from this and is enough to warrant adding a bunch of code to handle this stuff

[nekopsykose]

why should it be a separate argument? we could just print the latest commit so it doesn't get too noisy

that's only useful if you actually want to update to every single new commit, since otherwise you kinda dont want it in the log

[z-erica]

it's unavoidable for certain things, and i think it sucks that they will only get updated whenever somebody randomly remembers to do it or they start causing issues

i feel like that's partly why user/ exists, as an AUR-like kitchen sink that's not necessarily coordinated with the rest of the system proper and that offers no real guarantees wrt breakage beyond what ppl are willing to go out of their way to fix. imo it's fine for plan9port to stay in that category

[q66]

tbh i don't really see a good way to fetch the updates here anyway; to do so you'd need to actually invoke git on a clone, as if you just fetch what is the HEAD commit from like github or something, you have no way to tell if it's newer than your existing one or what

the only thing you could do is like, fetch the date for the latest commit and if it's newer than your version (which would be like 0_gitDATE) then report the update, but that still sounds pretty clunky

and as i see it, stuff it's unavoidable for is fairly rare and doesn't really warrant having special code to handle it

[z-erica]

for drawterm i kludged together this https://github.com/chimera-linux/cports/blob/e07da0d8a9b016f11e2e26e8ba59909c930117dc/user/drawterm/update.py but really only bc their git frontend lists the dates in a parseable format (and the commits are sparse enough)

[q66]

yea but this does not require any new code so that's fine

i don't see any way to piece this together generically which is what @triallax is asking for i guess

[triallax]

tbh i was not necessarily thinking of having some generic code for this in cbuild's update check code, it was more of a general question about adding update checks for unversioned packages even if it's per-template (i mean the former would be really nice still but yeah)

i feel like that's partly why user/ exists, as an AUR-like kitchen sink that's not necessarily coordinated with the rest of the system proper and that offers no real guarantees wrt breakage beyond what ppl are willing to go out of their way to fix. imo it's fine for plan9port to stay in that category

@z-erica there's also some stuff in main and contrib that does it too, for better or worse (e.g. luajit)

that's only useful if you actually want to update to every single new commit, since otherwise you kinda dont want it in the log

@nekopsykose true

[JamiKettunen]

fwiw I've had an implementation of this for nearly a year in master...JamiKettunen:cports:git-updates which I occasionally pick to local branches. not saying it should ever get integrated or that it's good (it's more or less just a port of my old JamiKettunen/void-packages@ca884fb) but that it does exist