| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Reported-by: Jannik Glückert <jannik.glueckert@gmail.com>
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subsection headings were already changed from title case to sentence
case in commit ca463ce. This left chapter and section headings alone,
which is inconsistent (although it is specified by some style guides
like APA).
This commit changes headings to sentence case throughout, following
most other Gentoo documentation, e.g. wiki and devmanual.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/660306
Signed-off-by: Michał Górny <mgorny@gentoo.org>
[Updated as discussed in -pms mailing list]
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
| |
Taken from https://tex.stackexchange.com/a/2645.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
| |
This is only used a few times, so a shorthand is not needed.
(We really should get rid of \i and \t as well, because redefining
LaTeX internal commands sucks.)
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was originally envisaged (but not stated in PMS) that SYSROOT would
only ever need to equal / or ROOT as a distinct SYSROOT would have no
benefit. A check was added to Portage to ensure this held. Myself, the
ChromiumOS team, and others have since been caught out by this check
when trying to bootstrap brand new systems from scratch. You cannot
bootstrap with no headers at all! The check will therefore be adjusted
to merely ensure that SYSROOT is / when ROOT is /.
There were differing assumptions about how prefixes applied to the
above. EPREFIX is traditionally something the user sets so some
thought that it would be applied to SYSROOT, regardless of the
latter's value. In order to honor the rule about there being no
distinct SYSROOT, this would mean that if SYSROOT is / then EPREFIX
would have to match BROOT. Despite that limitation, ESYSROOT was
written into PMS with a fixed value of ${SYSROOT}${EPREFIX}. Being
somewhat unfamiliar with prefix at the time, I didn't realise that
this view didn't align with what I'd had in mind and it was only when
I came to need a distinct SYSROOT that I realised there was a problem.
crossdev toolchains are installed to ${EPREFIX}/usr/${CHOST} but have
no further prefix appended and packages subsequently installed with
cross-emerge are placed in this location by setting ROOT. Bug #642604
recently revealed that the build system's prefix was being erroneously
duplicated on the end but I have now fixed this.
What if we want to bootstrap a brand new prefixed system using the
crossdev system as SYSROOT? This is the distinct SYSROOT case. The
problem is that there is no distinct variable for SYSROOT's prefix
and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
therefore cannot do it! If the crossdev prefix is blank then ROOT's
must be blank too.
I also never intended to have the aforementioned limitation where
EPREFIX must match BROOT when SYSROOT is /. These are both entirely
artificial restrictions.
So how should it work instead? We originally intended for SYSROOT to
equal either / or ROOT so I imagined the prefix would automatically be
adjusted to match the prefix applicable at the matching location,
namely BROOT or EPREFIX. This is obviously more flexible than forcing
it to match EPREFIX.
What about the distinct SYSROOT case? With no distinct variable, we
have no way to explicitly set a prefix but this is likely only needed
when bootstrapping against crossdev systems, which are unprefixed by
nature. We therefore simply assume that the prefix is blank in this
case.
What about the cross-prefix case? Here, SYSROOT matches both / and
ROOT so which prefix do we choose? The bootstrap-prefix.sh script sets
flags to build against the target prefix so EPREFIX is used in this
case. This happens to fit the current definition of ESYSROOT anyway.
Legitimate concerns have been raised about building for a system with
a different prefix to the one you're building against. The only
binaries that leak from SYSROOT to ROOT are static libraries. Headers
from SYSROOT will obviously also influence how ROOT's binaries are
built. It is entirely possible that SYSROOT's prefix may leak through
a header but grepping /usr/include on my own main system reveals only
a few paths from a small handful of packages. pkg-config files
invariably include paths but these are almost always used at build
time, not runtime. A differing prefix would likely only occur in cases
involving core packages like the libc and kernel headers anyway. Also
consider that we have never prevented this from happening in the
past. It has always been possible to do "EPREFIX=/foo emerge bar" from
some system with a different prefix or no prefix at all. All we're
doing here is including the prefix (if any) in the ESYSROOT variable.
Should this warrant a new EAPI? I don't think so. All existing usage
of ESYSROOT that I have seen still fits with this new definition and
most of that usage has come from me. We're not even changing what the
variable is used for, just loosening the constraints around what it
can be set to.
If you have doubts about whether this makes sense or actually works in
practise, I have experimented with a prefixed system using all the
different combinations I could think of, including cross-compiling,
and it all worked as expected. Keep in mind that ESYSROOT is not magic
and currently isn't used very much. As such, neither the toolchain nor
pkg-config will use this sysroot if you don't explicitly tell them
to. For the former, I find CC="${CHOST}-gcc --sysroot=${ESYSROOT}"
works well. For the latter, crossdev installs a cross-pkg-config
wrapper but it is completely lacking prefix support at the moment. I
have fixes waiting on this change.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
[Replaced "/" by "empty", reworded table cell in ebuild-env-vars.tex]
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
| |
This is a remnant of old-style virtuals and should have been removed
long ago.
Fixes: c8ab6b99bffa85bcd686284ba60a30f53c31c8b0
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
| |
Also rename label prefixes, "ch:" for chapters, "sec:" for sections,
as suggested by Michael Orlitzky.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
| |
Its subsubsections "Operators", "Block operator", "Slot dependencies",
and "2-style and 4-style USE dependencies" will become subsections,
so the maximum section number depth of the document will be 2.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
SRC_URI, REQUIRED_USE, PROPERTIES, and RESTRICT are ebuild-defined
variables. Move them to that chapter.
Add reference to tab:uri-arrows-table in SRC_URI section. Otherwise,
no change of wording.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Remove the circular dependency note for RDEPEND. This is confusing
at best, and there is no gain from claiming that non-standard, redundant
Portage behavior is valid.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Account for build dependencies being satisfied in pkg_setup, when
executed as part of source build, in order to match the realistic
implementation and widespread use in Gentoo. This changes pkg_setup
from the previous state of no dependencies being guaranteed.
Firstly, this matches the standard package manager implementation
better. Since pkg_setup is executed as part of the sequence of
successive phases comprising a source build, it is natural that build
dependencies are installed already when it's executed, and not between
pkg_setup and src_unpack.
Secondly, it accounts for widespread use of pkg_setup to determine
installed dependencies in order to set the build environment
appropriately. This is a case e.g. with python-any-r1 or llvm eclasses,
which query installed packages in order to determine the Python or LLVM
version to use, appropriately. This behavior can't be changed without
major changes to a large number of ebuilds, and without making ebuild
development harder.
Technically, we could extend the same rule to RDEPEND being satisfied
when package is going to be installed. However, this would restrict
the flexibility of parallel builds. With regard to the current rules,
the package manager can start building package from sources before all
of its runtime dependencies are installed. The unclear benefit
of having RDEPEND satisfied in pkg_setup does not seem to justify losing
this possibility.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
| |
|
| |
|
|
|
|
| |
Bug: https://bugs.gentoo.org/203891
|
| |
|
|
|
|
| |
Bug: https://bugs.gentoo.org/317337
|
|
|
|
| |
Bug: https://bugs.gentoo.org/636596
|
| |
|
|
|
|
| |
Use the command correctly throughout; it requires an argument.
|
| |
|
|
|
|
|
| |
Any-of, exactly-one-of, and at-most-one-of groups have similar format,
so there is no need to repeat the same description three times.
|
|
|
|
| |
Bug: https://bugs.gentoo.org/370565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The specification for empty groups was originally added to match
historical Portage behaviour. However, Portage was changed in 2011
to treat empty dependency groups as an error, therefore ebuilds cannot
rely on any definite behaviour. Consequently, empty groups are not used
by any ebuild or eclass in the Gentoo repository.
Note that the explicit handling for empty groups is still retained for
the case of implicit empty groups resulting from collapsing USE
conditionals in any-of groups et al.
This is a retroactive change for all EAPIs.
Bug: https://bugs.gentoo.org/370565
|
| |
|
|
|
|
|
|
|
|
|
| |
Add additional vertical space between rows of the 'Dependency classes
required to be satisfied for a particular phase function' to improve
readbility. For all but the last row, the phase function cell spans
multiple lines while the dependency class cell is one line only. Without
the extra spacing, it is not apparent at a first glance whether
a particular phase function uses dependencies above or below it.
|
|
|
|
|
|
| |
An empty group will automatically fulfill the condition of "at most
one immediate child element", therefore no special provision for an
empty group is necessary here.
|
|
|
|
|
| |
Replacement was done using "sed -i 's/\\_/_/g' *.tex".
This does not change the resulting PDF and HTML output.
|
|
|
|
|
|
|
|
| |
Use title case for first and second level headings (i.e., \chapter
and \section in the main text, \section and \subsection in the EAPI
cheat sheet); use sentence case everywhere else.
https://archives.gentoo.org/gentoo-pms/message/cef75e03f1a3b692281a5b79065dc2b6
|
|
|
|
|
|
|
|
|
| |
Explicitly indicate that the ebuild is required to provide appropriate
DEPEND for := to have a matching package installed. Additionally ban
the cases where := can not be reliably used or does not make any sense:
PDEPEND (because by intent the dependency can not be in DEPEND),
and any-of groups (because the non-binding nature of any-of group
collides with binding nature of :=).
|
|
|
|
|
|
|
|
|
|
|
| |
Correct the wording for the 'equals' slot operator to indicate that
the slot of the best installed package at the time package is *built*
matters. After all, the common use case for := is to indicate that
the build binds to a specific package version.
This is also more in line with dependency classes where we clearly
split the dependencies between build and runtime, and indicate that only
DEPEND is guaranteed to be available before src_*.
|
| |
|
|
|
|
|
| |
Combine all lines with identical behaviour for different EAPIs.
Also use consistent indentation for tables in the LaTeX source.
|
| |
|
| |
|
| |
|
|
|
|
| |
Bug: 560466
|
|
|
|
|
|
| |
Lines seem to be wrapped at 100 characters throughout, with the
exception of eapi-cheatsheet.tex which is wrapped at 70 characters.
Assign the "fill-column" file local variable for Emacs accordingly.
|
| |
|
|
|
|
|
|
|
|
| |
RESTRICT=sandbox is neither used in the tree nor supported by Portage.
Drop it retroactively for all EAPIs, bug 161045.
The spec still says that "package managers may recognise other tokens"
so package managers are free to support the feature.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
See also ebuild(5):
fetch - like mirror but the files will not be fetched via SRC_URI either.
|
|
|
|
| |
See bug 424429.
|
|
|
|
| |
See bug 354219
|