guix-commits
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]