After the upgrade of dev-lang/go, the necessity to rebuild all "go" packages is pointed out. The same should happen with dev-lang/rust. Reproducible: Always
It feels less plausible to do this for rust than for golang, honestly. The point of rebuilding is so that binaries are re-linked against a newer version of the standard library, which mostly doesn't actually matter unless there are bugfixes or security fixes in the new version. But if it was that simple we'd actually say the same thing for glibc updates too, because software that links to glibc only uses the symbols available in the glibc version it was originally compiled against. Sure, it's not statically linked in, but you miss out on improvements in the form of new APIs and new, backwards incompatible versions of existing APIs -- because glibc maintains strict compatibility with older versions and if they need to fix a symbol such that it changes ABI, the new version gets a different binary name and won't be used except by newly compiled programs. Basically, it all comes down to security vulnerabilities, and that's why we single out golang -- because golang specifically has a horrible track record.
(In reply to Eli Schwartz from comment #1) > It feels less plausible to do this for rust than for golang, honestly. The > point of rebuilding is so that binaries are re-linked against a newer > version of the standard library, which mostly doesn't actually matter unless > there are bugfixes or security fixes in the new version. > > But if it was that simple we'd actually say the same thing for glibc updates > too, because software that links to glibc only uses the symbols available in > the glibc version it was originally compiled against. Sure, it's not > statically linked in, but you miss out on improvements in the form of new > APIs and new, backwards incompatible versions of existing APIs -- because > glibc maintains strict compatibility with older versions and if they need to > fix a symbol such that it changes ABI, the new version gets a different > binary name and won't be used except by newly compiled programs. > > Basically, it all comes down to security vulnerabilities, and that's why we > single out golang -- because golang specifically has a horrible track record. I wonder if this is the same reason that rust-rebuild is now broken after the recent removal of virtual/rust? Are we going to drop the rust-rebuild support?
Huh, that's an interesting point. @rust-rebuild is defined in the portage source code: [rust-rebuild] class = portage.sets.dbapi.VariableSet variable = BDEPEND includes = virtual/rust
(In reply to Eli Schwartz from comment #3) > Huh, that's an interesting point. @rust-rebuild is defined in the portage > source code: > > > [rust-rebuild] > class = portage.sets.dbapi.VariableSet > variable = BDEPEND > includes = virtual/rust virtual/rust as a BDEPEND for rust packages was removed in commit 01ba4dc61965 ("*/*: update for slotted Rust") and the virtual package itself was also masked in favor of the new slotted Rust. This breaks the definition of @rust-rebuild set above (emerge -1v @rust-rebuild finds nothing). If this is not intended, should I open a separate bug?
(In reply to Jinghao Jia from comment #4) > (In reply to Eli Schwartz from comment #3) > > Huh, that's an interesting point. @rust-rebuild is defined in the portage > > source code: > > > > > > [rust-rebuild] > > class = portage.sets.dbapi.VariableSet > > variable = BDEPEND > > includes = virtual/rust > > virtual/rust as a BDEPEND for rust packages was removed in commit > 01ba4dc61965 ("*/*: update for slotted Rust") and the virtual package itself > was also masked in favor of the new slotted Rust. This breaks the definition > of @rust-rebuild set above (emerge -1v @rust-rebuild finds nothing). If this > is not intended, should I open a separate bug? oddly enough it doesnt find anything even if changing it to includes = dev-lang/rust like i would expect it to. unless im missing something here. and i definitely have packages depending on dev-lang/rust. idk maybe they just arent listed as having rust as a bdep. rpm-seqouia being one of them off the top of my head.
ok i tried the latest changes from that link. should @rust-rebuild now be asking to rebuild all dev-lang/rust slots too? or is that unintended behavior? because i just noticed that as different behavior than before.
(In reply to jeremy mills from comment #6) > ok i tried the latest changes from that link. should @rust-rebuild now be > asking to rebuild all dev-lang/rust slots too? or is that unintended > behavior? because i just noticed that as different behavior than before. My guess is you have system-bootstrap USE flag enabled so that dev-lang/rust becomes a BDEPEND of itself?
Well, part of the eclass changes is that dev-lang/rust no longer has a system-bootstrap USE flag, and it simply always does a system bootstrap. Before this, it was a system bootstrap in disguise, as it downloaded a temporary copy of dev-lang/rust-bin and ran that. (In reply to jeremy mills from comment #6) > ok i tried the latest changes from that link. should @rust-rebuild now be > asking to rebuild all dev-lang/rust slots too? or is that unintended > behavior? because i just noticed that as different behavior than before. This makes sense I think, because dev-lang/rust is, itself, written in rust so bootstrapping rust:1.81.0 using rust:1.80.1 and then running @rust-rebuild will cause rust:1.81.0 to rebuild itself using a newer rustc (1.81.0, of course).
(In reply to Eli Schwartz from comment #8) > Well, part of the eclass changes is that dev-lang/rust no longer has a > system-bootstrap USE flag, and it simply always does a system bootstrap. > > Before this, it was a system bootstrap in disguise, as it downloaded a > temporary copy of dev-lang/rust-bin and ran that. > > (In reply to jeremy mills from comment #6) > > ok i tried the latest changes from that link. should @rust-rebuild now be > > asking to rebuild all dev-lang/rust slots too? or is that unintended > > behavior? because i just noticed that as different behavior than before. > > > This makes sense I think, because dev-lang/rust is, itself, written in rust > so bootstrapping rust:1.81.0 using rust:1.80.1 and then running > @rust-rebuild will cause rust:1.81.0 to rebuild itself using a newer rustc > (1.81.0, of course). what you are saying makes sense for the scenario your explaining. how about if my path was the opposite though? i had manually installed rust:1.82.0. then eselected it as the default. then manually installed rust:1.81.0. then i synced my portage tree today and got the rebuilds for both due to the system-bootstrap usemask i believe (i always use --with-bdeps=y --changed-deps=y also). rust:1.82.0 is still eselected. then i tried changes to the portage set and it wanted to rebuild both slots again. its not a big deal either way they build for me in about 15mins each. on weaker hardware it might be an inconvenience.
(In reply to jeremy mills from comment #9) > what you are saying makes sense for the scenario your explaining. how about > if my path was the opposite though? The direction doesn't really change the fact that the dynamic set as calculated, only knows what packages depend on a given selector. I think what you're trying to say is a more general issue: A set calculated as "packages which depend on dev-lang/rust and can therefore be rebuilt against changes to dev-lang/rust", doesn't know whether you've already rebuilt it, so every time you run `emerge @rust-rebuild` it will rebuild all packages that are compiled using a rust compiler. Again, and again, and again. Rust is a package that builds using a rust compiler. It's conceptually valid to rebuild it, but you may well have already done so. One could perhaps argue that this is part of the reason why it's not necessarily useful to emerge @rust-rebuild after every update to dev-lang/rust. One could also argue that it would be neat if portage dynamic sets could compare DEPEND based selectors for the most recent merge time of the selected package versus the most recent merge time of the DEPEND that caused it to be included in the set. But that would be an entirely different feature request.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=c990345eb83cba8e1606f643b19b99520e54e06c commit c990345eb83cba8e1606f643b19b99520e54e06c Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2024-11-11 21:15:24 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-11-18 16:48:57 +0000 update set for "rust-rebuild" to adapt to changes in gentoo The virtual package is deprecated and we use an eclass to depend on an any-of group for the relevant rust compilers. This set no longer does anything without an update. Start checking BDEPEND for the specific rust compilers. Also keep checking for the virtual, so that "rust-rebuild" reports on packages that have not, in fact, been rebuilt yet. Bug: https://bugs.gentoo.org/906044 Closes: https://github.com/gentoo/portage/pull/1399 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Mike Gilbert <floppym@gentoo.org> cnf/sets/portage.conf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
*** Bug 945545 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03f41049a0fe0632eabd8cddaaca898e45943201 commit 03f41049a0fe0632eabd8cddaaca898e45943201 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-22 00:29:50 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-22 00:30:02 +0000 sys-apps/portage: add 3.0.67 Closes: https://bugs.gentoo.org/703520 Closes: https://bugs.gentoo.org/707980 Closes: https://bugs.gentoo.org/904702 Closes: https://bugs.gentoo.org/906044 Closes: https://bugs.gentoo.org/923530 Closes: https://bugs.gentoo.org/938164 Closes: https://bugs.gentoo.org/939299 Closes: https://bugs.gentoo.org/940120 Closes: https://bugs.gentoo.org/942512 Closes: https://bugs.gentoo.org/942760 Closes: https://bugs.gentoo.org/945382 Closes: https://bugs.gentoo.org/945861 Closes: https://bugs.gentoo.org/946326 Closes: https://bugs.gentoo.org/947822 Closes: https://bugs.gentoo.org/948067 Closes: https://bugs.gentoo.org/939444 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.67.ebuild | 231 +++++++++++++++++++++++++++++++++ 2 files changed, 232 insertions(+)