--with-bdeps and emerge --depclean

[v_andal]

Sorry, I kind of got confused about this stuff. Until recently, when I did 'emerge --depclean' I never had any problems with "build dependencies". Somehow, now when I run this command I get notification that some of my build-dependencies are not updated and recommendation to run update with --with-bdeps=y.

Why is this? If "update world" without this option didn't think that build dependency should be updated, why "emerge --depclean" refuses to work until they are updated?

[krinn]

I agree, but i don't think it really need the option. From my emerge i have :

Code: Select all

The most comprehensive command for this purpose is as follows ... Note that the --with-bdeps=y option is not required in many situations. :

That's a bit blur as the first suggest just "the most comprehensive command", and the second suggest it is sometimes require, and i don't see any reason to that case too.
The text could be update to be less blur and/or emerge was change in a "fancy" way, as even if depclean removed a build dependency this wouldn't harm any installed package.

This kind of stuff can only be fix in bugs.gentoo.org

[steveL]

If "update world" without this option didn't think that build dependency should be updated, why "emerge --depclean" refuses to work until they are updated?

Because you might want to upgrade the apps on your system without upgrading things used only at build-time, so long as the dep is satisified. As a hypothetical example (since it's in @system anyhow, so wouldn't be a dep) if a package needed sed to build, the sed you have installed will likely work fine. So portage doesn't need to consider it as an upgrade, even if there is a new sed available. If it were a runtime dep, like a library, we'd like it upgraded. So the distinction can be drawn, and by default portage does less.

depclean defaults to --with-bdeps y meaning "don't try to depclean build-dependencies", just keep them. Whatever it does, it usually needs a fully upgraded machine.
Otherwise emerge defaults to --with-bdeps n meaning "don't try to upgrade build-deps" as above. So you need to run an emerge -av -uDN @world --with-bdeps y before you depclean, usually.

FWIW I use update to handle all this; just update -s on its own will run emerge -pv -uD --changed-use @world --with-bdeps y after syncing, so you can review it, and then go ahead and do the lot once confirmed. After that it'll do GLSAs, @preserved-rebuild if needed, depclean and revdep-rebuild.
You'd use update -uDN to do the above emerge. (we switched from -N to --changed-use a while back, as it's an in-portage impl of skipping useless rebuilds, which we had as external code for a few years.)

[v_andal]

Whatever it does, it usually needs a fully upgraded machine.

Actually, that's the point I don't understand. Why does it need fully upgraded machine? It's clear for all, bdeps are not needed for the system, even if they are installed. So, why depclean needs them to be upgraded?

I'm trying to understand this, because I have a feeling, that this is a bug. But there might be reasons why this has to be a feature

[krinn]

That's how things are working for me :

A is a dbeps of B
emerge --depclean --with-bdeps=y mean remove B and keep A
emerge --depclean --with-bdeps=n mean remove B and remove A

It's already a strange usage to me, i don't see any reason to keep A, not even if i put B in my world file. A has no usage at all and should always be clear out.

Now it's even weirder to see emerge asking you need to update A to make --depclean running.
But i don't really know the answer ; except i agree with you that a request to update using --with-bdeps=y is weird.
Something better ask in bugs.gentoo.org for me.

[v_andal]

Ok. I've created new "bug" with ID 503490. We'll see what developers say to this.

[steveL]

That's how things are working for me :

A is a dbeps of B
emerge --depclean --with-bdeps=y mean remove B and keep A
emerge --depclean --with-bdeps=n mean remove B and remove A

It's already a strange usage to me, i don't see any reason to keep A, not even if i put B in my world file. A has no usage at all and should always be clear out.

Now it's even weirder to see emerge asking you need to update A to make --depclean running.
But i don't really know the answer ; except i agree with you that a request to update using --with-bdeps=y is weird.

Yeah it seems odd at first. But think of it this way: A is usually something that's needed by other things to build, as well. If you're doing a few things on your machine, and fiddling with packages, you don't necessarily want to remove it. Even if it's only a build-dep, you're likely going to want to use it for another emerge in the near future.

Perl might make a good example, except people use it in scripts. But let's say, like me, you don't do perl, and you want a setup without it (example breaks down because of its script usage for so many things, but let's pretend.) You still have to bootstrap perl in order to run autotools properly, or patching is out of the window, and you are reliant on upstream not making any mistakes (since you can't autoreconf without perl.) And perl is a b1tch to bootstrap (one of the main reasons I'm not allowed to use autotools at work, in fact): be grateful we don't have do stage1 and 2 any more. So there's no way you want to get rid of perl, even if it's not needed for packages at runtime. Depcleaning it (unlikely, but let's pretend;) and then having to rebuild it every world upgrade would soon convince you not to use --depclean --with-bdeps y as part of your routine.

The reason it seems odd is that it feels like the sense is inverted; in an install operation, --with-bdeps y installs them, in depclean it removes them. In English terms it makes sense, (depclean the bdeps, emerge the bdeps) and also in the terms it's put in the manual (include them in the dependency calculation) though that's obviously a bit more formalised. However for us stressed out users at cli, it can get confusing when you think of y as install and n as remove: that's fine for everything but depclean. And then ofc the sane default is the opposite in each case.

To be honest, that's why I let update do it for me. I don't want to have to remember it, as I'm lazy, and even when I do (or did, before we added it to update by default) I normally get the sense inverted. (Although I did add a shortcut: --bdeps use --with-bdeps y to portage or: --bdeps=y|n, it doesn't apply to depclean. Its usage is for when you supply a target to update, since it won't add it then, nor will it add it for ROOT builds.)

As for it needing them upgraded, I imagine if you're telling it to keep the build-deps (depclean default), it wants to know you have them upgraded, so it can remove the unneeded ones. If it also needs them upgraded when you have --depclean --with-bdeps y then I agree it's a bug (assuming the rest of the world/system is up to date.) The "whatever it does" aspect might be my confusion, though. Normally, given that I always run it after a full upgrade, my build-deps have been updated, so I don't come across that case (just "your machine has not been upgraded" or w/e it is if I use update -C to depclean without upgrading after a sync.)

@v_andal: can you add a [bug=503490]bug url[/bug] to your previous post please? hit edit and then use the Bug button, same as you would a url or post after you've selected a bit of text, or just type it by hand

Code: Select all

[bug=503490]ID 503490[/bug]

(I'll remove this text when you have.)