Gentoo Forums :: View topic - Can't 'emerge --depclean' because of some Perl conflict

Can't 'emerge --depclean' because of some Perl conflict

View unanswered posts
View posts from last 24 hours

Gentoo Forums Forum Index

Portage & Programming

View previous topic :: View next topic

Author

Message

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Wed Sep 04, 2024 8:18 am Post subject: Can't 'emerge --depclean' because of some Perl conflict

Hi folks

I just did `emerge ... @world` to update my system. I had to mask the kicad package, to prevent it rebuilding, as this monster takes 2-3 days to compile. At the time of the update, `emerge` said this:

Code:

dev-lang/perl:0

(dev-lang/perl-5.40.0-1:0/5.40::gentoo, binary scheduled for merge) USE="gdbm -berkdb -doc -minimal" ABI_X86="(64)" PERL_FEATURES="(-debug) -ithreads -quadmath" pulled in by
dev-lang/perl:0/5.40= required by (virtual/perl-Encode-3.210.0-r1-1:0/0::gentoo, binary scheduled for merge) USE="" ABI_X86="(64)"
^^^^^^^^
=dev-lang/perl-5.40* required by (virtual/perl-libnet-3.150.0-r1-1:0/0::gentoo, installed) USE="ssl" ABI_X86="(64)"
^ ^^^^^
(and 19 more with the same problems)

(dev-lang/perl-5.38.2-r3-1:0/5.38::gentoo, installed) USE="gdbm -berkdb -doc -minimal" ABI_X86="(64)" PERL_FEATURES="(-debug) -ithreads -quadmath" pulled in by
=dev-lang/perl-5.38* required by (virtual/perl-IO-1.520.0-1:0/0::gentoo, installed) USE="" ABI_X86="(64)"
^ ^^^^^
dev-lang/perl:0/5.38= required by (dev-perl/Mozilla-CA-20999999-r1-2:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PERL_FEATURES="(-debug) -ithreads -quadmath"
^^^^^^^^
(and 28 more with the same problems)

I ignored this and carried on, and the update appeared to be successful.

But now I can't run `emerge --depclean` to tidy up. I get this:

Code:

Calculating dependencies... done!
* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* dev-lang/perl:0/5.38= pulled in by:
* virtual/perl-Getopt-Long-2.540.0
*

This is followed by about a hundred pages of warning related to the same Perl package.

I can still '--depclean' explicit packages, so I guess my system isn't completely broken. But I can't tidy up after the update, and I have no idea how to recover from this situation (or whether I need to).

Suggestions welcome.

BR, Lars.

sam_
Developer

Joined: 14 Aug 2020
Posts: 1949

Posted: Wed Sep 04, 2024 8:19 am Post subject:

You've snipped out the part where depclean tells you a command to try run.

sMueggli
Guru
Guru

Joined: 03 Sep 2022
Posts: 489

Posted: Wed Sep 04, 2024 8:22 am Post subject: Re: Can't 'emerge --depclean' because of some Perl conflict

lars_the_bear wrote:

I just did `emerge ... @world` to update my system.

Really?

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Wed Sep 04, 2024 8:33 am Post subject:

sam_ wrote:

You've snipped out the part where depclean tells you a command to try run.

I'm entirely sure what you mean. `emerge` does say to run:

Code:

emerge --update --newuse --deep --with-bdeps=y @world

I don't really understand how that's different from what I just did to update (emerge -avuDN --getbinpkg @world). Clearly it is different, though, because it wants to update a heap of stuff. But not sure I want to do that, because:

Code:

[ebuild U ] dev-lang/rust-bin-1.79.0 [1.77.1]
[ebuild U ] virtual/rust-1.79.0 [1.77.1]

!!! The following binary packages have been ignored due to non matching USE:

=virtual/rust-1.79.0 -profiler
=dev-lang/rust-bin-1.79.0 -profiler

Can you (or anybody) explain what's going on here, in numpty language that I stand any chance of understanding? Why does it want to install rust and rust-bin? I don't want to build rust from source on a 10-year-old laptop, and I don't use rust, anway.

BR, Lars.

sam_
Developer

Joined: 14 Aug 2020
Posts: 1949

Posted: Wed Sep 04, 2024 8:47 am Post subject:

The difference is --with-bdeps=y because world upgrades with partial binpkgs use won't upgrade build-only dependencies unnecessarily. Also, virtual/rust is not real Rust, it's a fake package.

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Wed Sep 04, 2024 9:54 am Post subject:

sam_ wrote:

The difference is --with-bdeps=y because world upgrades with partial binpkgs use won't upgrade build-only dependencies unnecessarily. Also, virtual/rust is not real Rust, it's a fake package.

OK, thanks. Am I just doing updates wrong? I just do

Code:

emerge -avuDN @world

because that's what the documentation says. Is that wrong? When I did the '--with-bdeps=y' thing, it updated another 71 packages.

I don't know know 'partial binpkgs' are, and I suspect I wouldn't understand if you explained

BR, Lars.

petr2008
Tux's lil' helper

Joined: 03 Jan 2008
Posts: 124
Location: Prague, cz

Posted: Wed Sep 04, 2024 9:56 am Post subject: Re: Can't 'emerge --depclean' because of some Perl conflict

I masked also old perl:

Code:

cat package.mask
=dev-lang/perl-5.38.2-r3:0/5.38::gentoo

and I went successfully through emerge --depclean and revdep-rebuild

Hu
Administrator

Joined: 06 Mar 2007
Posts: 22618

Posted: Wed Sep 04, 2024 11:36 am Post subject:

lars_the_bear wrote:

sam_ wrote:

You've snipped out the part where depclean tells you a command to try run.

I'm entirely sure what you mean. `emerge` does say to run:

Code:

emerge --update --newuse --deep --with-bdeps=y @world

I don't really understand how that's different from what I just did to update (emerge -avuDN --getbinpkg @world).

As I read the manual page (man emerge), it is different because --getbinpkg implies --usepkg, and --usepkg implicitly disables --with-bdeps if not set by the user. Therefore, you were not updating build dependencies, and that caused a problem. The command sam_ referred you to will explicitly include build dependencies.

lars_the_bear wrote:

Code:

[ebuild U ] dev-lang/rust-bin-1.79.0 [1.77.1]
[ebuild U ] virtual/rust-1.79.0 [1.77.1]

Can you (or anybody) explain what's going on here, in numpty language that I stand any chance of understanding?

What is wrong with installing rust-bin? As the name says, it is a -bin package, meaning that you are just downloading a blob of files built by upstream. You don't build anything. (Rust is really bad in this regard, in that if you did want to build it, you'd need to install it before you can build it.)

