Zen

Translation

Package management commands.name changes
English type: item
Package name changes
10/200 · 20

Sign in to save the translation.

English Korean Actions
To guard against accidentally updating the @code{guix} package to a commit that others can't refer to, a check is made that the commit used has already been pushed to the Savannah-hosted Guix git repository.
 
This check can be disabled, @emph{at your own peril}, by setting the @code{GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT} environment variable. When this variable is set, the updated package source is also added to the store. This is used as part of the release process of Guix.
 
deprecation policy
 
As any lively project with a broad scope, Guix changes all the time and at all levels. Because it's user-extensible and programmable, incompatible changes can directly impact users and make their life harder. It is thus important to reduce user-visible incompatible changes to a minimum and, when such changes are deemed necessary, to clearly communicate them through a @dfn{deprecation period} so everyone can adapt with minimum hassle. This section defines the project's commitments for smooth deprecation and describes procedures and mechanisms to honor them.
 
There are several ways to use Guix; how to handle deprecation will depend on each use case. Those can be roughly categorized like this:
 
package management exclusively through the command line;
 
advanced package management using the manifest and package interfaces;
 
Home and System management, using the @code{operating-system} and/or @code{home-environment} interfaces together with the service interfaces;
 
development or use of external tools that use programming interfaces such as the @code{(guix ...)} modules.
 
These use cases form a spectrum with varying degrees of coupling---from ``distant'' to tightly coupled. Based on this insight, we define the following @dfn{deprecation policies} that we consider suitable for each of these levels.
 
Command-line tools
프로그래밍 연결장치
Guix sub-commands should be thought of as remaining available ``forever''. Once a Guix sub-command is to be removed, it should be deprecated first, and then remain available for @b{at least one year} after the first release that deprecated it.
 
Deprecation should first be announced in the manual and as an entry in @file{etc/news.scm}; additional communication such as a blog post explaining the rationale is welcome. Months before the scheduled removal date, the command should print a warning explaining how to migrate. An example of this is the replacement of @command{guix environment} by @command{guix shell}, started in October 2021@footnote{For more details on the @command{guix shell} transition, see @uref{https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/}.}.
 
Because of the broad impact of such a change, we recommend conducting a user survey before enacting a plan.
 
package deprecation
꾸러미 설명
Package name changes
꾸러미 관리 명령.
When a package name changes, it must remain available under its old name for @b{at least one year}. For example, @code{go-ipfs} was renamed to @code{kubo} following a decision made upstream; to communicate the name change to users, the package module provided this definition:
 
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.
 

Loading…

User avatar None

String added in the repository
Package name changes
꾸러미 관리 명령.
3 months ago
User avatar None

Source string changed
Package management commands.name changes
3 months ago
Browse all string changes

Things to check

Mismatched full stop

Source and translation do not both end with a full stop

Reset

Glossary

English Korean
package 꾸러미 guix Glossary

18406739 String information

Source string description
type: item
Flags
no-wrap
Source string location
guix-git/doc/contributing.texi:3194
String age
3 months ago
Last updated
2 weeks ago
Source string age
3 months ago
Translation file
po/doc/guix-manual.ko.po, string 830