Hello, I will start by replying only on the editorial comments.
Am Wed, Apr 15, 2026 at 07:17:51AM +0200 schrieb apteryx: > +## Package renamings > + > +As stipulated in the current deprecation policy, such renamings may happen > > "such renamings" appears to refer to something introduced earlier, which isn't > the case. I'd repeat "package renamings" or "renaming of packages". Are we > talking strictly about the package name, or both its name and variable name > (which is really the API part)? I have replaced by "name field of packages", since otherwise define-deprecated-package does not work. Changing the variable name is in a sense covered by the section about moving between modules; it is possible to change variable names inside the same module, but this brings little gain for some pain and is not a common use case (even more so since by default, the variable name and the name field of the package record are the same). So in this case maybe we can assume that people will do as for the moving between modules case and use define-deprecated/public-alias. > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +176,4 @@ > + > +## Package additions > + > +Care shall be taken when adding packages that these do not already > > I'd replace shall (future) with must, here and elsewhere. Hm, I am using "shall" as in RFCs https://www.rfc-editor.org/rfc/rfc2119 as an imperative; I am not a native speaker, but I think it is a somewhat more polite form of "must". > +## Package additions > + > +Care shall be taken when adding packages that these do not already > > I think this could be reworded for more clarity to something like: > > If a package does not satisfy the requirements* for package health (e.g., if > it > is abandoned upstream), then it should not be accepted in the Guix package > collection. > > * which requirements? I don't see anything clearly defined here, or in our > current deprecation policy. I am not convinced; the "criteria to become a removal candidate" are outlined above and I do not think we should repeat them. Also, the current sentence states precisely what we want to avoid: A potential cycle between additions and removals, whatever the criteria for removal are. > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > +### Removal candidates that are building leaf packages > + > +It makes sense to distinguish two cases. > > Maybe we could have an enumeration below, to further explicit what the two > cases are. Changed. > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +110,4 @@ > + > +It makes sense to distinguish two cases. > + > +Leaf packages that by their nature were used mainly as inputs to other > > s/were/are/, to be consistent Changed. > > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +123,4 @@ > +they may be removed following the above process. > + > + > +### Removal candidates that are building packages inside the dependency graph > > perhaps "that have dependents" would be clearer than "are inside the > dependency > graph" ? > > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > In 006-package-deprecation.md: > > diff --git a/006-package-deprecation.md b/006-package-deprecation.md > --- /dev/null > +++ b/006-package-deprecation.md > @@ -0,0 +125,4 @@ > + > +### Removal candidates that are building packages inside the dependency graph > + > +Removing building packages that are in the interior of the dependency graph > > "in the interior" sounds weird to me; I'd rephrase to just "that have > dependents (in the Guix packages graph)" I think this is consistent with some definitions of graph theory, but I have changed it to make it simpler and thus clearer. The same could be done for leaves, but the term is probably more common. I am always a bit at a loss with the term "dependency" - if package A is said to "have a dependency B", does it mean that A depends on B or that B depends on A? Using "dependent" should be okay (is it a noun in English? or does one have to use it as an adjective such as in "dependent package"?). > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > +Removing building packages that are in the interior of the dependency graph > +causes more disruption than removing leaf packages, since at the same time > +all dependent packages need to be removed. This may still be desirable for > +overarching reasons. For instance, we will want to remove older versions > > s/will// Done. Thanks! Andreas
