Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 906044 - dev-lang/rust: pkg_postinst misses info on "emerge @rust-rebuild"
Summary: dev-lang/rust: pkg_postinst misses info on "emerge @rust-rebuild"
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Rust Project
URL: https://gitweb.gentoo.org/repo/gentoo...
Whiteboard:
Keywords:
: 945545 (view as bug list)
Depends on: 939444
Blocks:
  Show dependency tree
 
Reported: 2023-05-09 20:31 UTC by David Sardari
Modified: 2025-01-22 00:48 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Sardari 2023-05-09 20:31:01 UTC
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
Comment 1 Eli Schwartz gentoo-dev 2024-11-10 22:22:36 UTC
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.
Comment 2 Jinghao Jia 2024-11-11 19:27:11 UTC
(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?
Comment 3 Eli Schwartz gentoo-dev 2024-11-11 20:05:24 UTC
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
Comment 4 Jinghao Jia 2024-11-11 20:13:47 UTC
(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?
Comment 5 jeremy mills 2024-11-12 18:27:32 UTC
(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.
Comment 6 jeremy mills 2024-11-12 18:46:56 UTC
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.
Comment 7 Jinghao Jia 2024-11-12 19:59:41 UTC
(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?
Comment 8 Eli Schwartz gentoo-dev 2024-11-12 20:03:28 UTC
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).
Comment 9 jeremy mills 2024-11-13 01:39:03 UTC
(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.
Comment 10 Eli Schwartz gentoo-dev 2024-11-13 02:17:18 UTC
(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.
Comment 11 Larry the Git Cow gentoo-dev 2024-11-18 16:49:38 UTC
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(-)
Comment 12 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-12-01 15:03:44 UTC
*** Bug 945545 has been marked as a duplicate of this bug. ***
Comment 13 Larry the Git Cow gentoo-dev 2025-01-22 00:30:21 UTC
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(+)