In... commit 1cadd9ee290d278983d8eb596b58907cb344de86 Author: Arthur Zamarin <arthurzam@gentoo.org> Date: Thu Apr 3 21:13:02 2025 +0300 dev-lang/rust: add 1.86.0, SLOT=1.86 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> commit 8749059bd1b78b32f3e77a77db03fdef7ae26358 Author: Arthur Zamarin <arthurzam@gentoo.org> Date: Thu Apr 3 21:17:21 2025 +0300 dev-lang/rust-bin: add 1.86.0, SLOT=1.86 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> ... we changed the slotting scheme from ${PV} to $(ver_cut 1-2). We'd discussed that change on IRC but we should've put rationale in the commit message and in a bug somewhere. (Not saying Arthur or anyone did something wrong.) We had some fallout because of assumptions of the "old" slotting scheme: * bug 953103 * bug 953127 * bug 953130 I suspect that there's more breakage. It's hard to find these assumptions via grepping or even just reading the ebuilds. As for why we picked the new scheme: it's related to https://github.com/pkgcore/pkgcheck/issues/731 and pkgcheck's NonexistentDeps. The old scheme meant that once we cleanup e.g. rust-1.85.0, we get loads of pkgcheck warnings (not errors, as it's within || ( ... )) on rust.eclass consumers because 1.85.0 doesn't exist anymore. The new scheme avoids that because the dependency in the eclass only has :1.85, not :1.85.0 and :1.85.1.
My take is that we should revert to the old scheme: * I think it's too hard to find all the breakage. * None of us have time to try find all that breakage, and haven't had time to do so for quite a few days. 1.86.0 has been masked since then: commit b89c58da1802c889e4445c03d5a54acafef8372d Author: Arthur Zamarin <arthurzam@gentoo.org> Date: Fri Apr 4 21:59:57 2025 +0300 dev-lang/rust{,-bin}: mask 1.86.0 Temporary mask until handled the usage of shorter SLOT. Bug: https://bugs.gentoo.org/953103 Bug: https://bugs.gentoo.org/953127 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> * I don't think Rust is really stable enough yet for us to be sure that users will never want or need to downgrade to .0 if .1 is available and test both. It took a *long* time for us to be able to make that change for GCC and it was only in part because of the upstream versioning change there.
In my comment I assume we don't speak on the current active minor, but the previous ones. For example currently 1.86.0 is the main one, and 1.84.0 is the candidate to remove with 1.84.1 existing. From my side, I feel there is no need for .0 version if .1 exists. Rust ebuilds are slow (to build, and to parse [1]). It also is heavy on the mirrors side (imagine all the official and our tarballs) for rust-bin. On the side of bootstraping, there is no change between .1 and .0, so in the long run there is no need for .0 to exist in such case. Now why we need at all the .0 to remain? Maybe we should improve the BDEPEND string we build? Where do we really care that .0 remain? > None of us have time to try find all that breakage, and haven't had time to do so for quite a few days. 1.86.0 has been masked since then: For me this is a strong point currently, and I'm in support of returning 1.86.0 to old SLOT (${PV}), and we consider to move to shorter for next slot. We waiting for a long time already. [1] Running `pk pkg source` on dev-lang/rust gets me ~130ms, compared to <10ms for most ebuilds, 40ms for sys-devel/gcc, 30ms for llvm-core/llvm.
(In reply to Arthur Zamarin from comment #2) > From my side, I feel there is no need for .0 version if .1 exists. Rust > ebuilds are slow (to build, and to parse [1]). It also is heavy on the > mirrors side (imagine all the official and our tarballs) for rust-bin. My main argument is that it's very possible for Rust to introduce regressions in a .1 and being able to try .0 easily isn't a bad thing. > It also is heavy on the mirrors side (imagine all the official and our tarballs) for rust-bin. This is a fair point, especially with our own tarballs adding to that. > > Now why we need at all the .0 to remain? Maybe we should improve the BDEPEND > string we build? Where do we really care that .0 remain? It could maybe work to do =dev-lang/rust-${RUST_MAJOR}*:* in || ( ... ) but I don't know if Portage will handle that correctly or with good performance. > > > None of us have time to try find all that breakage, and haven't had time to do so for quite a few days. 1.86.0 has been masked since then: > > For me this is a strong point currently, and I'm in support of returning > 1.86.0 to old SLOT (${PV}), and we consider to move to shorter for next > slot. We waiting for a long time already. I'm unconvinced that the next bump will be different... it will likely mean we either delay bumping for ages, or we have breakage again. > [1] Running `pk pkg source` on dev-lang/rust gets me ~130ms, compared to > <10ms for most ebuilds, 40ms for sys-devel/gcc, 30ms for llvm-core/llvm. This metric does matter but we shouldn't let the tail wag the dog, either (i.e. it's not the most important thing).
(In reply to Sam James from comment #3) > > My main argument is that it's very possible for Rust to introduce > regressions in a .1 and being able to try .0 easily isn't a bad thing. OK, sounds good to me, for now. > > It also is heavy on the mirrors side (imagine all the official and our tarballs) for rust-bin. > > This is a fair point, especially with our own tarballs adding to that. OK, maybe extreme idea now. The tarball for dev-lang/rust isn't too bad, even for many versions, the issue is with dev-lang/rust-bin prebuilt ones. What if we decide a threshold of sanity (let's say 1.82 in current days), and make all older version have mirror restricted so they aren't mirrored on our mirrors. They are still mirrored on rust's CDN. Would it work? I think so, since it would drop those files from mirrors. Is it a weird usage of a feature? yes. Is it a good idea? I leave it to you to decide. > > > > > Now why we need at all the .0 to remain? Maybe we should improve the BDEPEND > > string we build? Where do we really care that .0 remain? > > It could maybe work to do =dev-lang/rust-${RUST_MAJOR}*:* in || ( ... ) but > I don't know if Portage will handle that correctly or with good performance. Sounds scary for now. > > > > > None of us have time to try find all that breakage, and haven't had time to do so for quite a few days. 1.86.0 has been masked since then: > > > > For me this is a strong point currently, and I'm in support of returning > > 1.86.0 to old SLOT (${PV}), and we consider to move to shorter for next > > slot. We waiting for a long time already. > > I'm unconvinced that the next bump will be different... it will likely mean > we either delay bumping for ages, or we have breakage again. Next bump we reconsider. If yet no one has the energy, we once again bump ${PV}. One day, onde day, it might happen. > > [1] Running `pk pkg source` on dev-lang/rust gets me ~130ms, compared to > > <10ms for most ebuilds, 40ms for sys-devel/gcc, 30ms for llvm-core/llvm. > > This metric does matter but we shouldn't let the tail wag the dog, either > (i.e. it's not the most important thing). But it does show a weak reason to remove those, or at least find where to optimize.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ab7539f2f0bf97b90c22d860a91bcbe321f4a0e commit 3ab7539f2f0bf97b90c22d860a91bcbe321f4a0e Author: Arthur Zamarin <arthurzam@gentoo.org> AuthorDate: 2025-04-13 15:36:25 +0000 Commit: Arthur Zamarin <arthurzam@gentoo.org> CommitDate: 2025-04-13 15:38:57 +0000 dev-lang/rust{,-bin}: update SLOT back to ${PV} We have issues and breakage with the shorter SLOT. Currently Rust project has no capacty to fix it. For more details see the frist bug. Bug: https://bugs.gentoo.org/953747 Closes: https://bugs.gentoo.org/953103 Closes: https://bugs.gentoo.org/953127 Closes: https://bugs.gentoo.org/953130 Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org> .../rust-bin/{rust-bin-1.86.0.ebuild => rust-bin-1.86.0-r1.ebuild} | 2 +- dev-lang/rust/{rust-1.86.0.ebuild => rust-1.86.0-r1.ebuild} | 5 ++--- eclass/rust.eclass | 4 ++-- profiles/base/package.use.force | 4 ++-- profiles/package.mask | 6 ------ 5 files changed, 7 insertions(+), 14 deletions(-)