lars_the_bear wrote:

I don't use rust, anway.

Something you installed uses it, or at least claims to. What is the output of emerge --pretend --verbose --depclean virtual/rust dev-lang/rust-bin?

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Wed Sep 04, 2024 12:16 pm Post subject:

Hu wrote:

As I read the manual page (man emerge), it is different because --getbinpkg implies --usepkg, and --usepkg implicitly disables --with-bdeps if not set by the user.

Thanks. Fair enough. So what should I do if I want to perform a regular update, and insist that emerge use binary packages if they are available? Is that where I need to use `--with-bdeps`? I don't seem to get binaries if I specify neither --with-bdpeps nor --getbinpkg. Perhaps I should be using --usepkg rather than --getbinpkg? The manual descriptions for these switches all look pretty similar to me.

As for rust, it seems that I'm getting rust because librsvg depends on it, and a whole bunch of stuff depends on librsvg.

Now... librsvg is written in Rust, but I wasn't aware that Rust had run-time dependencies, as Java does. But I've never knowingly used Rust, so maybe I'm mistaken? But 'ldd librsvg.so' doesn't show anything that I immediately connect to Rust.

BR, Lars.

GDH-gentoo
Veteran
Veteran

Joined: 20 Jul 2019
Posts: 1686
Location: South America

Posted: Wed Sep 04, 2024 3:46 pm Post subject:

lars_the_bear wrote:

As for rust, it seems that I'm getting rust because librsvg depends on it, and a whole bunch of stuff depends on librsvg.

Very likely.

lars_the_bear wrote:

Now... librsvg is written in Rust, [...] But 'ldd librsvg.so' doesn't show anything that I immediately connect to Rust.

