In general, there are *preferred* versus *workable* bootstrap compilers,
and it is *preferred* to build ${lang} with an already built copy of
that compiler, e.g. to get bugfixes and so on. So, for iteration order
when setting up the compilation environment, we prefer our own SLOT, if
multiple bootstrap compilers are available after `src_*` phases start
running.
As a separate matter, the dependency merge graph must pull in at least
one *workable* compiler, and it would be nice if it is a *preferred*
one. Portage solves for dependencies favoring leftmost if it is
necessary to merge an additional dependency. So, ordering from
most-preferred to least-preferred is plausibly reasonable.
Problem: given an installed *workable* but least-preferred compiler,
triggering autounmask of USE=ada causes portage to ignore a *workable*
compiler if the leftmost dependency is already in the merge graph. It
then reports a cycle, where the current package to build depends on
itself:
```
* Error: circular dependencies:
(sys-devel/gcc-14.3.0:14/14::gentoo, ebuild scheduled for merge) depends on
(sys-devel/gcc-14.3.0:14/14::gentoo, ebuild scheduled for merge) (buildtime)
```
It turns out, the order in the any-of group matters. If:
- item 1 is ${PN}:${SLOT}
- item 2 is <${PN}-${SLOT}
- item 3 is installed (ada-bootstrap)
The merge graph wants to build item 1, item 2 would build a ton of
versions and eventually need item 3, item 3 simply works without fuss.
But item 1 *cannot* be uninstalled, yet still get merged in this
transaction to satisfy the deps. And if it is already installed, we
don't need leftmost-associativity to force the preferred compiler to be
merged for building excellent machine code.
Conversely, if item 1 is moved to the end, portage... doesn't try to
autounmask item 2 (now item 1), even if item 3 (ada-bootstrap) is *not*
installed. Although without autounmasking, if "sys-devel/gcc ada" is in
package.use, it does build a large chain of gcc[ada]'s, since it can and
is leftmost.
But for autounmask, instead, it installs item 3 (ada-bootstrap) if
necessary, since it can do so without further autounmask. The incorrect
cycle is broken.
Make this change, because it only affects cycle-breaking and doesn't
affect iteration order in src_configure.
Bug: https://bugs.gentoo.org/962273
Acked-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Upstream did not use a consistent versioning scheme. Releases progressed
like this:
2.43 -> 2.5 -> 2.6.0 -> .. -> 2.7.0 -> 2.7.1 -> 2.8 -> 2.81 -> 2.82
Gentoo versioning was changed from version 2.70 to 2.7.0 (see commit
f90946f91c88 in archive/repo/gentoo-2.git) with the rationale:
"change Ebuild name, so we can get rid of MY_PV variable".
The current e3 announces itself as "MicroEditor e3 v2.82-UTF8", and both
the tarball and its top-level directory are named e3-2.82. If upstream
should ever publish a 2.9 release, we could use 2.90 as package version.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
Source of many upstream reports, so Wayland users might as well go straight
to ~arch 13.1.0 instead. This will at least get rid of the KF5 dependency.
Bug: https://bugs.gentoo.org/954005
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Andreas Sturmlechner
Eli Schwartz
Ulrich Müller
Hanno Böck
Arthur Zamarin
Patrick Lauer
Matt Turner
Joonas Niilola
Pavel Sobolev
Jay Faulkner
Michał Górny