| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Also make it a multiple of 12pt (= \baselineskip).
Automatically calculate the width of the last column in the big
variables table.
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Portage didn't ever set (or unset) these variables to a special value
when sourcing the ebuild, so obviously ebuilds cannot rely on this.
Restrict their validity to actual phases and make global scope
behaviour unspecified.
The previous wording was introduced with commit 58d3bc0.
Bug: https://bugs.gentoo.org/908552
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D in pkg_* phases was first mentioned in SVN r74 (commit f627e46102c6)
as a variable specific to the pkg_preinst phase function (replacing
IMAGE). pkg_postinst was added in r88 (commit 3da3ee561f1a), but this
was reverted in r89 (commit 65c466317718) "D in pkg_postinst == bad".
pkg_postinst reappeared when the env vars section was converted to
a table in commit 58d3bc0e8301.
According to chapter 13 "Merging and Unmerging", the method used to
perform the merge is not specified, and merging a regular file or
a directory may alter or remove its source under D. Therefore, trying
to access any file in D during the postinst phase is an error.
The scope of ED follows that of D.
Closes: https://bugs.gentoo.org/920889
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
| |
Restrict the previous change to EAPIs that actually support IDEPEND.
Bug: https://bugs.gentoo.org/911574
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By section sec:dependency-classes, dependency class BDEPEND is
satisfied in phase functions src_* and pkg_setup (only if part of
source build); IDEPEND is satisfied in pkg_preinst, pkg_postinst,
pkg_prerm and pkg_postrm.
Update the entry for BROOT accordingly.
Closes: https://bugs.gentoo.org/911574
Reported-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
| |
Suggested-by: Sam James <sam@gentoo.org>
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>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The D variable has been described as a "phase-specific variable" since
the spec's early draft stage (SVN r19). However, Portage would always
define the variable in all src_* phases, with the restriction that the
directory would exist only in src_install().
In reality, not all ebuilds comply with the spec. For example, Perl
eclasses use D in src_configure(), i.e. they rely on Portage behaviour.
Therefore, lift this unnecessary and somewhat artificial restriction
and make the variable (but not the directory) available outside the
install phase.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
| |
Fixes: 27a0bf1961ae56fd6b948d5ffea9a9e4ae35fd91
Closes: https://bugs.gentoo.org/796794
Signed-off-by: Dmitrii Neskoromnyi <nuclearspace@gmail.com>
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>
|
|
|
|
|
|
|
|
|
|
|
| |
Subsume IUSE_REFERENCEABLE and IUSE_EFFECTIVE under a single
conditional, which will clarify that these variables are equal if the
feature is supported.
Also the profile-iuse-inject featurelabel was misplaced (it didn't
cover IUSE_REFERENCEABLE).
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>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
| |
Allow using SYSROOT & BROOT in pkg_setup(), when building from source.
This follows the earlier change allowing for build-time dependencies
in pkg_setup under the same circumstances.
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>
|
|
|
|
|
| |
We use \textbf almost everywhere, so remove the few uses of \b
(which is not recognised by AUCTeX either).
|
|
|
|
|
|
|
|
| |
tab:added-env-vars-table was too wide, which is fixed by reducing
the width of the paragraph type columns.
tab:econf-options-table: Change columns with overlong headers to
paragraph type, in order to allow line breaks.
|
|
|
|
|
|
| |
Thanks to mgorny for providing the initial wording.
Bug: https://bugs.gentoo.org/499288
|
|
|
|
| |
Bug: https://bugs.gentoo.org/317337
|
|
|
|
| |
Bug: https://bugs.gentoo.org/317337
|
|
|
|
| |
Bug: https://bugs.gentoo.org/465772
|
| |
|
|
|
|
| |
Bug: https://bugs.gentoo.org/173630
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/373349
Bug: https://bugs.gentoo.org/373351
|
| |
|
| |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Ebuilds must not access the WORKDIR directory in global scope, so the
FILESDIR footnote applies to it, too. Rearrange the table accordingly.
Also small change of wording ("in which" -> "where") to prevent an
awkward page break.
|
|
|
|
| |
This reverts commit 65d38361a953c0b6da4cc192d8727b0d6f1c64cc.
|
|
|
|
|
|
|
|
|
|
|
| |
It is quite common and useful for existing ebuilds to access the A
variable in pkg_nofetch. Also package managers define the variable
there. Update the spec accordingly.
The same applies to AA (which is deprecated, but there is no reason
why its scope should be different from A).
Thanks to Michał Górny for pointing this out.
|
|
|
|
|
|
|
|
|
| |
Both WORKDIR and S are defined in global scope, but ebuilds must not
access the actual directories. So the FILESDIR footnote applies to
them, too. Rearrange the table accordingly.
Also small change of wording ("in which" -> "where") to prevent an
awkward page break.
|
|
|
|
|
|
|
|
|
| |
Require both DISTDIR and FILESDIR variables to have consistent value
across phases. We need to guarantee that the value used in global scope
to propagate PATCHES array will be still valid in src_prepare().
Furthermore, as Ulrich Müller points out that PMS requires ebuilds to
recalculate any value derived from inconsistent variables, therefore
colliding with the global-scope assignment.
|
|
|
|
|
|
| |
Rephrase the wording for FILESDIR to indicate that it does not need to
be the original files/ directory in the repository. It just needs to
be some directory containing the files from that directory.
|
|
|
|
|
| |
PF may change if the package is updated, because the package name may
change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit fa4ac9474048ec75af138fc61f22485c06aac5b7 had inadvertently
changed the scope of the PORTDIR and ECLASSDIR variables which were
referring to FILESDIR by a "ditto" in the second column. Restore both
variables to src_*. To this end, reorder variables such that DISTDIR
follows FILESDIR, and move the remark about accessing the directory
into the footnote.
Note: Similar to FILESDIR, accessing DISTDIR in global scope is needed
for assignment of the PATCHES variable in EAPI 6.
Thanks to mgorny for pointing this out.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is needed for assigning PATCHES in EAPI 6.
Also add a note that ebuilds must not access the actual directory
in global scope. The situation is similar to WORKDIR which is also
defined in global scope (for assigning S) but with the dir not being
available there.
|
|
|
|
| |
This is also consistent with the spec for the A variable.
|