[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
01/02: doc: Fix typos in Guix Days 2020 "Parameterized packages".
From: |
Pierre Neidhardt |
Subject: |
01/02: doc: Fix typos in Guix Days 2020 "Parameterized packages". |
Date: |
Mon, 17 Feb 2020 05:26:51 -0500 (EST) |
ambrevar pushed a commit to branch master
in repository maintenance.
commit 26ea4ab4c6789ab971016f90665cd15d37386e4b
Author: Pierre Neidhardt <address@hidden>
AuthorDate: Mon Feb 17 11:22:49 2020 +0100
doc: Fix typos in Guix Days 2020 "Parameterized packages".
* doc/guix-days-2020/parameterized-packages-guix-days: Do it.
---
.../parameterized-packages-guix-days.org | 24 +++++++++++-----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/doc/guix-days-2020/parameterized-packages-guix-days.org
b/doc/guix-days-2020/parameterized-packages-guix-days.org
index 96f2921..e1aead5 100644
--- a/doc/guix-days-2020/parameterized-packages-guix-days.org
+++ b/doc/guix-days-2020/parameterized-packages-guix-days.org
@@ -1,10 +1,10 @@
* Parameterized Packages
** Definititions
*** USE flags
-The inspiration for Parameterized Packages in guix largely comes from
+The inspiration for Parameterized Packages in Guix largely comes from
Gentoo Linux, which is well known for its powerful
[[https://wiki.gentoo.org/wiki/USE_flag][USE flags]], which
allow the end user to customize various properties of the package
-build process. Common USE flags include *X*, for enabling X11 support,
+build process. Common USE flags include *X*, for enabling X11 support,
*dbus* to toggle dbus integration, and *debug* to enable debugging
support.
@@ -22,40 +22,40 @@ any combination of parameters.
** Integration with Functional Builds
A common problem with Gentoo USE flags occurs when packages in a user
profile themselves depend the same package, only with conflicting USE
-flags set. Fortunately, guix's functional package builds allow us to
+flags set. Fortunately, Guix's functional package builds allow us to
have multiple versions of a package in the store that differ only in
the parameter set.
*** Hackability / customizability
-An easy interface for package customization would further guix's goal
+An easy interface for package customization would further Guix's goal
of being a hackable package manager.
** Disadvantages
*** Complexity
The flipside of increased expressiveness in package definitions is
increased complexity. As the number of parameters grows, there is a
explosion in the number of possible parameter combinations. This means
-that guix may be unable to test all possibile parameter combinations
-available to the end user.
+that Guix may be unable to test all possibile parameter combinations
+available to the end user.
*** Substitutes
When a user customizes their package parameters, they are creating a
distinct version of the package that will have a unique store
-hash. Therefore unless guix dedicates resources to building
+hash. Therefore unless Guix dedicates resources to building
substitutes for common package parameters, they will have to compile
everything themselves.
** Questions / Discussions
*** Dealing with propagation
We agreed that we want to to develop an alternative approach to the
-Gentoo USE flag system. Guix packages should be able to declare which
+Gentoo USE flag system. Guix packages should be able to declare which
parameters that they understand, and in addition we believe that guix
packages should explicitly declare which parameters are allowed to
-propagate to any dependencies of the package. If a parameter is not
+propagate to any dependencies of the package. If a parameter is not
allowed to propagate, then when the dependencies are evaluated, they
will not see that the parameter has been set, instead falling back to
-the parameter default. In addition, packages will not be able to set
+the parameter default. In addition, packages will not be able to set
any additional parameters for their dependencies that the user has not
already declared.
-*** Technical Considerations
+*** Technical considerations
**** Host instead of build side
Because we want to support parameters that can add additional
dependencies to the package, the parameter handling logic needs to
-occur on the host side. One possibility suggested was for the
+occur on the host side. One possibility suggested was for the
parameters to be evaluated when the package is lowered into a bag.