But if I understand the "emerge" manual page correctly, "--changed-deps" causes a rebuild of a package, if one of its dependencies has been re- build, even though the package does not require the newer version of the dependency. So does it really make sense to have this option hardcoded
in a script? Or does it just cause plenty of package rebuilds without
any real effect? Likewise, what about "--deep"? Should I keep it?
Or does it just cause plenty of package rebuilds without
any real effect? Likewise, what about "--deep"? Should I keep it?
On Sun, 20 Feb 2022 at 15:40, Dr Rainer Woitok<rainer.woitok@gmail.com> wrote:
But if I understand the "emerge" manual page correctly, "--changed-deps""--deep" seems like a good idea, to minimise the chance of trouble,
causes a rebuild of a package, if one of its dependencies has been re-
build, even though the package does not require the newer version of the
dependency. So does it really make sense to have this option hardcoded
in a script? Or does it just cause plenty of package rebuilds without
any real effect? Likewise, what about "--deep"? Should I keep it?
but "--changed-deps" does indeed seem excessive.
I also have "--oneshot" in my updates, although I'm not sure if this
actually makes a difference on a world update.
I also have "--backtrack=100" to minimise the risk of portage not
being able to find an upgrade path for some troublesome package. Just
as "--deep" it will add to the time portage needs to calculate what
packages to update, but it feels like I've had less instances of
upgrade path troubles since adding it to my regular world update
command.
On 20/02/2022 14:54, Arve Barsnes wrote:
On Sun, 20 Feb 2022 at 15:40, Dr Rainer
Woitok<rainer.woitok@gmail.com> wrote:
But if I understand the "emerge" manual page correctly,"--deep" seems like a good idea, to minimise the chance of trouble,
"--changed-deps"
causes a rebuild of a package, if one of its dependencies has been
re-
build, even though the package does not require the newer version of
the
dependency. So does it really make sense to have this option
hardcoded
in a script? Or does it just cause plenty of package rebuilds
without
any real effect? Likewise, what about "--deep"? Should I keep it?
but "--changed-deps" does indeed seem excessive.
I also have "--oneshot" in my updates, although I'm not sure if this
actually makes a difference on a world update.
Oneshot just stops stuff being added by default to the world file, so
on an update it'll have no effect whatsoever.
I also have "--backtrack=100" to minimise the risk of portage not
being able to find an upgrade path for some troublesome package. Just
as "--deep" it will add to the time portage needs to calculate what
packages to update, but it feels like I've had less instances of
upgrade path troubles since adding it to my regular world update
command.
:-) yes it seems most of my problems get solved by increasing
backtrack so maybe I ought to do that too ...
What I'd also like is an option --dont-stop. Similar to keep-going, it
would kick in earlier. Keep-going only kicks in once the real emerge
is running. What I would like with dont-stop is if the dependency
calculation gives up, it would start emerging whatever it's found so
far. I've found when things really go pear-shaped updating a system
for the first time in yonks, looking at and updating what's updateable enables the next attempt to get a little further, etc etc, until
suddenly everything updates.
So basically, dont-stop would update everything it can.
Cheers,
Wol
Greetings,
some time back it was pointed out on this list to only use "--changed-
use" rather than "--newuse". So I've meanwhile removed this option (and
also a few others) from my update script which I had created early after installing Gentoo. It now basically runs
$ sudo emerge --ask --verbose-conflicts --changed-deps \
--changed-use --deep --update @world
But if I understand the "emerge" manual page correctly, "--changed-deps" causes a rebuild of a package, if one of its dependencies has been re- build, even though the package does not require the newer version of the dependency. So does it really make sense to have this option hardcoded
in a script? Or does it just cause plenty of package rebuilds without
any real effect? Likewise, what about "--deep"? Should I keep it?
Sincerely,
Rainer
So basically, dont-stop would update everything it can.
So basically, dont-stop would update everything it can.
I half-jokingly called this "emerge --i-dont-care" in 2012:
https://groups.google.com/g/linux.gentoo.user/c/wE2GnF7RlnY
There are (still) a lot of people who want it. Last night I started a
@world update that would take all night and then went to bed. Five
minutes later, app-laptop/tp_smapi failed to build due to some error
that I don't care about. As a result, it's going to take an extra day
to update my system.
On Sun, 20 Feb 2022 11:49:45 -0500, Michael Orlitzky wrote:
So basically, dont-stop would update everything it can.
I half-jokingly called this "emerge --i-dont-care" in 2012:
https://groups.google.com/g/linux.gentoo.user/c/wE2GnF7RlnY
There are (still) a lot of people who want it. Last night I started a
@world update that would take all night and then went to bed. Five
minutes later, app-laptop/tp_smapi failed to build due to some error
that I don't care about. As a result, it's going to take an extra day
to update my system.
Shouldn't --keep-going have kicked in there and restarted the update?
Shouldn't --keep-going have kicked in there and restarted the update?
21/2/22 v 0:06, Michael Orlitzky <mjo@gentoo.org>:
On Sun, 2022-02-20 at 19:51 +0000, Neil Bothwick wrote:
Shouldn't --keep-going have kicked in there and restarted the update?
You'd think, but --keep-going tries to recompute dependencies and if
the original emerge crashes in an inconsistent state, that often seems
to push the calculation over the edge, preventing portage from figuring
out how to proceed.
In my half-baked imagination,
emerge --i-dont-care -uDN @world
would build the package list normally, but then would go through them
one at a time as if "emerge -1 --nodeps" was used for each. So once we
know that the package list *can* be emerged in that order -- just do
it, and don't try to think again.
You'd think, but --keep-going tries to recompute dependencies and if
the original emerge crashes in an inconsistent state, that often seems
to push the calculation over the edge, preventing portage from figuring
out how to proceed.
Pardon me, but how would using --nodeps be a wise choice to rebuild
your @world?
...
But --deep - that's to do
with a dependency changing USE flags, and it will block a depclean if
you don't do it.
Wol,
On Sunday, 2022-02-20 14:56:20 +0000, you wrote:
...Thanks for the reminder! This is in fact mentioned in every output from "emerge --depclean" and thus develops a high probability of being ignor-
But --deep - that's to do
with a dependency changing USE flags, and it will block a depclean if
you don't do it.
ed ... :-)
So my script will keep "--deep" when "--update" is specified. But what about "--changed-deps"? Can nobody on this list explain what it really
is or isn't good for, or when to use or not to use it?
Sincerely,
Rainer
P. S. I tried tkman to read man pages. It pukes a error and doesn't work. Something changed in the man command and I don't like it. I'm looking for a GUI man page tool. Any ideas? Off list if needed. I noticed this when trying to read the emerge man page.
On Mon, 21 Feb 2022 05:38:09 -0600, Dale wrote:
P. S. I tried tkman to read man pages. It pukes a error and doesn'tYou use KDE don't you? Konqueror still reads man pages.
work. Something changed in the man command and I don't like it. I'm
looking for a GUI man page tool. Any ideas? Off list if needed. I
noticed this when trying to read the emerge man page.
When running an update after a long long time my approach is as follows:
emerge -av --depclean <every huge program which will be updated anyway. Stuff like firefox, thunderbird, etc.>
emerge -a --depclean --with-bdeps=n
only then when there are as few programs installed as possible I run
emerge --sync
emerge -Dua --reinstall changed-use @world
maybe I have to deal with trouble here
dispatch-conf
emerge -a --depclean --with-bdeps=y
--with-bdeps=y shouldn`t do anything
revdep-rebuild -i -- --ask
glsa-check -t all
Maybe there is a better way or I've missed some new ways of updating.
On 20/02/2022 14:54, Arve Barsnes wrote:
On Sun, 20 Feb 2022 at 15:40, Dr Rainer
Woitok<rainer.woitok@gmail.com> wrote:
But if I understand the "emerge" manual page correctly, "--changed-deps" >>> causes a rebuild of a package, if one of its dependencies has been re- >>> build, even though the package does not require the newer version of the >>> dependency. So does it really make sense to have this option hardcoded >>> in a script? Or does it just cause plenty of package rebuilds without >>> any real effect? Likewise, what about "--deep"? Should I keep it?"--deep" seems like a good idea, to minimise the chance of trouble,
but "--changed-deps" does indeed seem excessive.
I also have "--oneshot" in my updates, although I'm not sure if this
actually makes a difference on a world update.
Oneshot just stops stuff being added by default to the world file, so on
an update it'll have no effect whatsoever.
I also have "--backtrack=100" to minimise the risk of portage not
being able to find an upgrade path for some troublesome package. Just
as "--deep" it will add to the time portage needs to calculate what
packages to update, but it feels like I've had less instances of
upgrade path troubles since adding it to my regular world update
command.
:-) yes it seems most of my problems get solved by increasing backtrack
so maybe I ought to do that too ...
What I'd also like is an option --dont-stop. Similar to keep-going, it
would kick in earlier. Keep-going only kicks in once the real emerge is running. What I would like with dont-stop is if the dependency
calculation gives up, it would start emerging whatever it's found so
far. I've found when things really go pear-shaped updating a system for
the first time in yonks, looking at and updating what's updateable
enables the next attempt to get a little further, etc etc, until
suddenly everything updates.
So basically, dont-stop would update everything it can.
Cheers,
Wol
emerge -av --depclean <every huge program which will be updated anyway.I think what you really are doing can be simplified by:
Stuff like firefox, thunderbird, etc.>
emerge -a --depclean --with-bdeps=n
only then when there are as few programs installed as possible I run
emerge --sync
emerge -Dua --reinstall changed-use @world
On Mon, 21 Feb 2022 22:26:30 +0100, hitachi303 wrote:
When running an update after a long long time my approach is as follows:
emerge -av --depclean <every huge program which will be updated anyway.
Stuff like firefox, thunderbird, etc.>
You don't need to unmerge them, just add --exclude "firefox thunderbird
etc" to your emerge command.
emerge -a --depclean --with-bdeps=n
only then when there are as few programs installed as possible I run
emerge --sync
emerge -Dua --reinstall changed-use @world
If it's been a while, it may be easier to update @system first.
maybe I have to deal with trouble here
dispatch-conf
emerge -a --depclean --with-bdeps=y
--with-bdeps=y shouldn`t do anything
revdep-rebuild -i -- --ask
glsa-check -t all
You can run this straight after syncing, it may mean you want to update affected programs before doing the rest of @world.
Maybe there is a better way or I've missed some new ways of updating.
...
But what about "--changed-deps"? Can nobody on this list explain what it really
is or isn't good for, or when to use or not to use it?
And none of the examples to overcome problems provided by others in this thread ever contained "--changed-deps". Does this mean "--changed-deps"It is kind of a noop. I am not 100% certain, but my interpretation is
is a NOOP, a relict from days long gone by, meanwhile without any funct- ionality, just provided for compatibility in order to not break ancient scripts?
=dep1:1.2.0This is all merged at timepoint T1 and these dependencies are
=dep1:1.2.0), however you try to update the client at timepoint T2 where the dependencyis now >=dep1:1.2.1, and you'll end up in mismatched dependency and
Is it a good practise to update @system first?
I always update @world almost every seven days and I only get into
package conflicts, if I do not update for more than 60 days or so. Last
time was 99 days ago and I had to resolve circular package dependencies
and so forth manually.
Apart from a reply by Dale which more or less confirmed (at least the
way I read it) that the section regarding the "--changed-deps" option in
"man emerge" does not contain much valuable information, there was no response whatsoever, not even from the "gentoo.org" folks on this list!
And none of the examples to overcome problems provided by others in this thread ever contained "--changed-deps". Does this mean "--changed-deps"
is a NOOP, a relict from days long gone by, meanwhile without any funct- ionality, just provided for compatibility in order to not break ancient scripts?
It's not a relic, it's a fairly recent addition. It's a bit of a belt and braces approach which basically says "rebuild everything that might just possibly, maybe, in some circumstances have some sort of effect".
...
It's really a (portage-only) workaround for developers who don't follow
the rules, thus ensuring that we'll never have another competing
package manager again.
But --changed-use slows things down a lot, so you also don't want to
use it *every* time.
So for people like me, neither being a developer nor managing a local server for binary packages (thanks Andreas for pointing out this special case), "--changed-deps" really is an option not to be used.
Case finally closed :-)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 302 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 98:55:30 |
| Calls: | 6,767 |
| Calls today: | 5 |
| Files: | 12,295 |
| Messages: | 5,376,396 |
| Posted today: | 1 |