If I remember correctly, for this particular shared library (isn't librsvg-2.so the real name?) the compiled Rust code is linked statically, so nothing Rust-related would show up in the output of ldd.
_________________

NeddySeagoon wrote:

I'm not a witch, I'm a retired electronics engineer

Ionen wrote:

As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Thu Sep 05, 2024 6:48 am Post subject:

GDH-gentoo wrote:

That would be my understanding as well. So why does librsvg declare a dependency on Rust? Is this just a mistake?

BR, Lars.

Hu
Administrator

Joined: 06 Mar 2007
Posts: 22618

Posted: Thu Sep 05, 2024 12:46 pm Post subject:

Why do you think it is a mistake? The upstream librsvg project is very clear that they use Rust as part of their build process, so listing rust as a build-time dependency (BDEPEND) is correct. Are you saying you see a version of librsvg with an RDEPEND relation on rust? What is the output of emerge --pretend --verbose --depclean --with-bdeps=n virtual/rust dev-lang/rust dev-lang/rust-bin?

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Thu Sep 05, 2024 1:51 pm Post subject:

Hu wrote:

Why do you think it is a mistake? The upstream librsvg project is very clear that they use Rust as part of their build process, so listing rust as a build-time dependency (BDEPEND) is correct.

Sure. But I'm installing the binary rust-bin, so why does emerge care what the build-time dependency is? The library is written in Rust, so I completely understand the build-time dependency. But I'm not building the library, so far as I know, and never have.

Code:

$ emerge --pretend librsvg
[binary R ] gnome-base/librsvg-2.57.3-1

I'm probably just being dim, as usual, but why would emerge need to satisfy a built-time dependency for a package that isn't actually being built?

BR, Lars.

Hu
Administrator

Joined: 06 Mar 2007
Posts: 22618

Posted: Thu Sep 05, 2024 2:08 pm Post subject:

You probably told it to do so. Without more information about your environment, it is difficult to say. I have repeatedly asked for output that I think could help answer your question, and you keep responding without providing that output or explaining why you are not providing it. We can offer guesses, but unless you answer our questions, they're just speculation about what you might have done and what might happen as a result. Please answer my prior requests, and provide the output of emerge --info. Otherwise, we cannot help you.

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Thu Sep 05, 2024 2:52 pm Post subject:

@Hu

I attached the output of the commands you asked me to run. I did not do so earlier, because they did not seem to me to contain much that helps. And I have to edit the output to remove personally-identifying information, which is irritating. But I guess this stuff means more to you than to me.

Nevertheless, my question is a generic one, that doesn't seem to me to need any diagnostics:

In general, is Portage smart enough to avoid satisfying build-time dependencies when a package will be obtained as a binary?

BR, Lars.

Code:

$ emerge --pretend --verbose --depclean --with-bdeps=n virtual/rust dev-lang/rust dev-lang/rust-bin
--- Couldn't find 'dev-lang/rust' to depclean.

Calculating dependencies... done!
>>> Calculating removal order...

>>> These are the packages that would be unmerged:

virtual/rust
selected: 1.79.0
protected: none
omitted: none

dev-lang/rust-bin
selected: 1.79.0
protected: none
omitted: none

All selected packages: =virtual/rust-1.79.0 =dev-lang/rust-bin-1.79.0

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Packages installed: 947
Packages in world: 71
Packages in system: 49
Required packages: 945
Number to remove: 2

ortage 3.0.65 (python 3.12.3-final-0, default/linux/amd64/23.0/desktop, gcc-13, glibc-2.39-r6, 6.6.47-gentoo-dist x86_64)
=================================================================
System uname: Linux-6.6.47-gentoo-dist-x86_64-Intel-R-_Core-TM-_i7-4900MQ_CPU_@_2.80GHz-with-glibc2.39
KiB Mem: 16252136 total, 412728 free
KiB Swap: 0 total, 0 free
Timestamp of repository gentoo: Mon, 02 Sep 2024 07:00:00 +0000
Head commit of repository gentoo: 37afec878a990da113784452302aec0a19916e42
Head commit of repository XXX-gentoo: 503e3cb37c4a116d2106f080cfdd41ed8db6de64

Head commit of repository pf4public: fa1e631cfadd590a96f1e56ff05978829fed33d9

sh bash 5.2_p26-r6
ld GNU ld (Gentoo 2.42 p3) 2.42.0
app-misc/pax-utils: 1.3.7::gentoo
app-shells/bash: 5.2_p26-r6::gentoo
dev-build/autoconf: 2.71-r7::gentoo
dev-build/automake: 1.16.5-r2::gentoo
dev-build/cmake: 3.30.2::gentoo
dev-build/libtool: 2.4.7-r4::gentoo
dev-build/make: 4.4.1-r1::gentoo
dev-build/meson: 1.5.1::gentoo
dev-java/java-config: 2.3.4::gentoo
dev-lang/perl: 5.40.0::gentoo
dev-lang/python: 3.11.9_p2::gentoo, 3.12.3-r1::gentoo
dev-lang/rust-bin: 1.79.0::gentoo
sys-apps/baselayout: 2.15::gentoo
sys-apps/openrc: 0.54.2::gentoo
sys-apps/sandbox: 2.38::gentoo
sys-devel/binutils: 2.42-r1::gentoo
sys-devel/binutils-config: 5.5::gentoo
sys-devel/clang: 18.1.8::gentoo
sys-devel/gcc: 13.3.1_p20240614::gentoo
sys-devel/gcc-config: 2.11::gentoo
sys-devel/llvm: 18.1.8-r1::gentoo
sys-kernel/linux-headers: 6.6-r1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.39-r6::gentoo
Repositories:

gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
volatile: False
sync-rsync-extra-opts:
sync-rsync-verify-jobs: 1
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-max-age: 3

XXX-gentoo
location: /var/db/repos/XXX-gentoo
sync-type: git
sync-uri: https://github.com/XXX/XXX-gentoo.git
masters: gentoo
volatile: False

pf4public
location: /var/db/repos/pf4public
sync-type: git
sync-uri: https://github.com/PF4Public/gentoo-overlay
masters: gentoo
volatile: False

Binary Repositories:

gentoobinhost
priority: 9999
sync-uri: https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64

XXXbinhost
priority: 1
sync-uri: http://192.168.1.10:8080/binhost1

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.9/conf"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/var/cache/distfiles"
EMERGE_DEFAULT_OPTS="--usepkg-exclude 'xfce4-base/libxfce4ui'"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles getbinpkg ipc-sandbox merge-sync merge-wait multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="https://mirror.bytemark.co.uk/gentoo/"
LANG="C.UTF8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs"
LEX="flex"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/bash"
USE="X a52 aac acl acpi alsa amd64 bluetooth branding bzip2 cairo cdda cdr cet crypt css cups dbus dri dts dvd dvdr elogind encode exif flac gdbm gif gpm gtk gui iconv icu ipv6 jpeg kf6compat lcms libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses networkmanager nls ogg opengl openmp pam pango pcre pdf png policykit ppds qt5 qt6 readline sdl seccomp sound spell ssl startup-notification svg test-rust tiff truetype udev udisks unicode upower usb vorbis vulkan wxwidgets x264 xattr xcb xft xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gcc_12" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 aes avx avx2 f16c fma3 pclmul popcnt rdrand sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 ntrip navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" GRUB_PLATFORMS="efi-64" GUILE_SINGLE_TARGET="3-0" GUILE_TARGETS="3-0" INPUT_DEVICES="libinput synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-2" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_12" PYTHON_TARGETS="python3_12" RUBY_TARGETS="ruby31 ruby32" VIDEO_CARDS="intel_i915" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, MAKEOPTS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS

GDH-gentoo
Veteran
Veteran

Joined: 20 Jul 2019
Posts: 1686
Location: South America

Posted: Thu Sep 05, 2024 5:30 pm Post subject:

lars_the_bear wrote:

Code:

Portage is telling you that you no longer need anything Rust-related for building. Which is consistent with librsvg now being provided by a binary package.
_________________

NeddySeagoon wrote:

I'm not a witch, I'm a retired electronics engineer

Ionen wrote:

As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Thu Sep 05, 2024 7:37 pm Post subject:

GDH-gentoo wrote:

Portage is telling you that you no longer need anything Rust-related for building. Which is consistent with librsvg now being provided by a binary package.

Sure. What I'm trying to understand is why `rust-bin` had to be updated, last time I did `emerge ... @world`. It looked at the time as if the only thing that had a dependency on `virtual/rust` was `librsvg`, which was a binary. So it wasn't clear to me, and still isn't clear, why rust-bin had to be updated at all.

I was worried at the time that Rust had to be compiled, which is why I was so alarmed -- that would take days. The fact that it's a binary means that it isn't really a problem -- except that it shows me yet again how poorly I understand Gentoo.

BR, Lars

GDH-gentoo
Veteran
Veteran

Joined: 20 Jul 2019
Posts: 1686
Location: South America

Posted: Thu Sep 05, 2024 8:35 pm Post subject:

lars_the_bear wrote:

It looked at the time as if the only thing that had a dependency on `virtual/rust` was `librsvg`, which was a binary.

And is it still? Last command you actually showed us the output of claimed that virtual/rust and dev-lang/rust-bin could both be removed. We don't know why Portage wanted to upgrade them "at the time" because you didn't post any information "at the time" to help us help you understand.

Does:

Code:

$ emerge --pretend --depclean

claim that you can remove them in the "These are the packages that would be unmerged" part? If yes, then why don't you? Of no, we can keep looking into it.
_________________

NeddySeagoon wrote:

I'm not a witch, I'm a retired electronics engineer

Ionen wrote:

As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though

lars_the_bear
Guru
Guru

Joined: 05 Jun 2024
Posts: 517

Posted: Fri Sep 06, 2024 7:32 am Post subject:

GDH-gentoo wrote:

We don't know why Portage wanted to upgrade them "at the time" because you didn't post any information "at the time" to help us help you understand.

What information would have helped?

FWIW I don't care about Rust; what I care about is trying to understand how Gentoo works. In particular, here I'm trying to understand whether Portage always understands the difference between build-time dependencies and run-time dependencies, when it comes to doing updates. Tools like 'equery' don't seem to understand this distinction. So, for example:

Code:

$ equery g librsvg
-- virtual/rust-1.79.0 (>=virtual/rust-1.70.0) amd64 [abi_x86_32(-)? abi_x86_64(-)? abi_x86_x32(-)? abi_mips_n32(-)? abi_mips_n64(-)? abi_mips_o32(-)? abi_s390_32(-)? abi_s390_64(-)?]
...

There's no indication here that rust is only a build-time dependency (although it's clear in the .ebuild file). Perhaps there are other circumstances in which build-time and run-time dependencies get mixed up, particularly when using binary packages? I understand that binary packages are a relatively new thing in Gentoo.

