GNU bug report logs - #72840
[PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Janneke Nieuwenhuizen <janneke <at> gnu.org>
Cc: guix-devel <guix-devel <at> gnu.org>, 72840 <at> debbugs.gnu.org
Subject: [bug#72840] [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.
Date: Thu, 26 Sep 2024 15:16:58 +0200

Hi Janneke,

Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:

>>   https://issues.guix.gnu.org/72840
>
> Thanks, looks good to me!  As a side remark: It would be nice if
> upgrading of config.scm / home.scm could be automated.

It would be great, indeed.

> Anyway, I do have a vaguely related question.  The Dezyne package comes
> with a `guix.scm' that uses a package description in
> guix/pack/dezyne.scm, which uses `%gnu-build-system-modules'.
>
> Recently, %gnu-build-system-modules was deprecated in
>
> 28dbfdb38f52f5814fb4cba9c02831d2ab0dc079
> build-system/gnu: Introduce ‘%gnu-build-system-modules’ deprecated alias.
>
> 9e4ce281dbd92e3c52b831824ebb1f77023c960c
> build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-modules.

I’m not convinced this was a worthwhile change BTW, looking at the
intended clarity improvement vs. cost ratio.

> Although the `guix.scm' has a comment like
>
> ;; To use the canonical commit that has everything prebuilt:
> ;;
> ;;   guix time-machine --commit=918b7d102c2051c3d6c6ba54c8d265affec5282c -- shell
>
>
> documenting a commit that can be used for building the package and has
> substitutes available, usage of the commit is not enforced.  After a
> recent `guix pull', we now get this warning
>
> pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, use '%default-gnu-imported-modules' instead
>
> and I'm wondering what the best moment would be to change the package
> description.  Upgrading sooner (i.e., now) means that a future guix that
> has this deprecated feature removed will be able to build more
> hystorical releases of the package simply by doing `guix shell', so
> that's probably the best choice?  It would mean that all developers have
> to upgrade now (or use the time machine).

Yeah, that’s always a difficult choice, and I don’t have a good answer.
What’s sure is that the deprecated name will remain available for a
relatively long time, so there’s no urgency at this point.

> but you'd have to know about that and it probably only works for the
> Dezyne package.  Is there a better way or should something like this be
> advertised/recommended in the documentation?

I’m not sure we could recommend one approach that would work for
everyone because it really depends on the use case (for instance whether
building with an older Guix is important for your project.  But at
least, by setting expectations, the deprecation policy lets users making
informed decisions.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.