Am 10.01.22 um 01:59 schrieb Morgan Wesström:
On a freshly updated system (emerge -uDN @world):
"emerge @changed-deps" wants to reinstall 0 packages.
"emerge -u --changed-deps=y" wants to reinstall 24 packages.
"emerge -uD --changed-deps=y" wants to reinstall 181 packages.
A couple of years ago there was a build breakage in Portage because, as
I understood it at the time, some developer changed the dependencies in
an existing ebuild without bumping its revision level. The solution was
to use --changed-deps=y to catch these occurrences and I've been using
it in my regular update routine since then. But as you can see in the
third example above, it usually wants to reinstall hundreds of packages
that doesn't have any updated versions and I'm wondering if this is
working as intended. I have a hard time believing that gentoo devs are
pushing changes to existing ebuilds in such numbers on a regular basis
without bumping the revision level.
Some time ago I became aware that Portage now has a @changed-deps set,
which I assumed was accomplishing the same thing, but it doesn't produce
the same result as --changed-deps=y - usually just a dozen reinstalls or
so.
Can someone please elaborate on what's going on here, what the
difference is between --changed-deps=y and @changed-deps, if that
difference is intended and what the recommended update procedure is
these days to catch these and other kinds of inconsistencies in Portage?
Regards
Morgan
On my system most of this is related to build time dependencies.
#emerge -Duav --reinstall changed-use --changed-deps=y --with-bdeps=n @world
Total: 10 packages (10 reinstalls)
#emerge -Duav --reinstall changed-use --changed-deps=y --with-bdeps=y @world
Total: 131 packages (131 reinstalls)
