Subject: Re: [PATCH RFC] DRAFT doc: Add “Deprecation Policy” section.

From: Janneke Nieuwenhuizen <[email-masked]>
Date: Sat, 14 Sep 2024 09:14:21 +0200

Ludovic Courtès writes:

Hi!

> I realize I did not advertise the “Deprecation Policy” proposal here,
> which is a mistake because it’s relevant to all of us as developers and
> packagers, and it’s also a key element of our relation with the broader
> user base.
>
> So please, consider reading the proposal and joining the discussion:
>
>   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.

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

--8<---------------cut here---------------start------------->8---
28dbfdb38f52f5814fb4cba9c02831d2ab0dc079
build-system/gnu: Introduce ‘%gnu-build-system-modules’ deprecated alias.

9e4ce281dbd92e3c52b831824ebb1f77023c960c
build-systems: gnu: Export %default-gnu-imported-modules and %default-gnu-modules.
--8<---------------cut here---------------end--------------->8---

Although the `guix.scm' has a comment like

--8<---------------cut here---------------start------------->8---
;; To use the canonical commit that has everything prebuilt:
;;
;;   guix time-machine --commit=918b7d102c2051c3d6c6ba54c8d265affec5282c -- shell
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
pack/dezyne.scm:69:20: warning: '%gnu-build-system-modules' is deprecated, use '%default-gnu-imported-modules' instead
--8<---------------cut here---------------end--------------->8---

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).

Of course, we can always(?) build hystorical release by doing

    $(grep -o 'guix time.*' guix.scm)

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?

Greetings
Janneke

-- 
Janneke Nieuwenhuizen <[email-masked]>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com