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 Mon, Jan 10, 2022 at 01:59:13AM +0100, Morgan Wesström wrote:
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
Don't know if it's relevant or not but recently upstream deprecated the "KERNEL" USE flag, resulting in many rebuilds for packages.
On Mon, Jan 10, 2022 at 01:59:13AM +0100, Morgan Wesström wrote:
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?
Don't know if it's relevant or not but recently upstream deprecated the "KERNEL" USE flag, resulting in many rebuilds for packages.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 83:11:40 |
Calls: | 6,495 |
Calls today: | 6 |
Files: | 12,096 |
Messages: | 5,276,829 |