Preventing unmerge of specific package version and atom-bins

[coalms]

Im trying to avoid making too many forum posts at for relevant answers so sorry guys ima treat you like the IT guy gets treated at a party and ask you loads of questions in a disrespectful sounding way, not trying to be rude to be honest

Im stack on reemerging rust every 3 days because rust-bin is not working with with musl and emergin virtual/rust-x.x version gets deleted after some point with --depclean, I understand I could just mask the binned version but is a problem that popped 3 questions in my head

• Is there a way to prevent globally any bin packages from installing? (i have come to understand it is probably accept_lisence=-@BINARY-REDISTRIBUTABLE I just find it masks almost everything, neither am I sure that all bin packages end in -bin to mask */*-bin)
  is there a way to keep multiple versions on the system without them being umerged at some point in the future? nothing like "package.keep"or "slot.keep" on man 5 portage and afaik you can only -w atom names not versions, unless I understand slotting wrong they get unmerged as well(otherwise my rust packages wouldn't get unmerged since they are automatically sloted when i emerge virtual/rust-x-y-z
  lastly not as important question to the rest, how can i keep slots from unmerging if i did for example "SLOT='nameofslot' emerge another-other-other-version-of-firefox --emptytree" how can i prevent every package installed in that slot from unmerging in the future?

[NeddySeagoon]

coalms,

We were all new to Gentoo once. Just when you get that hang of it, it changes. It seems like after 20 years, I'm still new :)

A few words on slotting.
Slotting is expensive in terms of developer time. Two different versions of the same package will want to install the same files. Slotting keeps the installed files apart.
Its not automatic.

gcc is slotted.

Code: Select all

[U] sys-devel/gcc
     Available versions:  
     (8.5.0) [M]8.5.0-r1^t
     (9.5.0) [M]9.5.0^t
     (10)   [M]10.5.0^t
     (11)   11.4.1_p20230622^t (~)11.4.1_p20230824^t **11.4.1_p20231116^t **11.4.1_p20231123^t **11.4.1_p20231130^t **11.5.9999*l^t
     (12)   12.3.1_p20230825^t **12.3.1_p20231117^t **12.3.1_p20231124^t **12.3.1_p20231201^t **12.4.9999*l^t
     (13)   13.2.1_p20230826^t{tbz2} (~)13.2.1_p20231014^t{tbz2,xpak:2} **13.2.1_p20231118^t **13.2.1_p20231125^t **13.3.9999*l^t
     (14)   **14.0.0_pre20231119^t **14.0.0_pre20231126^t **14.0.0.9999*l^t

Its possible to install one version in each slot. Prior to slot 10, slots were down to patch versions. That was dropped due to the maintenance burden.

Rust is not slotted, so you may only install one version at a time.

is there a way to keep multiple versions on the system without them being umerged at some point in the future?

Yes and no. You can keep binary packages that you build yourself and reuse them in future.
Read about FEATURES in

Code: Select all

man make.conf

Now you can switch between multiple home made binaries with an emerge command.
That's the theory.
In practice, ebuilds get removed from the repo. You need the ebuild to install your binary.
Other things, depend on certain versions, so when you try to downgrade, portage may tell you you can't do that.

Code: Select all

Your "SLOT='nameofslot' emerge another-other-other-version-of-firefox --emptytree"

Does not do what you think it does.

Code: Select all

$ SLOT="foo" emerge sys-devel/gcc -1vp

These are the packages that would be merged, in order:

Calculating dependencies
Dependency resolution took 1.96 s (backtrack: 0/20).

[ebuild   R    ] sys-devel/gcc-13.2.1_p20231014:13::gentoo  USE="(cxx) fortran graphite lto nls nptl openmp (pie) sanitize ssp -ada (-cet) (-custom-cflags) -d -debug -default-stack-clash-protection -default-znow -doc (-fixed-point) -go -hardened (-ieee-long-double) -jit (-libssp) -modula2 (-multilib) -objc -objc++ -objc-gc (-pch) -pgo -systemtap -test -valgrind -vanilla -vtv -zstd" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Read the output as <category>/<package>-<version>:<slot>::<repo>, so that's sys-devel/gcc, version 13.2.1_p20231014 in slot 13 using the ebuild from the gentee repo.
The environment variable SLOT= is ignored.

If rust-bin does not work on musl, it should not be possible to install it there. That's a bug.
As you say the work around is to mask the -bin. That's dev-lang/rust-bin, not the virtual.

virtuals are a portage trick for dependency resolution. They do not install any code.
When several packages can satisfy a dependency, e.g. dev-lang/rust-bin and dev-lang/rust, the packages that need rust will depend on virtual/rust.
The virtual will list suitable packages in preference order. From virtual/rust ...

Code: Select all

RDEPEND="|| (
        ~dev-lang/rust-bin-${PV}[rustfmt?,${MULTILIB_USEDEP}]
        ~dev-lang/rust-${PV}[rustfmt?,${MULTILIB_USEDEP}]
)"

so the binary is preferred, as its listed first.

When the dependency resolver finds that the virtual is satisfied, it will not install anything.
You can mask dev-lang/rust-bin, so it not available, that will force dev-lang/rust to be built.

At world updates, give

Code: Select all

--exclude="dev-lang/rust"

and see if portage can find a dependency resolution without updating rust.
You may want to use

Code: Select all

--backtrack=500

to tell portage to try very hard to find a solution.

[Hu]

Im trying to avoid making too many forum posts at for relevant answers so sorry guys ima treat you like the IT guy gets treated at a party and ask you loads of questions in a disrespectful sounding way, not trying to be rude tbh

One simple way to be respectful of others' time is to make your messages accessible. Avoid abbreviations, such as tbh, which not all readers will expand as To Be Honest. Use proper punctuation and grammar. Make your message as easy to read as possible. Some of our readers are not native English speakers, and if your message is ambiguous, they may need to stop and study it to understand what you meant.

Use BBcode where possible. You started to write a list, but then put everything in one line.

Independent of that, make it easy for us to follow along. Tell us exact commands executed, and their full output.

Im stack on reemerging rust every 3 days because rust-bin is not working with with musl and emergin virtual/rust-x.x version gets deleted after some point with --depclean

This should not happen. What do you have in @world that depends on Rust?

I understand I could just mask the binned version but is a problem that popped 3 questions in my head

What about the bin version fails for you? What is the output of emerge --info on this system?

Is there a way to prevent globally any bin packages from installing?

Masks are the standard answer here. Binary packages completely unsuitable for an architecture should be blocked automatically by KEYWORDS.

(i have come to understand it is probably accept_lisence=-@BINARY-REDISTRIBUTABLE I just find it masks almost everything, neither am I sure that all bin packages end in -bin to mask */*-bin)

