gentoolkit | Any IT here? Help Me!

List all Gentoo packages built against the old Lua or specific version

After similar articles about Python (List all Gentoo packages built against the old python or specific version) under Gentoo and Ruby List all Gentoo packages built against the old ruby or specific version, the Lua upgrade in Gentoo may have similar problems, so this article shows how to list old Lua modules and packages built against old Lua environments. Despite a clean upgrade without any blockers or masked packages, sometimes, on old machines, there might be packages left still built against an old version of Lua, which is even no longer available on the system!

main menu — equery USE lua_targets_lua5-4

On Gentoo, there are two important flags in the configuration make.conf file:

LUA_SINGLE_TARGET="lua5-4"
LUA_TARGETS="lua5-1 lua5-4"

The LUA_TARGETS controls the support of multiple Lua versions installed on the system. When the Gentoo package has a use flag lua, the builder emerge will build the Lua module for all the Lua versions in LUA_TARGETS. Some programs or libraries may not support multiple versions to be installed on the system and they may require to specify just one Lua library target, against which they are going to be built and that’s why LUA_SINGLE_TARGET exists. In most cases, the LUA_SINGLE_TARGET should be the active (default in the system) Lua version.
Keep on reading!

List all Gentoo packages built against the old ruby or specific version

After a similar article about Python (List all Gentoo packages built against the old python or specific version) under Gentoo, the Ruby upgrade in Gentoo may have similar problems, so this article shows how to list old Ruby modules and packages build against old ruby environments. Despite a clean upgrade without any blockers or masked packages, sometimes, on old machines, there might be packages left still built against an old version of Ruby, which is no longer available on the system!

On Gentoo, there is one important flag in the configuration make.conf file:

RUBY_TARGETS="ruby30 ruby31"

The RUBY_TARGETS controls the support of multiple Ruby versions installed on the system. When the Gentoo package has a use flag ruby, the builder emerge will build the Ruby module for all the Ruby versions in RUBY_TARGETS.
Keep on reading!

List all Gentoo packages built against the old python or specific version

Updating python under Gentoo is not always straightforward work. Despite a clean upgrade without any blockers or masked packages, sometimes, on old machines, there might be packages left still built against an old version of python, which is no longer available on the system!

On Gentoo, there are two important flags in the configuration make.conf file:

PYTHON_TARGETS="python3_8 python3_10"
PYTHON_SINGLE_TARGET="python3_8"

The PYTHON_TARGETS and PYTHON_SINGLE_TARGET control the support of multiple Python versions installed on the system. When the Gentoo package has a use flag python, the builder emerge will build the python module for all the Python versions in PYTHON_TARGETS. Some programs or libraries may not support multiple versions to be installed on the system and they may require to specify just one Python library target, against which they are going to be built and that’s why PYTHON_SINGLE_TARGET exists. In most cases, the PYTHON_SINGLE_TARGET should be the active (default in the system) Python version.
Keep on reading!

Gentoo update tips when updating packages with blocks and masked files

It’s not so rear to have

blocks or masked files

when using Gentoo emerge system, but it is not complex and in most cases it is easy to resolve

To summarize it up at the beginning and then we are going to show you other articles using these advises here where you’ll see what are the steps we took to resolve the conflicts and masked packages:

Use verbose,verbose-conflicts and backtrack with emerge
Remove only big GUI packages, which have really big dependency graph like office suites or development IDEs
Remove obsolete packages – you do not need them, they can just make problems when updating, because emerge will take into consideration their requirements and dependencies and your update could be impossible!
Do not update everything with one line, you could update only the base libraries like QT, which are very important for the Linux GUI in general
Include explicitly packages, which block our updates in the emerge line! You could specify packages with the versions.
use tools like “equery” (part of app-portage/gentoolkit) for checking dependencies and/or which packages depend on the queried package. You can use it with specific version for the package. “qlist” (part of app-portage/portage-utils) also is a handful tool.
Sometimes when updating a group or a package with big dependency graph it is much easier to drop the -“u” update argument and to rebuild some packages with the updates.
In rear cases you can use “–nodeps” when updating or installing a new package (we do not need and show this one here!)
Do NOT rebuild the entire system with “emerge -v world” every time when you rebuild glibc, gcc, it is not mandatory to do it to have a healthy system.
Add or remove USE flags if needed – emerge will show you information about it. Use package.use, package.mask, package.unmask and so on.
use qlist to update/re(build) to pull currently installed packages with some name or category (categories)
```
emerge -v $(qlist -IC|grep <NAME>)
```
and for update just add “u” to “-v”:
```
emerge -vu $(qlist -IC|grep <NAME>)
```

Keep on reading!