On 23-07-2022 22:53, Liliana Marie Prikler wrote: > Am Samstag, dem 23.07.2022 um 21:56 +0200 schrieb Maxime Devos: >> On 23-07-2022 17:11, Liliana Marie Prikler wrote: >> >>> +        (revision "2022.05.23"))        ; Use a date rather than a >>> number >> This is a technically a possibility, but currently the convention is >> to use numbers and the number convention is expected by (guix >> upstream) and the (not yet merged, needs some finishing touches IIRC) >> latest-git updater, and AFAIK there hasn't been any discussion on >> switching to dates. > In this case I am departing from the usual convention because I think > calendar versioning is more useful for this type of content. OK, but Guix seems to have decided on numbering in the past, I don't think a package patch is a place to change that policy. If you want to change things to calendar versioning for some kinds of git stuff, this sounds like something to be discussed and approved or disapproved on guix-devel@gnu.org, not here. > Given the issue that lead to this patch at all, I'm not sure if support for > automatic updates would be a good idea with this package. IMHO, it's a > feature rather than a bug that you can't accidentally pull a third of > BSD's offensive database, were it to ever land in this repo. As mentioned later, "guix refresh -u" != automatic updates. I expect that a person manually updating the package would prefer the aid of "guix refresh -u" instead of having to clone the git repo by theirselves and do "guix hash -r", maybe forget the "-x", then remembering that "-r" is deprecated then having to look in the manual for --serializer=nix. > Should I explain this thought more clearly in the package or do automatic updates trump ethical concerns? Guix does not have automatic updates, it does not decide by itself to update some packaes without any review. The updaters are only run when done so manually, e.g. with "guix refresh -u fortunes-jkirchartz". In that case, as always though it seems to be neglected due to limited resources currently, the diff between the previous version and the new version should be verified for malware.  There's no X trumps Y here, AFAICT. Also, if Guix decides on CalVer for some packages, then in the context of the latest-git updater, the latest-git updater will have to be modified to support CalVer -- latest-git has no idea about how individual packages work, so it cannot decide to block updates. As such, going for CalVer to prevent generic-git from updating (with guix refresh -u or --with-latest) does not seem robust to me, as it will just be updated anyway with future improvements to latest-git. If you want to block updates to some degree for some packages, then you could look into, say, adding a (updatable? . #false) flag or such for the 'properties' field or maybe add a comment next to the package definition to ask people updating the package to look out for fortunes-mod-style badness. Greetings, Maxime.