| View previous topic :: View next topic |
| Author |
Message |
Slippery Jim
Apprentice
Joined: 08 Jan 2005
Posts: 281
|
 Posted: Fri Sep 27, 2024 1:44 pm Post subject: I want a complete dependency graph |
 |
|
Philosophical question, not a technical one:
Is there a good reason why many packages in portage still have an implicit dependency on @system, after more than 20 years of portage development?
I usually build binary packages into an empty target root. I have scripts that automate the process and test a given ebuild and its dependencies, one at a time, in order.
I often get configure or build failures on things that include header files from or link to @system packages, like gcc and glibc, because they're not listed explicitly as dependencies.
I maintain a private overlay, where I add in the missing dependencies, as I find them. This works well, but is tedious and time consuming to maintain.
So my question is why not just explicitly add the required dependencies to the ebuilds in question, and be done with it?
Is it just that no one wants to do it, or is there some advantage to having this implicit dependency, which is basically a catch-all that assumes your root is a full Gentoo install?
It seems to unnecessarily limit the use cases for portage to Gentoo alone, when it has the potential to be a great meta-distro tool, if only the dependency graph were complete. |
|
| Back to top |
|
 |
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9611
Location: beyond the rim
|
| Posted: Fri Sep 27, 2024 2:56 pm Post subject: Re: I want a complete dependency graph |
|
|
| Slippery Jim wrote: | Philosophical question, not a technical one:
Is there a good reason why many packages in portage still have an implicit dependency on @system, after more than 20 years of portage development? |
Just making an educated guess here:
For >95% of all use cases it would mean a lot of work to validate those low-level dependencies for no benefit. On the contrary it would make certain use cases more difficult. In particular if you think about stuff like supporting different libc implementations or toolchains (where virtuals don't really work) specifying dependencies explicitly can get pretty messy and is much easier handled via profiles.
Also keep in mind that @system isn't a fixed list of dependencies that you can just blindly copy+paste into ebuilds. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1967
|
| Posted: Fri Sep 27, 2024 3:00 pm Post subject: |
|
|
In addition to what Genone said, you don't know which compiler is even used at runtime. But it's also generally assumed that you will, in fact, have a compiler and a libc. Adding the dependency then doesn't actually serve much purpose.
There are some things where I think we should move towards explicitly stating the dependency more, but those two don't really have much value. Can you give other examples instead? |
|
| Back to top |
|
|
Slippery Jim
Apprentice
Joined: 08 Jan 2005
Posts: 281
|
| Posted: Fri Sep 27, 2024 5:03 pm Post subject: |
|
|
| sam_ wrote: | In addition to what Genone said, you don't know which compiler is even used at runtime. But it's also generally assumed that you will, in fact, have a compiler and a libc. Adding the dependency then doesn't actually serve much purpose.
There are some things where I think we should move towards explicitly stating the dependency more, but those two don't really have much value. Can you give other examples instead? |
My use case is that I'm building into a target root, so things like header files and shared libraries from other packages can be implicit dependencies of some ebuilds. This is stuff that needs to be in the target root in order for the package to build, so DEPEND rather than BDEPEND.
A current example is dev-libs/libfmt, which depends on features.h and linux/errno.h when configured on my system. Querying my build system tells me that features.h comes from glibc, and linux/errno.h comes from sys-kernel/linux-headers. I'm not a portage guru or anything, so I've just been adding them to DEPEND in the ebuild in question. It occurred to me that I could add the virtual libc or os-headers instead, but I think features.h is glibc specific, so I thought it best to keep things simple, and just add the direct dependency. Maybe I was wrong to do this, since I could be configuring a target root with a different libc or different kernel, etc.
To reiterate, I'm not talking about BDEPEND here. I'm trying to satisfy build-time dependencies that have to be installed into the target root. The goal is to build binary packages and install them somewhere else later. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1967
|
| Posted: Fri Sep 27, 2024 5:09 pm Post subject: |
|
|
Thank you for the elaboration! It's a usecase I do care about.
For linux-headers, dependencies should be added in DEPEND indeed. Please file bugs for those where it's missing. This is useful for a few reasons, not least because it's actually super helpful when bumping linux-headers to have a list of consumers to test.
For libfmt, I don't think it requires glibc at all (it builds fine on musl, as far as I'm aware), so it's harder there. Adding virtual/libc into DEPEND and RDEPEND into a million ebuilds isn't really worthwhile. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 227
|
| Posted: Fri Sep 27, 2024 5:21 pm Post subject: Re: I want a complete dependency graph |
|
|
| Slippery Jim wrote: |
Is it just that no one wants to do it, or is there some advantage to having this implicit dependency, which is basically a catch-all that assumes your root is a full Gentoo install?
It seems to unnecessarily limit the use cases for portage to Gentoo alone, when it has the potential to be a great meta-distro tool, if only the dependency graph were complete. |
It doesn't limit the use case for portage to Gentoo alone, at all. Perhaps you could argue that it limits the use case for the ::gentoo repository to Gentoo alone -- what packages are in your @system set is a repository policy, not a portage requirement, and what ebuilds refrain from listing dependencies in @system is also a repository policy.
The issue is just reusing the Gentoo ebuilds.
...
As far as listing complete dependencies goes, stuff like e2fsprogs, kmod, wget, virtual/ssh, rsync, are in @system and you may be right that they should be carefully listed where required. But your examples of problematic dependencies are TBH bad examples, because source ebuilds don't generally depend on gcc or glibc at all, witness the LLVM profile and the musl profile. It's the kind of thing that might make sense for a precompiled binary copy of proprietary software. Actually, portage already adds sys-libs/glibc dependencies into compiled binhost packages for you though!
And it really does not make the remotest bit of sense IMO to have every package that installs shell scripts, list all of:
| Code: |
app-alternatives/awk
app-alternatives/sh
sys-apps/coreutils
sys-apps/diffutils
sys-apps/file
sys-apps/findutils
sys-apps/grep
sys-apps/sed
|
dependencies, just because the script uses a POSIX shell and relies on POSIX mandated utilities to be installed.
It is litigious busywork to want those dependencies fully expressed. Possibly the only conceivable use case and not a very good use case at that is if you want to use portage to install a bare metal kiosk application that boots directly into the application and it is of critical business importance to avoid the 1mb overhead of having sed installed but not used after you vetted the scripts in question and determined that while many other POSIX utilities were used, sed was not.
Such people should simply have their kiosk application run on an embedded memory card with an additional 1mb of memory.
The real issue is figuring out the balance between the two extremes. For example, stuff like https://bugs.gentoo.org/show_bug.cgi?id=which-hunt |
|
| Back to top |
|
|
Slippery Jim
Apprentice
Joined: 08 Jan 2005
Posts: 281
|
| Posted: Sat Sep 28, 2024 1:37 pm Post subject: |
|
|
| sam_ wrote: | Thank you for the elaboration! It's a usecase I do care about.
For linux-headers, dependencies should be added in DEPEND indeed. Please file bugs for those where it's missing. This is useful for a few reasons, not least because it's actually super helpful when bumping linux-headers to have a list of consumers to test.
For libfmt, I don't think it requires glibc at all (it builds fine on musl, as far as I'm aware), so it's harder there. Adding virtual/libc into DEPEND and RDEPEND into a million ebuilds isn't really worthwhile. |
A little more detail:
libfmt failed on features.h:
| Code: |
-- Generating done (0.0s)
-- Build files have been written to: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
ninja -v -j16 -l14.4
[1/4] /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/os.cc.o -MF CMakeFiles/fmt.dir/src/os.cc.o.d -o CMakeFiles/fmt.dir/src/os.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/w
ork/fmt-9.1.0/src/os.cc
FAILED: CMakeFiles/fmt.dir/src/os.cc.o
/usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/os.cc.o -MF CMakeFiles/fmt.dir/src/os.cc.o.d -o CMakeFiles/fmt.dir/src/os.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fm
t-9.1.0/src/os.cc
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/x86_64-pc-linux-gnu/bits/c++config.h:679,
from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/cerrno:41,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include/fmt/os.h:11,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/os.cc:13:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/x86_64-pc-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory
39 | #include <features.h>
| ^~~~~~~~~~~~
compilation terminated.
[2/4] /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/format.cc.o -MF CMakeFiles/fmt.dir/src/format.cc.o.d -o CMakeFiles/fmt.dir/src/format.cc.o -c /var/tmp/portage/dev-libs/libfm
t-9.1.0-r1/work/fmt-9.1.0/src/format.cc
FAILED: CMakeFiles/fmt.dir/src/format.cc.o
/usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/format.cc.o -MF CMakeFiles/fmt.dir/src/format.cc.o.d -o CMakeFiles/fmt.dir/src/format.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.
0-r1/work/fmt-9.1.0/src/format.cc
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/x86_64-pc-linux-gnu/bits/c++config.h:679,
from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/stl_algobase.h:59,
from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/algorithm:60,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include/fmt/format-inl.h:11,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/format.cc:8:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/x86_64-pc-linux-gnu/bits/os_defines.h:39:10: fatal error: features.h: No such file or directory
39 | #include <features.h>
| ^~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
* ERROR: dev-libs/libfmt-9.1.0-r1::gentoo failed (compile phase):
* ninja -v -j16 -l14.4 failed
*
* Call stack:
* ebuild.sh, line 136: Called src_compile
* environment, line 2086: Called cmake_src_compile
* environment, line 842: Called cmake_build
* environment, line 809: Called eninja
* environment, line 1284: Called die
* The specific snippet of code:
* "$@" || die -n "${*} failed"
*
* If you need support, post the output of `emerge --info '=dev-libs/libfmt-9.1.0-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv '=dev-libs/libfmt-9.1.0-r1::gentoo'`.
* The complete build log is located at '/var/tmp/log/dev-libs:libfmt-9.1.0-r1:20240927-142008.log'.
* For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/temp/environment'.
* Working directory: '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build'
* S: '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0'
|
equery b features.h identified glibc as the owner. I added this to DEPEND in the ebuild for libfmt.
libfmt then failed on linux/errno.h:
| Code: |
* Package: dev-libs/libfmt-9.1.0-r1:0/9.1.0
* Repository: local
* Maintainer: candrews@gentoo.org
* Upstream: https://github.com/fmtlib/fmt/issues
* USE: abi_x86_64 amd64 elibc_glibc kernel_linux
* FEATURES: fakeroot network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking libfmt-9.1.0.tar.gz to /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work
>>> Source unpacked in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work
>>> Preparing source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
cmake -C /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DFMT_CMAKE_DIR=lib64/cmake/fmt -DFMT_LIB_DIR=lib64 -DFMT_TEST=no -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build/gentoo_toolchain.cmake /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0
loading initial cache file /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build/gentoo_common_config.cmake
-- CMake version: 3.28.5
-- The CXX compiler identification is GNU 13.3.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Module support is disabled.
-- Version: 9.1.0
-- Build type: RelWithDebInfo
-- CXX_STANDARD: 11
-- Performing Test has_std_11_flag
-- Performing Test has_std_11_flag - Success
-- Performing Test has_std_0x_flag
-- Performing Test has_std_0x_flag - Success
-- Required features: cxx_variadic_templates
-- Target 'doc' disabled (requires doxygen)
-- <<< Gentoo configuration >>>
Build type RelWithDebInfo
Install path /usr
Compiler flags:
C
C++ -O2 -pipe -march=native
Linker flags:
Executable -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
Module -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
Shared -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
-- Configuring done (0.6s)
-- Generating done (0.0s)
-- Build files have been written to: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
ninja -v -j16 -l14.4
[1/4] /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/os.cc.o -MF CMakeFiles/fmt.dir/src/os.cc.o.d -o CMakeFiles/fmt.dir/src/os.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/os.cc
FAILED: CMakeFiles/fmt.dir/src/os.cc.o
/usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/os.cc.o -MF CMakeFiles/fmt.dir/src/os.cc.o.d -o CMakeFiles/fmt.dir/src/os.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/os.cc
In file included from /mnt/software/gentoo-target/root/usr/include/errno.h:28,
from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/cerrno:42,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include/fmt/os.h:11,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/os.cc:13:
/mnt/software/gentoo-target/root/usr/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory
26 | # include <linux/errno.h>
| ^~~~~~~~~~~~~~~
compilation terminated.
[2/4] /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/format.cc.o -MF CMakeFiles/fmt.dir/src/format.cc.o.d -o CMakeFiles/fmt.dir/src/format.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/format.cc
FAILED: CMakeFiles/fmt.dir/src/format.cc.o
/usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/format.cc.o -MF CMakeFiles/fmt.dir/src/format.cc.o.d -o CMakeFiles/fmt.dir/src/format.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/format.cc
In file included from /mnt/software/gentoo-target/root/usr/include/errno.h:28,
from /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/cerrno:42,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include/fmt/format-inl.h:13,
from /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/format.cc:8:
/mnt/software/gentoo-target/root/usr/include/bits/errno.h:26:11: fatal error: linux/errno.h: No such file or directory
26 | # include <linux/errno.h>
| ^~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
* ERROR: dev-libs/libfmt-9.1.0-r1::local failed (compile phase):
* ninja -v -j16 -l14.4 failed
*
* Call stack:
* ebuild.sh, line 136: Called src_compile
* environment, line 2086: Called cmake_src_compile
* environment, line 842: Called cmake_build
* environment, line 809: Called eninja
* environment, line 1284: Called die
* The specific snippet of code:
* "$@" || die -n "${*} failed"
*
* If you need support, post the output of `emerge --info '=dev-libs/libfmt-9.1.0-r1::local'`,
* the complete build log and the output of `emerge -pqv '=dev-libs/libfmt-9.1.0-r1::local'`.
* The complete build log is located at '/var/tmp/log/dev-libs:libfmt-9.1.0-r1:20240927-142336.log'.
* For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/temp/environment'.
* Working directory: '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build'
* S: '/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0'
|
equery b features.h identified linux-headers and gentoo-sources as owners. I added linux-headers to DEPEND in the ebuild for libfmt.
Now it builds cleanly:
| Code: |
* Package: dev-libs/libfmt-9.1.0-r1:0/9.1.0
* Repository: local
* Maintainer: candrews@gentoo.org
* Upstream: https://github.com/fmtlib/fmt/issues
* USE: abi_x86_64 amd64 elibc_glibc kernel_linux
* FEATURES: fakeroot network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking libfmt-9.1.0.tar.gz to /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work
>>> Source unpacked in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work
>>> Preparing source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
cmake -C /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build/gentoo_common_config.cmake -G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DFMT_CMAKE_DIR=lib64/cmake/fmt -DFMT_LIB_DIR=lib64 -DFMT_TEST=no -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build/gentoo_toolchain.cmake /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0
loading initial cache file /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build/gentoo_common_config.cmake
-- CMake version: 3.28.5
-- The CXX compiler identification is GNU 13.3.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Module support is disabled.
-- Version: 9.1.0
-- Build type: RelWithDebInfo
-- CXX_STANDARD: 11
-- Performing Test has_std_11_flag
-- Performing Test has_std_11_flag - Success
-- Performing Test has_std_0x_flag
-- Performing Test has_std_0x_flag - Success
-- Required features: cxx_variadic_templates
-- Target 'doc' disabled (requires doxygen)
-- <<< Gentoo configuration >>>
Build type RelWithDebInfo
Install path /usr
Compiler flags:
C
C++ -O2 -pipe -march=native
Linker flags:
Executable -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
Module -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
Shared -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
-- Configuring done (0.5s)
-- Generating done (0.0s)
-- Build files have been written to: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0 ...
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
ninja -v -j16 -l14.4
[1/4] /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/os.cc.o -MF CMakeFiles/fmt.dir/src/os.cc.o.d -o CMakeFiles/fmt.dir/src/os.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/os.cc
[2/4] /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -DFMT_EXPORT -Dfmt_EXPORTS -I/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/include -O2 -pipe -march=native -std=gnu++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT CMakeFiles/fmt.dir/src/format.cc.o -MF CMakeFiles/fmt.dir/src/format.cc.o.d -o CMakeFiles/fmt.dir/src/format.cc.o -c /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0/src/format.cc
[3/4] : && /usr/bin/x86_64-pc-linux-gnu-g++ --sysroot=/mnt/software/gentoo-target/root -fPIC -O2 -pipe -march=native -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -shared -Wl,-soname,libfmt.so.9 -o libfmt.so.9.1.0 CMakeFiles/fmt.dir/src/format.cc.o CMakeFiles/fmt.dir/src/os.cc.o && :
[4/4] /usr/bin/cmake -E cmake_symlink_library libfmt.so.9.1.0 libfmt.so.9 libfmt.so && :
>>> Source compiled.
* Skipping make test/check due to ebuild restriction.
>>> Test phase [disabled because of RESTRICT=test]: dev-libs/libfmt-9.1.0-r1
>>> Install dev-libs/libfmt-9.1.0-r1 into /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image
* Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0"
* Build directory (BUILD_DIR): "/var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build"
ninja -v -j16 -l14.4 install
[0/1] cd /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/work/fmt-9.1.0_build && /usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "RelWithDebInfo"
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/libfmt.so.9.1.0
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/libfmt.so.9
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/libfmt.so
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/args.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/chrono.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/color.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/compile.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/core.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/format.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/format-inl.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/os.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/ostream.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/printf.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/ranges.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/std.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/include/fmt/xchar.h
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/cmake/fmt/fmt-config.cmake
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/cmake/fmt/fmt-config-version.cmake
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/cmake/fmt/fmt-targets.cmake
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake
-- Installing: /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image/usr/lib64/pkgconfig/fmt.pc
>>> Completed installing dev-libs/libfmt-9.1.0-r1 into /var/tmp/portage/dev-libs/libfmt-9.1.0-r1/image
* Final size of build directory: 4424 KiB (4.3 MiB)
* Final size of installed tree: 756 KiB
* QA Notice: Unresolved soname dependencies:
*
* /usr/lib64/libfmt.so.9.1.0: libgcc_s.so.1 libstdc++.so.6
*
strip: x86_64-pc-linux-gnu-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version
/usr/lib64/libfmt.so.9.1.0
./
./usr/
./usr/share/
./usr/share/doc/
./usr/share/doc/libfmt-9.1.0-r1/
./usr/share/doc/libfmt-9.1.0-r1/README.rst.bz2
./usr/include/
./usr/include/fmt/
./usr/include/fmt/xchar.h
./usr/include/fmt/std.h
./usr/include/fmt/ranges.h
./usr/include/fmt/printf.h
./usr/include/fmt/ostream.h
./usr/include/fmt/os.h
./usr/include/fmt/format-inl.h
./usr/include/fmt/format.h
./usr/include/fmt/core.h
./usr/include/fmt/compile.h
./usr/include/fmt/color.h
./usr/include/fmt/chrono.h
./usr/include/fmt/args.h
./usr/lib64/
./usr/lib64/pkgconfig/
./usr/lib64/pkgconfig/fmt.pc
./usr/lib64/cmake/
./usr/lib64/cmake/fmt/
./usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake
./usr/lib64/cmake/fmt/fmt-targets.cmake
./usr/lib64/cmake/fmt/fmt-config-version.cmake
./usr/lib64/cmake/fmt/fmt-config.cmake
./usr/lib64/libfmt.so
./usr/lib64/libfmt.so.9
./usr/lib64/libfmt.so.9.1.0
>>> Done.
* checking 22 files for package collisions
>>> Merging dev-libs/libfmt-9.1.0-r1 to /mnt/software/gentoo-target/root/
--- /mnt/software/gentoo-target/root/usr/
--- /mnt/software/gentoo-target/root/usr/lib64/
>>> /mnt/software/gentoo-target/root/usr/lib64/libfmt.so.9.1.0
>>> /mnt/software/gentoo-target/root/usr/lib64/libfmt.so.9 -> libfmt.so.9.1.0
>>> /mnt/software/gentoo-target/root/usr/lib64/libfmt.so -> libfmt.so.9
>>> /mnt/software/gentoo-target/root/usr/lib64/cmake/
>>> /mnt/software/gentoo-target/root/usr/lib64/cmake/fmt/
>>> /mnt/software/gentoo-target/root/usr/lib64/cmake/fmt/fmt-config.cmake
>>> /mnt/software/gentoo-target/root/usr/lib64/cmake/fmt/fmt-config-version.cmake
>>> /mnt/software/gentoo-target/root/usr/lib64/cmake/fmt/fmt-targets.cmake
>>> /mnt/software/gentoo-target/root/usr/lib64/cmake/fmt/fmt-targets-relwithdebinfo.cmake
--- /mnt/software/gentoo-target/root/usr/lib64/pkgconfig/
>>> /mnt/software/gentoo-target/root/usr/lib64/pkgconfig/fmt.pc
--- /mnt/software/gentoo-target/root/usr/include/
>>> /mnt/software/gentoo-target/root/usr/include/fmt/
>>> /mnt/software/gentoo-target/root/usr/include/fmt/args.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/chrono.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/color.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/compile.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/core.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/format.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/format-inl.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/os.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/ostream.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/printf.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/ranges.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/std.h
>>> /mnt/software/gentoo-target/root/usr/include/fmt/xchar.h
--- /mnt/software/gentoo-target/root/usr/share/
--- /mnt/software/gentoo-target/root/usr/share/doc/
>>> /mnt/software/gentoo-target/root/usr/share/doc/libfmt-9.1.0-r1/
>>> /mnt/software/gentoo-target/root/usr/share/doc/libfmt-9.1.0-r1/README.rst.bz2
>>> dev-libs/libfmt-9.1.0-r1 merged.
>>> Regenerating /mnt/software/gentoo-target/root/etc/ld.so.cache...
/mnt/software/gentoo-target/root/sbin/ldconfig: need absolute file name for configuration file when using -r
!!! ldconfig failed with exit status 1
|
|
|
| Back to top |
|
|
Slippery Jim
Apprentice
Joined: 08 Jan 2005
Posts: 281
|
| Posted: Sat Sep 28, 2024 5:15 pm Post subject: Re: I want a complete dependency graph |
|
|
| eschwartz wrote: |
It doesn't limit the use case for portage to Gentoo alone, at all. Perhaps you could argue that it limits the use case for the ::gentoo repository to Gentoo alone -- what packages are in your @system set is a repository policy, not a portage requirement, and what ebuilds refrain from listing dependencies in @system is also a repository policy.
The issue is just reusing the Gentoo ebuilds.
|
Yes, sorry. I should have been more specific. It's the ::gentoo repository I want a full graph for. Exactly so I don't have to maintain and sync a parallel repo like I am now.
| Quote: |
...
As far as listing complete dependencies goes, stuff like e2fsprogs, kmod, wget, virtual/ssh, rsync, are in @system and you may be right that they should be carefully listed where required. But your examples of problematic dependencies are TBH bad examples, because source ebuilds don't generally depend on gcc or glibc at all, witness the LLVM profile and the musl profile.
|
I'll agree my example wasn't selected for generality; it was just the last thing that failed to build, so I grabbed it for the post. I should probably be adding the virtuals to DEPEND instead, since they're supposed to resolve exactly the issue you highlighted wrt different profiles.
| Quote: |
It's the kind of thing that might make sense for a precompiled binary copy of proprietary software. Actually, portage already adds sys-libs/glibc dependencies into compiled binhost packages for you though!
|
Now that is interesting! I did not know that portage added glibc (or is it virtual/libc?) as an RDEPEND to binary packages. Thank you!
| Quote: |
And it really does not make the remotest bit of sense IMO to have every package that installs shell scripts, list all of:
| Code: |
app-alternatives/awk
app-alternatives/sh
sys-apps/coreutils
sys-apps/diffutils
sys-apps/file
sys-apps/findutils
sys-apps/grep
sys-apps/sed
|
dependencies, just because the script uses a POSIX shell and relies on POSIX mandated utilities to be installed.
|
Isn't that similar to what packages with python scripts do?
| Quote: |
It is litigious busywork to want those dependencies fully expressed.
|
I respectfully disagree. From a practical perspective, it's certainly tedious and expensive in terms of opportunity cost to actually go through thousands of ebuilds and adjust the dependencies to complete the graph. But from an ideological perspective, wanting a complete graph is perfectly natural. I think a complete graph is the best case state. It allows portage to guarantee that all necessary and only necessary dependencies are installed for both building and running a package. The problem I see with implicit dependencies is precisely that portage does not know about them, and so can't tell you what's wrong when, for example, you remove a package in the @system set and something breaks.
| Quote: |
Possibly the only conceivable use case and not a very good use case at that is if you want to use portage to install a bare metal kiosk application that boots directly into the application and it is of critical business importance to avoid the 1mb overhead of having sed installed but not used after you vetted the scripts in question and determined that while many other POSIX utilities were used, sed was not.
|
Or any custom @world set you like with just the tools and apps you want in that image, and absolutely nothing else. Minimal attack surface, the best part is no part, and all that.
| Quote: |
Such people should simply have their kiosk application run on an embedded memory card with an additional 1mb of memory.
|
So, more hardware as a workaround?
We wouldn't have to do the whole thing at once. One could fix the DEPEND graph first, so that at least packages would build into a target root cleanly, even if they still required a full @system at runtime. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1967
|
| Posted: Sat Sep 28, 2024 5:24 pm Post subject: |
|
|
The features.h thing is awkward as that's coming from libstdc++.
But your linux-headers thing is actually again an awkward one. Because it's not libfmt needing it, it's glibc's headers. We're then into the realm of "build-against" dependencies ("BADEPEND") where you don't actually need linux-headers in glibc's RDEPEND, but you do need linux-headers if building against glibc headers. Working around this in libfmt isn't the right solution. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22658
|
| Posted: Sat Sep 28, 2024 6:34 pm Post subject: Re: I want a complete dependency graph |
|
|
| Slippery Jim wrote: | | Now that is interesting! I did not know that portage added glibc (or is it virtual/libc?) as an RDEPEND to binary packages. Thank you! |
This was added in Inject implicit libc dependency to RDEPEND. | Slippery Jim wrote: | | Isn't that similar to what packages with python scripts do? |
Python script packages need to be explicit about their consumed Python version, because they install the script for specific Python versions. For scripts that call common utilities, it is likely rare that the script cares about a specific version of the utility. |
|
| Back to top |
|
|
Slippery Jim
Apprentice
Joined: 08 Jan 2005
Posts: 281
|
| Posted: Sun Sep 29, 2024 1:36 am Post subject: |
|
|
| sam_ wrote: | The features.h thing is awkward as that's coming from libstdc++.
|
Oh, from gcc's os_defines.h, I see it now.
| Quote: |
But your linux-headers thing is actually again an awkward one. Because it's not libfmt needing it, it's glibc's headers. We're then into the realm of "build-against" dependencies ("BADEPEND") where you don't actually need linux-headers in glibc's RDEPEND, but you do need linux-headers if building against glibc headers.
|
BADEPEND seems like a BADIDEA. Looking at https://wiki.gentoo.org/wiki/Future_EAPI/New_dependency_types, and the post it references for CDEPEND https://public-inbox.gentoo.org/gentoo-dev/?x=t&q=xarchiveshash:db4986470a316a3653bfecd593d5007b, it sounds like an invitation to have broken header files installed. Only ebuilds would be able to build against those packages. A normal user with a project source file that included a broken header would get compile-time errors, but wrapping the project in an ebuild that DEPENDs on the owner of that header would magically fix the errors, no?
| Quote: |
Working around this in libfmt isn't the right solution. |
I was going to agree, but after thinking it through, I'm not so sure. The headers aren't broken on the build system. It's only when the user passes that --sysroot flag to g++ that things start to break down. The user is responsible for that flag, so it should be the user's responsibility to ensure that the required headers are in the target-root. Consider that libfmt links to libstdc++. Then libstdc++ is effectively a runtime dependency of libfmt, right? So libfmt depends on sys-devel/gcc to run, since we can't split the C++ runtime out, AFAICT. If we add sys-devel/gcc to libfmt's RDEPEND list, then gcc will pull all the necessary things into the target root, in particular, glibc and os-headers. Is this not the correct way to address the issue in this use case? |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1967
|
| Posted: Sun Sep 29, 2024 1:46 am Post subject: |
|
|
| Slippery Jim wrote: | | sam_ wrote: | The features.h thing is awkward as that's coming from libstdc++.
|
Oh, from gcc's os_defines.h, I see it now.
| Quote: |
But your linux-headers thing is actually again an awkward one. Because it's not libfmt needing it, it's glibc's headers. We're then into the realm of "build-against" dependencies ("BADEPEND") where you don't actually need linux-headers in glibc's RDEPEND, but you do need linux-headers if building against glibc headers.
|
BADEPEND seems like a BADIDEA. Looking at https://wiki.gentoo.org/wiki/Future_EAPI/New_dependency_types, and the post it references for CDEPEND https://public-inbox.gentoo.org/gentoo-dev/?x=t&q=xarchiveshash:db4986470a316a3653bfecd593d5007b, it sounds like an invitation to have broken header files installed. Only ebuilds would be able to build against those packages. A normal user with a project source file that included a broken header would get compile-time errors, but wrapping the project in an ebuild that DEPENDs on the owner of that header would magically fix the errors, no?
|
No, we're not discussing sandboxing which hides the headers. This is purely about being able to express the dependency accurately for e.g. binpkgs (so they don't have unnecessary deps pulled in *in case* you want to build against it). The dep would be just as controllable as --with-bdeps is now. It would likely even default to being on given it's not intuitive. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1967
|
| Posted: Sun Sep 29, 2024 1:49 am Post subject: |
|
|
| Slippery Jim wrote: | | sam_ wrote: | The features.h thing is awkward as that's coming from libstdc++.
|
| Quote: |
Working around this in libfmt isn't the right solution. |
I was going to agree, but after thinking it through, I'm not so sure. The headers aren't broken on the build system. It's only when the user passes that --sysroot flag to g++ that things start to break down. The user is responsible for that flag, so it should be the user's responsibility to ensure that the required headers are in the target-root. Consider that libfmt links to libstdc++. Then libstdc++ is effectively a runtime dependency of libfmt, right? So libfmt depends on sys-devel/gcc to run, since we can't split the C++ runtime out, AFAICT. If we add sys-devel/gcc to libfmt's RDEPEND list, then gcc will pull all the necessary things into the target root, in particular, glibc and os-headers. Is this not the correct way to address the issue in this use case? |
I don't think it can possibly be right to have every single libstdc++ consumer workaround it. The issue is what was mentioned earlier -- you can't actually know if the user is even using GCC to build it. They could be using Clang with non-default libcxx. But yes, you're right about libstdc++ being a runtime dependency, of course. But so is libgcc for many packages - and you often can't know ahead of time whether libgcc is actually needed, because it depends on the optimisations the compiler was able to perform. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
