Summary: | frivolous rebuilds triggered by --rebuild-if-new-ver and/or --rebuild-if-new-rev | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Daniel Pouzzner <douzzer> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Daniel Pouzzner
2023-02-07 20:14:52 UTC
Not looked at this properly yet, but I'd like to note that: 1. I'm surprised (but glad) to see people using --rebuild-if-new-rev --rebuild-if-new-ver and they're not very common options to use, even if they have quite limited application; 2. I feel like the "spurious rebuilds" when saying "rebuild everything with new versions of my deps" is at best a bit confusing. What behaviour are you expecting, exactly? Portage _does not_ analyse which version it was built against. It does not analyse SONAME dependencies or anything of the like for this. These packages depend on gcc and hence get a rebuild with a new version of gcc. It's possible that someone could extend Portage to have it try figure out which GCC version things were built with (at least for C++, this will be easyish, not sure about C), but it isn't supposed to do that right now. The ebuilds in your list, I think, all explicitly depend on gcc rather than the standard @system thing because of e.g. openmp or specifying a minimum version. I do think there's value in something which tries to figure out if we used an old GCC (or glibc or ...), but it's also kind of related to the issue of "how do I rebuild only C/C++/... applications and not Python if it's unnecessary". I'm not sure if there's enough info in the VDB for this, it might be close enough based on NEEDED for libc.so and such though. But that doesn't help with your problem wrt exact GCC versions... >These packages depend on gcc and hence get a rebuild with a new version of gcc.
Ideally, I would want a package that depends on gcc to get a rebuild only if the new version of gcc at issue would be the one that the dependent package would actually use. With deselected gcc, it isn't, implying that what's missing here is slot sensitivity in the dependency calculation.
And for the example I showed, I think that's all that's needed to make --rebuild-if-* have expected+unsurprising results.
Ah, I follow now. I think we could do that, although I can't promise to implement it personally immediately. Understood. Yeah I was just wondering what effort would be involved... (In reply to Sam James from comment #4) > Ah, I follow now. I think we could do that, although I can't promise to > implement it personally immediately. Sorry, I mean: it'd be possible to say "rebuild if installed before a slot was ever around", but it's not possible to make it aware of what slot was used without obsoleting gcc-config and making an ebuild handle the selected variant. (This is similar to bug 283587.) I think the rule I have in mind would just be "upgrade of slotted package X triggers rebuild of dependent package Y iff the slot of X is the currently selected slot." Another example of the syndrome: These are the packages that would be merged, in order: [...] [ebuild NS ~] sys-devel/binutils-2.41:2.41::gentoo [2.38-r2:2.38::gentoo, 2.39-r5:2.39::gentoo, 2.40-r7:2.40::gentoo] USE="doc nls plugins static-libs (-cet) -debuginfod -gold -gprofng -hardened% -multitarget -pgo -test -vanilla -zstd" 0 KiB [...] The following packages are causing rebuilds: (sys-libs/binutils-libs-2.41:0/2.41::gentoo, ebuild scheduled for merge) causes rebuilds for: (dev-db/mariadb-10.11.4:10.11/18::gentoo, ebuild scheduled for merge) (dev-lang/ocaml-4.14.1:0/4.14.1::gentoo, ebuild scheduled for merge) # eselect binutils list [...] [44] x86_64-pc-linux-gnu-2.38 [45] x86_64-pc-linux-gnu-2.39 [46] x86_64-pc-linux-gnu-2.40 * The syndrome is fairly benign at least -- just some extra wheel-spinning. |