bug#54691: [PATCH 2/5] gnu: Add fortunes-jkirchartz.

[Maxime Devos]

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.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature