diff options
authorAndreas K. Hüttel <>2018-01-06 19:09:54 +0100
committerAndreas K. Hüttel <>2018-01-06 19:09:54 +0100
commitf2bdf8bc5a521c5d516cf51f623bebc134b14fa9 (patch)
tree297c838cd6c4183d397ff2f253b0bf275e76644b /decisions
parentImprove 5/2010 (diff)
Improve 5/2010 and 6/2010
Diffstat (limited to 'decisions')
6 files changed, 230 insertions, 41 deletions
diff --git a/decisions/decisions.ded b/decisions/decisions.ded
index 873fb38..613c89a 100644
--- a/decisions/decisions.ded
+++ b/decisions/decisions.ded
@@ -37,6 +37,9 @@
Ciaran McCreesh
+Tony Vroon
Donnie Berkholz
@@ -190,6 +193,9 @@
Peter Weller
+Alex Alexander
Chris Gianelloni
diff --git a/decisions/decisions.kilepr b/decisions/decisions.kilepr
index dc19778..2219636 100644
--- a/decisions/decisions.kilepr
+++ b/decisions/decisions.kilepr
@@ -4,7 +4,7 @@ img_extIsRegExp=false
img_extensions=.eps .jpg .jpeg .png .pdf .ps .fig .gif
name=Gentoo Council Decicisions Index
@@ -1200,10 +1200,10 @@ order=1
@@ -1220,20 +1220,20 @@ order=4
@@ -1895,7 +1895,7 @@ encoding=UTF-8
@@ -1903,7 +1903,7 @@ archive=true
@@ -1913,7 +1913,7 @@ archive=true
@@ -2855,10 +2855,10 @@ JumpList=
@@ -2867,16 +2867,16 @@ JumpList=
@@ -3276,15 +3276,15 @@ ViMarks=.,33,21,[,33,21,],33,21
diff --git a/decisions/decisions.tex b/decisions/decisions.tex
index a9f857e..98519a6 100644
--- a/decisions/decisions.tex
+++ b/decisions/decisions.tex
@@ -320,12 +320,6 @@ Election master ballot and results:
subsequent meetings. No unanimous acceptance of \dev{patrick} as next in list
was possible, so an election for the open seat was called.
-Call for nominations:
-Election master ballot and results:
{\bf Council members: \dev{betelgeuse}, \dev{calchan}, \dev{dertobi123},
\dev{leio}, \dev{lu_zero} (until 12/2009), \dev{scarabeus} (starting 1/2010),
\dev{solar}, \dev{ulm}}
@@ -346,10 +340,23 @@ Election master ballot and results:
\chapter{Meeting summaries 2010/11}
-Council members: betelgeuse, bonsaikitten (starting 1/2011), chainsaw,
-ferringb, halyc0n (until 12/2010), jmbsvicetto, scarabeus, wired
-All summaries have been added here.
+Call for nominations:
+Election results:
+Election master ballot:
+todo: changes
+{\bf Council members: \dev{betelgeuse}, \dev{patrick} (starting 1/2011),
+\dev{chainsaw}, \dev{ferringb}, \dev{halyc0n} (until 12/2010),
+\dev{jmbsvicetto}, \dev{scarabeus}, \dev{wired}}
diff --git a/decisions/documents.tex b/decisions/documents.tex
index cc8301b..1cfd6c2 100644
--- a/decisions/documents.tex
+++ b/decisions/documents.tex
@@ -414,3 +414,168 @@ Copyright
This document has been placed in the public domain.
+\section{REQUIRED_USE USE state constraints}
+GLEP: 61
+Title: REQUIRED_USE USE state constraints
+Version: 1.1
+Author: Brian Harring <ferringb at>
+Last-Modified: 2010/04/10 17:03:27
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 10-April-2010
+Post-History: 10-April-2010
+This GLEP proposes the addition of a new metadata key to specify what USE flag
+combinations are disallowed for a specific pkg.
+It's a semi common occurence that an ebuild may need to state that they disallow
+USE flags in specific combinations- either mysql or sqlite for example, but not
+Existing solutions rely on checking the the USE configuration in pkg_setup which
+is non-optimal due to pkg_setup being ran potentially hours after the initial
+emerge -p invocation.
+Current versions of EAPI4 support a phase hook pkg_pretend that is intended to
+move pre-build checks to just after resolution. It has been proposed that
+pkg_pretend should continue the tradition of adhoc shell code validating the USE
+state- this too is non optimal for the following reasons-
+1. The only way to find out if the USE state is disallowed is to run the code
+2. The common implementation of this can result in an iterative process where
+the user hits a USE constraint, fixs it, reruns the emerge invocation only to
+find that there is another constraint still violated for the ebuild, thus
+requiring them to fix it, rerun emerge, etc.
+3. For a package manager to classify the error, the only option it has is to
+try and parse adhoc output written by an ebuild dev. This effectively disallows
+package manager options for providing a more informative error message. A simple
+example would be if the package manager wanted to integrate in the flag
+descriptions from use.desc/use.local.desc; this would be effectively impossible.
+4. Fundamentally these constraints are data, yet they're being encoded as
+executable code- this effectively blocks the possibility of doing a wide variety
+of QA/tree scans. For example it blocks the possibility of sanely scanning for
+USE flag induced hard dependency cycles, because the tools in question cannot
+get that info out of adhoc shell code.
+5. More importantly if the manager cannot know what the allowed USE states are
+for the ebuild in question, this eliminates the possibility of ever sanely
+breaking dependency cycles caused by USE flags.
+Just as .sh scripts are considered a poor archival form due to their opaqueness,
+pkg_setup and pkg_pretend aren't a proper solution for this. pkg_pretend in
+particular makes the situation slightly worse due to ebuild devs being expected
+to convert their ebuilds to the pkg_pretend form when using EAPI4. In doing so
+they'll have to do work w/out the gains REQUIRED_USE provides and have to repeat
+the same conversion work when REQUIRED_USE lands in a later EAPI.
+It's due to this and a few lesser reasons that EAPI4 is strongly recommended as
+the target for this functionality.
+Essentially REQUIRED_USE is proposed to be an analogue of DEPENDS style syntax-
+a list of assertions that must be met for this USE configuration to be valid for
+this ebuild. For example, to state "if build is set, python must be unset":
+REQUIRED_USE="build? ( !python )"
+To state "either mysql or sqlite must be set, but not both":
+REQUIRED_USE="mysql? ( !sqlite ) !mysql? ( sqlite )"
+Note that the mysql/sqlite relationship is that of an Exclusive OR (XOR). While
+an XOR can be formed from existing syntax, it's suggested that a specific
+operator be added for this case using ^^. Reformatting the "mysql or sqlite, but
+not both" with XOR results in:
+REQUIRED_USE="^^ ( mysql sqlite )"
+Like any block operator, this can be combined with other constraints. For
+example if the user has flipped on the client flag, one gui must be choosen:
+REQUIRED_USE="client? ( ^^ ( gtk qt motif ) )"
+If the pkg is implemented sanely and requires at least one gui, but can support
+multiple it would be:
+REQUIRED_USE="client? ( || ( gtk qt motif ) )"
+Because ARCH is integrated into the USE space, this also allows for specifying
+corner cases like "at least one gui must be specified, but on mips only one gui
+can be specified":
+REQUIRED_USE="client? ( !mips? ( || ( gtk qt motif ) ) mips? ( ^^ ( gtk qt
+motif ) ) )"
+Please note that the AND operator is of course supported- if to enable client
+you must choose at least one gui and enable the python bindings the syntax would
+REQUIRED_USE="client? ( python || ( gtk qt motif x11 ) )"
+Finally, please note that this new metadata key can be set by eclasses, and the
+inherit implementation should protect the eclass set value just the same as how
+eclass defined DEPEND is protected.
+Implementing this for EAPI4, currently 'few' (Sebastion Luther) has a working
+git branch available at [portage-implementation] implementing this
+For getting this implemented in pkgcore, the author of the glep will handle it.
+As for paludis, presumably they can manage it due to MYOPTIONS existing in
+exheres already.
+Backwards Compatibility
+EAPI already makes this a non issue for backwards compatibility. Additionally
+the rsync metadata caches (enumerated flat file format) is designed for key
+expansion so there is no issue there either.
+Original ML proposal:
+Thanks to
+David Leverton, Brian Dolbec, and Jorge Manuel Vicetto for proofreading this and
+correcting the innumerable typos, run on sentences and general abuse of english
+the GLEP author is known for.
+Additionally, many thanks to Sebastion Luther ('few') for stepping up and
+writing the portage patch on short notice.
+This document has been placed in the public domain.
diff --git a/decisions/summary-20100517.tex b/decisions/summary-20100517.tex
index 21f7b2c..e2537cf 100644
--- a/decisions/summary-20100517.tex
+++ b/decisions/summary-20100517.tex
@@ -26,21 +26,22 @@ References:
A discussion on the voting procedures summarized in the
\agoref{gentoo-project}{df5433a1e6cbe479462da8f5fe588299} took place. It was
decided that all 5 options from that e-mail should be present in a future
-ballot on voting procedures.
+ballot on voting procedures. \index{council!votes!by mail}
Regarding present and future changes to the council structure, see the
\agoref{gentoo-project}{76311b25ccb18fff4764955db55ad0ea}, consensus was that
the new text should be a ``constitution'', which can only be updated with an
-all developer vote.
+all developer vote. \index{constitution} \index{metastructure}
Regarding the role of the council (e.g., responsive versus proactive), see the
\agoref{gentoo-project}{6009db554b00ae9de67047206c7698be}, an additional option
``Each council should set its mode of operation after being elected.'' was
-proposed. The trustee option should be a separate vote.
+proposed. The trustee option should be a separate vote. \index{council!role}
The options on potentially selecting a council lead, see the
\agoref{gentoo-project}{3806fe4e42dc8ce013e247a081e3d4a0}, were seen to be
-suitable for a ballot.
+suitable for a ballot. \index{council!lead}
There was consensus that such a central re-organization of Gentoo structure as
proposed here should not be rushed, with sufficient time for discussion on the
diff --git a/decisions/summary-20100614.tex b/decisions/summary-20100614.tex
index ea27481..15eb693 100644
--- a/decisions/summary-20100614.tex
+++ b/decisions/summary-20100614.tex
@@ -1,15 +1,25 @@
+Agenda call: ---
+Agenda announcement: ---
\agendaitem{REQUIRED_USE eapi addition}
+Reference: (dead link, see
+\ref{2010-05-feringb-requireduse} for the text)
-Reference: (dead link)
+Discussion touched the precise proposed syntax of REQUIRED_USE as well as its
+relationship to PMS.
-Voting delayed till next council to ensure everyone knew the details
+Voting on this issue was delayed until the next council is in office to ensure
+everyone knows the details.
\agendaitem{Attempted post mortem discussion for the outgoing council's term}
-Primarily discussion, no real recommendations/resolutions
+Primarily discussion took place, without real recommendations or resolutions.
+Suggestions included that the council be more decisive and proactive, and
+postpone decisions less.