Zen

Translation

English #-#-#-#-# contributing.pot (guix manual checkout) #-#-#-#-# type: item #-#-#-#-# guix.pot (guix manual checkout) #-#-#-#-# type: node
Services
0/100 · 8

Sign in to save the translation.

English Dutch Actions
deprecated-package
 
(define-public go-ipfs
(deprecated-package "go-ipfs" kubo))
 
That way, someone running @command{guix install go-ipfs} or similar sees a deprecation warning mentioning the new name.
 
package removal policy
 
package-removal-policy
 
Package removal
 
Packages whose upstream developers have declared as having reached ``end 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.
 
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 removing it (this applies even when the removal has additional motivations such as security problems affecting the package).
 
If it has many dependent packages---as is the case for example with Python version@tie{}2---the relevant team must propose a deprecation removal agenda and seek consensus with other packagers for @b{at least one month}. It may also invite feedback from the broader user community, for example through a survey. Removal of all impacted packages may be gradual, spanning multiple months, to accommodate all use cases.
 
When the package being removed is considered popular, whether or not it is a leaf, its deprecation must be announced as an entry in @code{etc/news.scm}.
 
Package upgrade
 
In the case of packages with many dependents and/or many users, an upgrade may be treated like the @emph{removal} of the previous version.
 
Examples include major version upgrades of programming language implementations, as we've seen above with Python, and major upgrades of ``big'' libraries such as Qt or GTK.
 
service deprecation
 
Services
 
Changes to services for Guix Home and Guix System have a direct impact on user configuration. For a user, adjusting to interface changes is rarely rewarding, which is why any such change must be clearly communicated in advance through deprecation warnings and documentation.
 
Renaming of variables related to service, home, or system configuration must be communicated for at least six months before removal using the @code{(guix deprecation)} mechanisms. For example, renaming of @code{murmur-configuration} to @code{mumble-server-configuration} was communicated through a series of definitions like this one:
 
define-deprecated/public-alias
 
(define-deprecated/public-alias
murmur-configuration
mumble-server-configuration)
 
Procedures slated for removal may be defined like this:
 
define-deprecated
 
(define-deprecated (elogind-service #:key (config (elogind-configuration)))
elogind-service-type
(service elogind-service-type config))
 
Record fields, notably fields of service configuration records, must follow a similar deprecation period. This is usually achieved through @i{ad hoc} means though. For example, the @code{hosts-file} field of @code{operating-system} was deprecated by adding a @code{sanitized} property that would emit a warning:
 
(define-record-type* <operating-system>
;; @dots{}
(hosts-file %operating-system-hosts-file ;deprecated
(default #f)
(sanitize warn-hosts-file-field-deprecation)))

 
(define-deprecated (operating-system-hosts-file os)
hosts-service-type
(%operating-system-hosts-file os))
 
When deprecating interfaces in @code{operating-system}, @code{home-environment}, @code{(gnu services)}, or any popular service, the deprecation must come with an entry in @code{etc/news.scm}.
 
deprecation of programming interfaces
 
Core interfaces
 
Core programming interfaces, in particular the @code{(guix ...)} modules, may be relied on by a variety of external tools and channels. Any incompatible change must be formally deprecated with @code{define-deprecated}, as shown above, for @b{at least one year} before removal. The manual must clearly document the new interface and, except in obvious cases, explain how to migrate from the old one.
 
As an example, the @code{build-expression->derivation} procedure was superseded by @code{gexp->derivation} and remained available as a deprecated symbol:
 
User avatar anonymous

Suggestion added

Services

Suggested change:

Services
a year ago

Loading…

User avatar anonymous

Suggestion added
Services
Services
a year ago
User avatar None

String updated in the repository
Services
 
a year ago
Browse all string changes

Things to check

Suggestions

There is 1 suggestion for this string.

View

Inconsistent

This string has more than one translation in this project or is untranslated in some components.

Reset

Glossary

English Dutch
No related strings found in the glossary.

14900011 String information

Source string description
#-#-#-#-# contributing.pot (guix manual checkout) #-#-#-#-# type: item #-#-#-#-# guix.pot (guix manual checkout) #-#-#-#-# type: node
Flags
ignore-same, no-wrap
Source string location
guix-git/doc/contributing.texi:3246 • guix-git/doc/guix.texi:388 • guix-git/doc/guix.texi:394 • guix-git/doc/guix.texi:17211 • guix-git/doc/guix.texi:19169 • guix-git/doc/guix.texi:19170 • guix-git/doc/guix.texi:35050
String age
a year ago
Last updated
6 days ago
Source string age
4 years ago
Translation file
po/doc/guix-manual.nl.po, string 847