My real problem is that, almost every day, Portage does something that surprises me, and that I don't understand. I'd really like to understand it better. Solving specific problems isn't a priority for me -- comprehension is.

BR, Lars.

eschwartz
Developer

Joined: 29 Oct 2023
Posts: 214

Posted: Fri Sep 06, 2024 2:54 pm Post subject:

lars_the_bear wrote:

Hu wrote:

As I read the manual page (man emerge), it is different because --getbinpkg implies --usepkg, and --usepkg implicitly disables --with-bdeps if not set by the user.

emerge -c won't uninstall build-time dependencies of installed packages by default, since it can't know whether next time you update librsvg you will be building from source or downloading a binpackage. That's why you were suggested to emerge -c --with-bdeps=n.

It's an assumption that optimizes for, by default, keeping around packages that you don't really need, but you might find annoying to reinstall later on just to build one package. People who don't use binpackages at all would certainly be very upset if emerge -c deleted their rust compiler and then gnome updated and they were forced to recompile the rust package just to rebuild librsvg.

But it's not actually a "real dependency", so:
- it's not considered part of "world"
- portage allows you to uninstall it without breaking the dependency database, as long as you tell it to not hoard build-dependencies.
- if you uninstall it, portage won't try to *reinstall* it, although if you manually --oneshot install it again, portage will hoard it as a build-dependency again

