Re: [gentoo-user] Options for "emerge"
On Tue, 2022-02-22 at 12:57 -0500, Michael Orlitzky wrote: > > But --changed-use slows things down a lot, so you also don't want to > use it *every* time. > Whoops, I mean --changed-deps.
Re: [gentoo-user] Options for "emerge"
On Tue, 2022-02-22 at 16:42 +0100, Dr Rainer Woitok wrote: > > 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 :-) > If only. You need to use it whenever a developer makes an important dependency change inside an ebuild or eclass without updating the revision number (e.g. -r1). But --changed-use slows things down a lot, so you also don't want to use it *every* time.
Re: [gentoo-user] Options for "emerge"
Thanks, Michael, On Tuesday, 2022-02-22 10:05:06 -0500, you wrote: > ... > 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. 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 :-) Sincerely, Rainer
Re: [gentoo-user] Options for "emerge"
On Tue, 2022-02-22 at 14:26 +, Neil Bothwick wrote: > > 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.
Re: [gentoo-user] Options for "emerge"
On Tue, 22 Feb 2022 13:21:48 +0100, Dr Rainer Woitok wrote: > 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". -- Neil Bothwick Heisenberg may have been here. pgpul7_nHCEIx.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Options for "emerge"
On Tue, 22 Feb 2022 14:09:30 +0100, Ramon Fischer wrote: > 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. Not really, if you update regularly, just doing @world is the way to go. Emerging @system first is recommended only when @world fails to resolve dependencies, which can happen after a long update interval. -- Neil Bothwick Physics is like sex: sure, it may give some practical results, but that's not why we do it.Richard Feynman pgpWjAgaL7xuV.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Options for "emerge"
On Tue, 22 Feb 2022 13:21:48 +0100 Dr Rainer Woitok wrote: > 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 is kind of a noop. I am not 100% certain, but my interpretation is the following (based on experience with a binary host serving to several clients). I'm at timepoint T1 and I merge package pkg1, which depends on >=dep1:1.2.0 This is all merged at timepoint T1 and these dependencies are remembered in /var/db/pkg and also in $PKGDIR/Packages. Now comes timepoint T2 the ebuild was modified, no revbump whatsoever has been done, but suddenly the dependency reads as >=dev1:1.2.1. Now normally it is a noop to re-emerge because you are already on dev1:1.3, i.e. nothing really changes BUT it makes a difference for binary packaging. When you have a build-host that you to provide binaries, you can end up in situations where your client would reject a package due to unmatched dependencies (your build-host has emerged pkg1 at timepoint T1 and remembered that pkg1 depends on >=dep1:1.2.0), however you try to update the client at timepoint T2 where the >dependency is now >=dep1:1.2.1, and you'll end up in mismatched dependency and the binary will be rejected, i.e. your client must compile itself and cannot merge from the binary host. When you are not worried providing packages as binaries to other clients you probably should not care about --changed-deps.
Re: [gentoo-user] Options for "emerge"
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.
I wrote this update script[1] for my weekly update routine, where I am
still testing "--changed-use", instead of "--newuse":
[...]
no_tmpfs_file="/etc/portage/package.env/no_tmpfs.conf"
[...]
large_package_list=$(/bin/grep --extended-regexp --only-matching
"[0-9a-zA-Z]+-[0-9a-zA-Z]+\/[-0-9a-zA-Z]+" "${no_tmpfs_file}")
[...]
/usr/bin/eix-sync
if /usr/bin/eix --upgrade sys-apps/portage >/dev/null
then
/bin/echo -e "\e[01;31mA new version of 'sys-apps/portage' was
found. Updating it first...\e[0m"
/usr/bin/emerge --ask --oneshot sys-apps/portage
fi
/usr/bin/emerge --ask --update --deep --changed-use --tree --verbose
--exclude="${large_package_list//$'\n'/ }" @world
# always compile large packages as last packages
/usr/bin/emerge --update --deep --changed-use --tree --verbose @world
/usr/sbin/etc-update
/usr/bin/emerge --ask --depclean --verbose
/usr/bin/glsa-check --test all
/usr/bin/glsa-check --list
/usr/bin/glsa-check --fix --quiet all
/usr/bin/revdep-rebuild --verbose -- --ask
/usr/bin/eclean --deep --time-limit="1m" distfiles
/usr/bin/eclean --deep --time-limit="1m" packages
/usr/bin/eix-test-obsolete
/usr/bin/elogv
/usr/bin/eselect news read
-Ramon
[1]
https://codeberg.org/keks24/dotfiles/src/branch/master/root/bin/update.sh
On 22/02/2022 07:24, hitachi303 wrote:
Am 22.02.2022 um 06:27 schrieb Andreas Fink:
On Mon, 21 Feb 2022 22:26:30 +0100
hitachi303 wrote:
emerge -av --depclean
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
I think what you really are doing can be simplified by:
emerge -auvDN @system
emerge -auvDN @world
Once @system is updated it is much simpler to get @world to update too.
Maybe you have to help with a couple of `--exclude ATOM` when updating
world.
From time to time I ran into trouble with @system where emerge
couldn't resolve blocks but using @world did not have this problems
and went fine.
--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-user] Options for "emerge"
Er ... On Monday, 2022-02-21 11:13:16 +0100, I myself wrote: > ... > 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? 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? If so, I think the manual page could frankly point that out. If not so, where could I look-up the relevant information, short of the source code? Sincerely, Rainer
Re: [gentoo-user] Options for "emerge"
Am 22.02.2022 um 06:27 schrieb Andreas Fink: On Mon, 21 Feb 2022 22:26:30 +0100 hitachi303 wrote: emerge -av --depclean 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 I think what you really are doing can be simplified by: emerge -auvDN @system emerge -auvDN @world Once @system is updated it is much simpler to get @world to update too. Maybe you have to help with a couple of `--exclude ATOM` when updating world. From time to time I ran into trouble with @system where emerge couldn't resolve blocks but using @world did not have this problems and went fine.
Re: [gentoo-user] Options for "emerge"
Am 21.02.2022 um 22:48 schrieb Neil Bothwick: 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 You don't need to unmerge them, just add --exclude "firefox thunderbird etc" to your emerge command. I have never used --exclude before. I'll try it out soon. I unmerge them so that in the next step --depclean --with-bdeps=n will also get rid of all dependencies and build-time dependencies. 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. Most likely the first steps will be eselect news read and emerge -a1 portage I have never been to lucky with @system. Often I do have more problems to update @system than to update @world. Sometimes I think that @system contains atoms which do not belong there. Might be a feeling and I never looked into it. 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. Your suggestion seems to be a better way. I'll change that. Maybe there is a better way or I've missed some new ways of updating.
Re: [gentoo-user] Options for "emerge"
On Mon, 21 Feb 2022 22:26:30 +0100 hitachi303 wrote: > > emerge -av --depclean 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 I think what you really are doing can be simplified by: emerge -auvDN @system emerge -auvDN @world Once @system is updated it is much simpler to get @world to update too. Maybe you have to help with a couple of `--exclude ATOM` when updating world.
Re: [gentoo-user] Options for "emerge"
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 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. -- Neil Bothwick Top Oxymorons Number 22: Childproof pgpOFItHiPSS9.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Options for "emerge"
Am 20.02.22 um 16:18 schrieb Wols Lists: On 20/02/2022 14:54, Arve Barsnes wrote: On Sun, 20 Feb 2022 at 15:40, Dr Rainer Woitok 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 When running an update after a long long time my approach is as follows: emerge -av --depclean 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. Regards
Re: [gentoo-user] Options for "emerge"
Neil Bothwick wrote: > 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'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. > You use KDE don't you? Konqueror still reads man pages. > > You come to the rescue again. That works great. Easy to scroll, copy and search for words. It is also easy to print from as well. For anyone else who runs up on this, put something like this in the url bar. man:emerge Thanks much. Dale :-) :-)
Re: [gentoo-user] Options for "emerge"
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'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. You use KDE don't you? Konqueror still reads man pages. -- Neil Bothwick Most software is about as user-friendly as a cornered rat! pgpyha_KurCxa.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Options for "emerge"
Dr Rainer Woitok wrote: > Wol, > > On Sunday, 2022-02-20 14:56:20 +, you wrote: > >> ... >>But --deep - that's to do >> with a dependency changing USE flags, and it will block a depclean if >> you don't do it. > Thanks for the reminder! This is in fact mentioned in every output from > "emerge --depclean" and thus develops a high probability of being ignor- > 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 > > I read what the man page says. For me, it isn't very clear. I'm sure you read it and came to the same conclusion. This is my thoughts, and I am certainly capable of being very wrong here. Lets say package A depends on package B. Package B changes and could affect package A. The --changed-deps should trigger a rebuild/reinstall of package A. Sometimes package A can link to parts of package B and changing package A can affect that if there is a sizable change. It may even make package A not work or crash. That's my thinking. Like I said, I could be wrong or have it backwards. The man page just isn't worded in a way that makes sense to me. Of course, I don't have a decoder for emerge either. :/ Anyone have a better explanation?? Dale :-) :-) 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.
Re: [gentoo-user] Options for "emerge"
Wol, On Sunday, 2022-02-20 14:56:20 +, you wrote: > ... >But --deep - that's to do > with a dependency changing USE flags, and it will block a depclean if > you don't do it. Thanks for the reminder! This is in fact mentioned in every output from "emerge --depclean" and thus develops a high probability of being ignor- 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
Re: [gentoo-user] Options for "emerge"
On Mon, 2022-02-21 at 00:12 +0200, j...@clusters.gr wrote: > Pardon me, but how would using --nodeps be a wise choice to rebuild > your @world? Straightaway, it isn't. But if you've already computed the list of packages to be emerged, and the order in which to emerge them, then emerging those one-at-a-time with --nodeps shouldn't cause any problems because you'll be emerging the dependencies before the packages that need them. We're brainstorming a workaround for two related portage annoyances: 1. Sometimes, if you try to upgrade too few packages, portage can't figure out what to do because the depgraph isn't big enough for it to see "the big picture." Like if there's a perl upgrade requiring --backtrack=200 or something like that. 2. Sometimes, if you try to upgrade too many packages, portage can't figure out what to do because the dependency graph gets too complicated. Often the way around this is to "emerge -1" things until the remaining package list is small enough that portage can deduce what to do. To solve (1), you want to use "emerge -uDN --backtrack= @world". But then this puts you in situation (2). In that scenario, it would be really nice if there was a way to tell portage to "just start doing it," so that you don't have to sit there and manually "emerge -1" things for an hour. But then to avoid falling back into situation (1), and to speed the process up, it would have to proceed as if --nodeps was given. Depending on what fails, you could still get into trouble by upgrading a package whose dependencies have failed to upgrade. But after enough wasted hours, I stop caring about that. Thus the semi-humorous suggestion of "emerge --i-dont-care".
Re: [gentoo-user] Options for "emerge"
On 20/02/2022 22:05, Michael Orlitzky wrote: 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. That's where I would like --dont-stop ... if the dependency calculation fails, just emerge everything that you have calculated ... Because on an old system, this is the step that has a habit of failing straight away ... Cheers, Wol
Re: [gentoo-user] Options for "emerge"
Pardon me, but how would using --nodeps be a wise choice to rebuild your @world? > 21/2/22 v 0:06, Michael Orlitzky : > > On Sun, 2022-02-20 at 19:51 +, 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. > > >
Re: [gentoo-user] Options for "emerge"
On Sun, 2022-02-20 at 19:51 +, 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.
Re: [gentoo-user] Options for "emerge"
On 20/02/2022 19:51, Neil Bothwick wrote: 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? Yup. That was my reaction - you're talking about "build failed", which is keep-going, and already which exists. I'm talking about "build never starts" ie tp-smapi (and everything else!) never even started! "too many failed dependencies - aborting" or something like that ... Cheers, Wol
Re: [gentoo-user] Options for "emerge"
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? -- Neil Bothwick All things being equal, fat people use more soap. pgpxZGJfkZbg3.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Options for "emerge"
On Sun, 2022-02-20 at 15:18 +, Wols Lists 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.
Re: [gentoo-user] Options for "emerge"
Wols Lists wrote: > On 20/02/2022 14:54, Arve Barsnes wrote: >> On Sun, 20 Feb 2022 at 15:40, Dr Rainer >> Woitok 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 > > I like the sound of dont-stop too. Interesting. Dale :-) :-)
Re: [gentoo-user] Options for "emerge"
Dr Rainer Woitok wrote: > 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 > > I been using Gentoo since about 2003. Over the years, I've learned what gives the most stable system even if it requires rebuilding packages as a extra step. I have some options in make.conf, such as --oneshot which keeps a clean world file, so I don't always have to do a lot of typing. I copied this from the emerge.log so it gives a complete output of options when I do a world update. emerge --newuse --oneshot --unordered-display --update --ask --backtrack=100 --deep --keep-going --with-bdeps=y --quiet-build=y --regex-search-auto=y --verbose world On occasion, I have to increase backtrack but about 99% of the time, 100 is enough. When I run into problems I can't seem to get through any other way, I tend to do a emerge -e world. Just in the last week or so, I ran into a USE flag problem that sent me in circles. After a while, I just did a emerge -e world and emerge was able to find a path that allowed me to get everything up to date and reinstall some packages I had removed, trying to get a clean output. I was then able to run --depclean which removed several packages. One thing I've learned, shortcuts sometimes cause problems. A program may crash, be slow or do other strange things. Over the years, I've found that weekly updates are easier than monthly. Over time, I've found that the options I use give me a really stable system. Sometimes my uptimes are months to almost a year on occasion. My biggest reason for rebooting, power failure. I'm also bad to stay logged in and keep programs running until my weekly updates are done. I logout, restart services until things are reloaded with new versions and then log back in. I don't do a lot of logouts and back ins. How you do things really depends on what you want in the end. If you really want a rock solid system, it may require rebuilding more packages than doing things a easy and fast way. In most cases, the fast and easy way may work fine. There will likely be exceptions to that rule tho. If you are on a laptop or a system that has less than great cooling, that raises a whole new way of viewing things. I wouldn't do updates on a laptop the way I do on this desktop. I have massive cooling on this system with my CPU rarely reaching 125F when all cores are at 100%, such as compiling gcc, libreoffice, Firefox etc. I don't mind pushing this thing a bit because the chance of overheating is basically zero. I have a older Cooler Master HAF-932 case with all fans installed and running. Large CPU cooler to. Dang thing barely fits in this large case. Others have given some good options. They may work better depending on your situation. Then again, you may like part of mine or all of mine. Just pick and chose what you like best. Hope that helps. Dale :-) :-)
Re: [gentoo-user] Options for "emerge"
On 20/02/2022 14:54, Arve Barsnes wrote: On Sun, 20 Feb 2022 at 15:40, Dr Rainer Woitok 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
Re: [gentoo-user] Options for "emerge"
On 20/02/2022 14:40, Dr Rainer Woitok wrote: Or does it just cause plenty of package rebuilds without any real effect? Likewise, what about "--deep"? Should I keep it? Changed deps, I don't particularly know about. But --deep - that's to do with a dependency changing USE flags, and it will block a depclean if you don't do it. It's up to you whether you want it as part of your normal e,merge - it's part of mine. Cheers, Wol
Re: [gentoo-user] Options for "emerge"
On Sun, 20 Feb 2022 at 15:40, Dr Rainer Woitok 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. 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. Regards, Arve