This will not work. The proper spelling is ACCEPT_LICENSE. The variable is case sensitive.

-bin is a convention, but not a requirement. Google Chrome is a notable deviant here.

is there a way to keep multiple versions on the system without them being umerged at some point in the future?

If multiple versions were installed concurrently, then they will only be removed when you permit it. What are you doing that removes them?

nothing like "package.keep"or "slot.keep" on man 5 portage and afaik you can only -w atom names not versions, unless I understand slotting wrong they get unmerged as well(otherwise my rust packages wouldn't get unmerged since they are automatically sloted when i emerge virtual/rust-x-y-z

I do not understand what you mean here. Can you show the commands involved?

lastly not as important question to the rest, how can i keep slots from unmerging if i did for example "SLOT='nameofslot' emerge another-other-other-version-of-firefox --emptytree" how can i prevent every package installed in that slot from unmerging in the future?

Any package in @world is protected from removal, to the extent that the atom in @world matches the best version in the slot being considered.

[coalms]

coalms,

We were all new to Gentoo once. Just when you get that hang of it, it changes. It seems like after 20 years, I'm still new

A few words on slotting.
Slotting is expensive in terms of developer time. Two different versions of the same package will want to install the same files. Slotting keeps the installed files apart.
Its not automatic.

gcc is slotted.

Code: Select all

[U] sys-devel/gcc
     Available versions:  
     (8.5.0) [M]8.5.0-r1^t
     (9.5.0) [M]9.5.0^t
     (10)   [M]10.5.0^t
     (11)   11.4.1_p20230622^t (~)11.4.1_p20230824^t **11.4.1_p20231116^t **11.4.1_p20231123^t **11.4.1_p20231130^t **11.5.9999*l^t
     (12)   12.3.1_p20230825^t **12.3.1_p20231117^t **12.3.1_p20231124^t **12.3.1_p20231201^t **12.4.9999*l^t
     (13)   13.2.1_p20230826^t{tbz2} (~)13.2.1_p20231014^t{tbz2,xpak:2} **13.2.1_p20231118^t **13.2.1_p20231125^t **13.3.9999*l^t
     (14)   **14.0.0_pre20231119^t **14.0.0_pre20231126^t **14.0.0.9999*l^t

Its possible to install one version in each slot. Prior to slot 10, slots were down to patch versions. That was dropped due to the maintenance burden.

Rust is not slotted, so you may only install one version at a time.

I though rust was in the (stable/v.e.r.s.i.o.n-.n.u.m.b.e.r) slot
what I understand from your explanation is that for your eix gcc example all version 14 atoms are in the same slot, same goes for all 13 12...9.5.0 being diffrent slots,rust is ignored because the slot is "stable" and the "/v.e.r.s.i.o.n" is a subslot, in which case portage ignores subslots?
lastly you didn't explicitly state it but the understanding I got is that slots are set inside ebuilds . So the SLOT environment variable is not AS pliable as other environment variables, making it mostly set in stone inside ebuilds.
Since I do tend to keep a few old programs from time to time I do not want updated, the best way for me to keep multiple versions on the same system if need be (other then this time) would be creating my own repo,eselect atoms and virtuals together with dependencies for said atoms.
I though portage was more flexible then that but I cannot really complain, I have not seen anything with this complexity and usability balance in any piece of software, cannot really complain for black magic not being able to do everything as I please

Thank you