GDH-gentoo
Veteran
Veteran

Joined: 20 Jul 2019
Posts: 1686
Location: South America

Posted: Fri Sep 06, 2024 3:22 pm Post subject:

lars_the_bear wrote:

What information would have helped?

emerge --pretend --depclean --with-bdeps=value. If Portage won't remove a package with --depclean, then it's somehow in @world's dependency graph, and will be updated by emerge --update depending on the other emerge options that you specify. @world is different for every Gentoo computer, so if you ask a question, people will ask you to provide more information, usually in the form "post the output of command X / contents of file Y". Be prepared for providing it.

lars_the_bear wrote:

In particular, here I'm trying to understand whether Portage always understands the difference between build-time dependencies and run-time dependencies, when it comes to doing updates.

It does, but whether build-time dependencies are updated by emerge --update --deep @world or not depends on the other options that you specify (or don't specify, implying default action). Notably --with-bdeps, and those that control usage of binary packages when available (such as --getbinpkg).

lars_the_bear wrote:

Solving specific problems isn't a priority for me -- comprehension is.

Solving several specific problems is also a way of gaining comprehension.
_________________

NeddySeagoon wrote:

I'm not a witch, I'm a retired electronics engineer

Ionen wrote:

As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though

Hu
Administrator

Joined: 06 Mar 2007
Posts: 22618

Posted: Fri Sep 06, 2024 4:25 pm Post subject:

lars_the_bear wrote:

And I have to edit the output to remove personally-identifying information, which is irritating

Considering how often we will ask for emerge --info when you bring us a problem, I suggest you spend some time reconfiguring to eliminate that personal information from the output, whether by renaming repositories, undefining variables, or at worst, writing a wrapper script that takes raw emerge --info, deletes the information you want to hide, and prints the remainder.

Display posts from previous:

	Gentoo Forums Forum Index Portage & Programming	All times are GMT
Page 1 of 1

Jump to:

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

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy