bartronx7/guix
1
0
Fork 0
mirror of https://codeberg.org/guix/guix.git synced 2026-01-25 03:55:08 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

doc: Recommend ‘define-deprecated-package’ in the Deprecation Policy.

Browse source 
* doc/contributing.texi (Deprecation Policy): Document and recommend
‘define-deprecated-package’.

Change-Id: I530310f5216f09025525d91f690bb3885fe2cfb4
This commit is contained in:
Ludovic Courtès 2025-10-16 18:25:23 +02:00
parent 9fcfb93944
commit 9995614558
No known key found for this signature in database
GPG key ID: 090B11993D9AEBB5
1 changed files with 13 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
doc/contributing.texi
View file

@ -3344,13 +3344,21 @@ for @b{at least one year}. For example, @code{go-ipfs} was renamed to
change to users, the package module provided this definition:
@findex deprecated-package
@findex define-deprecated-package
@lisp
(define-public go-ipfs
(deprecated-package "go-ipfs" kubo))
(define-deprecated-package go-ipfs
kubo)
@end lisp
That way, someone running @command{guix install go-ipfs} or similar sees
a deprecation warning mentioning the new name.
a deprecation warning mentioning the new package name; likewise, someone
referring to the @code{go-ipfs} @emph{variable} from their manifest or
package definition will see a warning.
Under the hood, @code{define-deprecated-package} combines
@code{define-deprecated/public-alias} to mark the variable as deprecated
(see below), and the @code{deprecated-package} procedure to mark the
package name as deprecated.
@cindex package removal policy
@anchor{package-removal-policy}
@ -3360,8 +3368,8 @@ of life'' or being unmaintained may be removed; likewise, packages that
have been @b{failing to build for two months or more} may be removed.
There is no formal deprecation mechanism for this case, unless a
replacement exists, in which case the @code{deprecated-package}
procedure mentioned above can be used.
replacement exists, in which case the @code{define-deprecated-package}
macro mentioned above can be used.
If the package being removed is a ``leaf'' (no other packages depend on
it), it may be removed after a @b{one-month review period} of the patch