[gentoo-user] emerge - Tips and Tricks

[gentoo-user] emerge - Tips and Tricks

[Joe]

Hello,


I'm looking for some tips and tricks regarding emerge. I know there is a 
cheat sheet on what stuff you can do. But i would like emerge exclusively .

Normally i run emerge -uavDU --with-bdeps=y @world when i don't want a 
reinstall of everything after a emerge --sync

I run emerge -uavDN --with-bdeps=y @world when i want to reinstall or 
like the manual says if there is a use flag that has been changed by me 
or the dev.


Am i doing it right or what should i do that can help me and newer people


Thanks


Joe

Re: [gentoo-user] emerge - Tips and Tricks

[Dale]

Joe wrote:
> Hello,
>
>
> I'm looking for some tips and tricks regarding emerge. I know there is
> a cheat sheet on what stuff you can do. But i would like emerge
> exclusively .
>
> Normally i run emerge -uavDU --with-bdeps=y @world when i don't want a
> reinstall of everything after a emerge --sync
>
> I run emerge -uavDN --with-bdeps=y @world when i want to reinstall or
> like the manual says if there is a use flag that has been changed by
> me or the dev.
>
>
> Am i doing it right or what should i do that can help me and newer people
>
>
> Thanks
>
>
> Joe

I been using Gentoo since 2003.  The emerge program has come a LONG way
since then.  Over the years tho, I've refined my update process until I
got to a point where it won't get any better.  You will still run into
the occasional update that requires the use of a hammer but for the most
part, this does well.  First thing.  I have a set of options in
make.conf to cover most options.  That line looks like this. 


EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=500 --keep-going -v
--quiet-build=y -1 --unordered-display --jobs=16 --load-average 8"


A couple of those are either personal preference or machine dependent. 
The bdeps option will cause extra rebuilds on occasion but it is rare
that I get a seg fault or programs that just crash because the versions
don't work well together.  Before that option was available, I used to
do a emerge -e world to fix problems with programs not starting or
crashing with a seg fault.  The bdeps options seems to have improved
that a LOT.  The backtrack option just makes sure you only have to run
emerge -a<whatever> once.  It takes a while sometimes but it digs deep,
real deep.  If a update can be done, it will find a way.  Honestly, 100
is likely more than enough in most all cases.  The keep-going option is
good for when a packages fails, especially early on, and it stops the
update.  On most occasions, emerge can regroup and continue on skipping
only one or a very few packages.  It saves time in the long run if you
start a update and don't monitor it.  The -1 option is the same as
oneshot.  This prevents you from accidentally cluttering up the world
file.  Something gives you problems and you are emerging by hand, if you
forget to add the -1 as you work to fix it, it adds all those to the
world file, including version if you specify one.  I'm not sure on the
display option.  I added it for some reason, ages ago.  The job and load
is different for each machine.  The line above is for a 16 core, 32
thread CPU with 64GBs of ram.  My old 8 core with 32GBs of ram was set
to jobs 8 and load 3 I think.  Memory is one limiting factor there. 
LOo, that qt package and a couple others can fail from lack of memory if
set higher.

Second thing.  My usual update process.  I sync first.  I run emerge
-auDN world and check what it plans to do.  I mostly check USE flags. 
Sometimes a USE flag will change and I have to adjust them a bit. 
Sometimes on a per package basis, sometimes global.  Once I'm happy with
what it wants to do, I hit the 'y' key and turn her lose. 

On both my old rig and new rig, I have a second install that is in a
chroot.  When I have packages that take a long time to build, I do my
updates in the chroot first and then copy over the binaries.  Then I
just need to do a emerge -aukDN world to make the update faster since it
is already compiled.  This can be handy when you have some of the qt
packages and the software has different versions and it causes
problems.  Some updates midway can make it so certain programs won't
launch at all.  I've had that happen with Kwrite several times, Dolphin
a few times.  Once the update is done and you logou and back in,
everything works again.  You just may run into problems during the
update when some packages are old still and some are new.  This method
lessens the time of that problem. 

Once the update is done, I then run emerge -a --depclean and see if
anything needs to be removed or if I need to add something I want to
keep to the world file.  Oh, if you want to emerge something and add it
to the world file so it gets updated and saved, emerge --select y plus
your other options will override the oneshot option.  If you run a GUI,
you need to logout and back in.  I sometimes switch to the boot runlevel
and check for services that need to be restarted as well.  One could
reboot and achieve the same goal.  This is Linux tho.  ;-) 

Obviously, a news item can change that process.  If there is a news item
with a different process, follow that for sure.  Following the news item
to the letter is the best way.  The devs work out all the kinks and bugs
before they post the news item. 

Oh, this is another good line to have in make.conf. 


FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch
parallel-install"


The ones I care about.  The buildpkg tells it to save binary copies. 
This is a must if done in a chroot and you want to install elsewhere as
binaries but comes in handy if you accidentally remove something and
need it back fast or you need to restore something you removed and broke
portage.  The fetch option just tells it to fork the download part and
keep downloading until it has everything it needs to update.  The
install option I think tells it to do more than one install at a time
instead of one at a time.  I've never had a problem with this.  If
something is going to clash, emerge sets a lock file and waits until the
other package is installed.  I think the others were the default when I
installed.  Check the man page maybe????

What you just read is from about 20 years of tweaking things on half a
dozen rigs.  It should get you off to a good start for sure. 

Dale

:-)  :-) 

P. S.  I'm starting to hate this keyboard on emails like this.  :-@  It
does give me practice tho.  lol 

Re: [gentoo-user] emerge - Tips and Tricks

[Joe]

On 9/1/24 16:56, Dale wrote:
> Joe wrote:
>> Hello,
>>
>>
>> I'm looking for some tips and tricks regarding emerge. I know there is
>> a cheat sheet on what stuff you can do. But i would like emerge
>> exclusively .
>>
>> Normally i run emerge -uavDU --with-bdeps=y @world when i don't want a
>> reinstall of everything after a emerge --sync
>>
>> I run emerge -uavDN --with-bdeps=y @world when i want to reinstall or
>> like the manual says if there is a use flag that has been changed by
>> me or the dev.
>>
>>
>> Am i doing it right or what should i do that can help me and newer people
>>
>>
>> Thanks
>>
>>
>> Joe
> 
> I been using Gentoo since 2003.  The emerge program has come a LONG way
> since then.  Over the years tho, I've refined my update process until I
> got to a point where it won't get any better.  You will still run into
> the occasional update that requires the use of a hammer but for the most
> part, this does well.  First thing.  I have a set of options in
> make.conf to cover most options.  That line looks like this.
> 
> 
> EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=500 --keep-going -v
> --quiet-build=y -1 --unordered-display --jobs=16 --load-average 8"
> 
> 
> A couple of those are either personal preference or machine dependent.
> The bdeps option will cause extra rebuilds on occasion but it is rare
> that I get a seg fault or programs that just crash because the versions
> don't work well together.  Before that option was available, I used to
> do a emerge -e world to fix problems with programs not starting or
> crashing with a seg fault.  The bdeps options seems to have improved
> that a LOT.  The backtrack option just makes sure you only have to run
> emerge -a<whatever> once.  It takes a while sometimes but it digs deep,
> real deep.  If a update can be done, it will find a way.  Honestly, 100
> is likely more than enough in most all cases.  The keep-going option is
> good for when a packages fails, especially early on, and it stops the
> update.  On most occasions, emerge can regroup and continue on skipping
> only one or a very few packages.  It saves time in the long run if you
> start a update and don't monitor it.  The -1 option is the same as
> oneshot.  This prevents you from accidentally cluttering up the world
> file.  Something gives you problems and you are emerging by hand, if you
> forget to add the -1 as you work to fix it, it adds all those to the
> world file, including version if you specify one.  I'm not sure on the
> display option.  I added it for some reason, ages ago.  The job and load
> is different for each machine.  The line above is for a 16 core, 32
> thread CPU with 64GBs of ram.  My old 8 core with 32GBs of ram was set
> to jobs 8 and load 3 I think.  Memory is one limiting factor there.
> LOo, that qt package and a couple others can fail from lack of memory if
> set higher.
> 
> Second thing.  My usual update process.  I sync first.  I run emerge
> -auDN world and check what it plans to do.  I mostly check USE flags.
> Sometimes a USE flag will change and I have to adjust them a bit.
> Sometimes on a per package basis, sometimes global.  Once I'm happy with
> what it wants to do, I hit the 'y' key and turn her lose.
> 
> On both my old rig and new rig, I have a second install that is in a
> chroot.  When I have packages that take a long time to build, I do my
> updates in the chroot first and then copy over the binaries.  Then I
> just need to do a emerge -aukDN world to make the update faster since it
> is already compiled.  This can be handy when you have some of the qt
> packages and the software has different versions and it causes
> problems.  Some updates midway can make it so certain programs won't
> launch at all.  I've had that happen with Kwrite several times, Dolphin
> a few times.  Once the update is done and you logou and back in,
> everything works again.  You just may run into problems during the
> update when some packages are old still and some are new.  This method
> lessens the time of that problem.
> 
> Once the update is done, I then run emerge -a --depclean and see if
> anything needs to be removed or if I need to add something I want to
> keep to the world file.  Oh, if you want to emerge something and add it
> to the world file so it gets updated and saved, emerge --select y plus
> your other options will override the oneshot option.  If you run a GUI,
> you need to logout and back in.  I sometimes switch to the boot runlevel
> and check for services that need to be restarted as well.  One could
> reboot and achieve the same goal.  This is Linux tho.  ;-)
> 
> Obviously, a news item can change that process.  If there is a news item
> with a different process, follow that for sure.  Following the news item
> to the letter is the best way.  The devs work out all the kinks and bugs
> before they post the news item.
> 
> Oh, this is another good line to have in make.conf.
> 
> 
> FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch
> parallel-install"
> 
> 
> The ones I care about.  The buildpkg tells it to save binary copies.
> This is a must if done in a chroot and you want to install elsewhere as
> binaries but comes in handy if you accidentally remove something and
> need it back fast or you need to restore something you removed and broke
> portage.  The fetch option just tells it to fork the download part and
> keep downloading until it has everything it needs to update.  The
> install option I think tells it to do more than one install at a time
> instead of one at a time.  I've never had a problem with this.  If
> something is going to clash, emerge sets a lock file and waits until the
> other package is installed.  I think the others were the default when I
> installed.  Check the man page maybe????
> 
> What you just read is from about 20 years of tweaking things on half a
> dozen rigs.  It should get you off to a good start for sure.
> 
> Dale
> 

Thanks,

This is more then i could have imagined. I've used Gentoo off and on for 
about a year. Sometimes i go to another distro like Debian but i keep 
coming back because of emerge use flags everything. i just like the control.

This is my main distro from now on. The community is the best. hope this 
helps somebody else also

Thanks

Joe

Re: [gentoo-user] emerge - Tips and Tricks

[Dale]

Joe wrote:
>
>
> On 9/1/24 16:56, Dale wrote:
>> Joe wrote:
>>> Hello,
>>>
>>>
>>> I'm looking for some tips and tricks regarding emerge. I know there is
>>> a cheat sheet on what stuff you can do. But i would like emerge
>>> exclusively .
>>>
>>> Normally i run emerge -uavDU --with-bdeps=y @world when i don't want a
>>> reinstall of everything after a emerge --sync
>>>
>>> I run emerge -uavDN --with-bdeps=y @world when i want to reinstall or
>>> like the manual says if there is a use flag that has been changed by
>>> me or the dev.
>>>
>>>
>>> Am i doing it right or what should i do that can help me and newer
>>> people
>>>
>>>
>>> Thanks
>>>
>>>
>>> Joe
>>
>> I been using Gentoo since 2003.  The emerge program has come a LONG way
>> since then.  Over the years tho, I've refined my update process until I
>> got to a point where it won't get any better.  You will still run into
>> the occasional update that requires the use of a hammer but for the most
>> part, this does well.  First thing.  I have a set of options in
>> make.conf to cover most options.  That line looks like this.
>>
>>
>> EMERGE_DEFAULT_OPTS="--with-bdeps y --backtrack=500 --keep-going -v
>> --quiet-build=y -1 --unordered-display --jobs=16 --load-average 8"
>>
>>
>> A couple of those are either personal preference or machine dependent.
>> The bdeps option will cause extra rebuilds on occasion but it is rare
>> that I get a seg fault or programs that just crash because the versions
>> don't work well together.  Before that option was available, I used to
>> do a emerge -e world to fix problems with programs not starting or
>> crashing with a seg fault.  The bdeps options seems to have improved
>> that a LOT.  The backtrack option just makes sure you only have to run
>> emerge -a<whatever> once.  It takes a while sometimes but it digs deep,
>> real deep.  If a update can be done, it will find a way.  Honestly, 100
>> is likely more than enough in most all cases.  The keep-going option is
>> good for when a packages fails, especially early on, and it stops the
>> update.  On most occasions, emerge can regroup and continue on skipping
>> only one or a very few packages.  It saves time in the long run if you
>> start a update and don't monitor it.  The -1 option is the same as
>> oneshot.  This prevents you from accidentally cluttering up the world
>> file.  Something gives you problems and you are emerging by hand, if you
>> forget to add the -1 as you work to fix it, it adds all those to the
>> world file, including version if you specify one.  I'm not sure on the
>> display option.  I added it for some reason, ages ago.  The job and load
>> is different for each machine.  The line above is for a 16 core, 32
>> thread CPU with 64GBs of ram.  My old 8 core with 32GBs of ram was set
>> to jobs 8 and load 3 I think.  Memory is one limiting factor there.
>> LOo, that qt package and a couple others can fail from lack of memory if
>> set higher.
>>
>> Second thing.  My usual update process.  I sync first.  I run emerge
>> -auDN world and check what it plans to do.  I mostly check USE flags.
>> Sometimes a USE flag will change and I have to adjust them a bit.
>> Sometimes on a per package basis, sometimes global.  Once I'm happy with
>> what it wants to do, I hit the 'y' key and turn her lose.
>>
>> On both my old rig and new rig, I have a second install that is in a
>> chroot.  When I have packages that take a long time to build, I do my
>> updates in the chroot first and then copy over the binaries.  Then I
>> just need to do a emerge -aukDN world to make the update faster since it
>> is already compiled.  This can be handy when you have some of the qt
>> packages and the software has different versions and it causes
>> problems.  Some updates midway can make it so certain programs won't
>> launch at all.  I've had that happen with Kwrite several times, Dolphin
>> a few times.  Once the update is done and you logou and back in,
>> everything works again.  You just may run into problems during the
>> update when some packages are old still and some are new.  This method
>> lessens the time of that problem.
>>
>> Once the update is done, I then run emerge -a --depclean and see if
>> anything needs to be removed or if I need to add something I want to
>> keep to the world file.  Oh, if you want to emerge something and add it
>> to the world file so it gets updated and saved, emerge --select y plus
>> your other options will override the oneshot option.  If you run a GUI,
>> you need to logout and back in.  I sometimes switch to the boot runlevel
>> and check for services that need to be restarted as well.  One could
>> reboot and achieve the same goal.  This is Linux tho.  ;-)
>>
>> Obviously, a news item can change that process.  If there is a news item
>> with a different process, follow that for sure.  Following the news item
>> to the letter is the best way.  The devs work out all the kinks and bugs
>> before they post the news item.
>>
>> Oh, this is another good line to have in make.conf.
>>
>>
>> FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch
>> parallel-install"
>>
>>
>> The ones I care about.  The buildpkg tells it to save binary copies.
>> This is a must if done in a chroot and you want to install elsewhere as
>> binaries but comes in handy if you accidentally remove something and
>> need it back fast or you need to restore something you removed and broke
>> portage.  The fetch option just tells it to fork the download part and
>> keep downloading until it has everything it needs to update.  The
>> install option I think tells it to do more than one install at a time
>> instead of one at a time.  I've never had a problem with this.  If
>> something is going to clash, emerge sets a lock file and waits until the
>> other package is installed.  I think the others were the default when I
>> installed.  Check the man page maybe????
>>
>> What you just read is from about 20 years of tweaking things on half a
>> dozen rigs.  It should get you off to a good start for sure.
>>
>> Dale
>>
>
> Thanks,
>
> This is more then i could have imagined. I've used Gentoo off and on
> for about a year. Sometimes i go to another distro like Debian but i
> keep coming back because of emerge use flags everything. i just like
> the control.
>
> This is my main distro from now on. The community is the best. hope
> this helps somebody else also
>
> Thanks
>
> Joe
>


If you have a laptop where heat is a issue, you may want to do things
different but if you can, that will give you the most stable system for
updates.  Also, I tend to update once a week.  Sometimes I'll skip a
week.  I get emails about KDE releases and kinda go by that.  I usually
pick Saturday night or Sunday morning.  Lots of updates seem to hit late
in the week mostly, that I worry about anyway.  On a laptop, I'd go with
one month maybe six weeks, to avoid the extra builds.  With Gentoo,
going any further can have you hitting updates that may have a more
difficult update path.

I might also add, my NAS systems or my old rig that is a backup in case
new rig takes a break, I update those around the first of each month. 
The updates go smoothly even with that duration.  I didn't update a
system once for about six months, it got tricky.  If unable to update
often, once every couple months is about as far as I would want to go. 
Some update daily tho.  I just don't see the need for that myself.
Basically, three or four months would be the limit for me in any
situation.  Weekly is about the fastest I would update. 

Also, I run a mix of stable and unstable here.  Still, my rigs once set
up and running well, tend to be really solid and problem free.  Setting
up this new rig, I had a few issues to work through but my current
uptime is about 45 days.  Other than adding some cgroup drivers, my
kernel is solid.  No panics or anything.  I credit the awesome work of
the emerge devs, the devs of every ebuild I use and my process of
updating.  On the stable side, anything required to boot.  KDE and
friends tend to be unstable.  I suspect most of the upgrade issues I do
run into are because of that mix.  If you run stable and only stable, it
is likely even smoother.  A lot of problems are worked out during the
stabilization process. 

It seems you plan to stick around for a while.  I hope this info helps
you to have a smooth running system.  I do wish someone would take this
info and put it on the wiki for new users tho.  The best thing I ever
did, add -1 as a default option in make.conf. 

Dale

:-)  :-) 

P. S.  Dang, only a few typos this time.  O_O  Crap, make that four. 
Dang was 'da,g'.  Fixed it tho.  ROFL

Re: [gentoo-user] emerge - Tips and Tricks

[Wols Lists]

On 02/09/2024 06:11, Dale wrote:
> If you have a laptop where heat is a issue, you may want to do things
> different but if you can, that will give you the most stable system for
> updates.

Another tip - if you run into any problems, try to emerge @system, not 
@world.

If you know you've successfully emerged @system and you get loads of 
stuff blocking with an @world, I tend to just unmerge all the blockers 
until @world fires successfully. You need to be a bit careful, you could 
still unmerge something important, but it's unlikely. Although these 
problems also tend to be fixed by backtrack=100.

Cheers,
Wol

Re: [gentoo-user] emerge - Tips and Tricks

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Monday, 2 September 2024 07:59:20 BST Wols Lists wrote:
> On 02/09/2024 06:11, Dale wrote:
> > If you have a laptop where heat is a issue, you may want to do things
> > different but if you can, that will give you the most stable system for
> > updates.
> 
> Another tip - if you run into any problems, try to emerge @system, not
> @world.
> 
> If you know you've successfully emerged @system and you get loads of
> stuff blocking with an @world, I tend to just unmerge all the blockers
> until @world fires successfully. You need to be a bit careful, you could
> still unmerge something important, but it's unlikely. Although these
> problems also tend to be fixed by backtrack=100.
> 
> Cheers,
> Wol

You can remove blockers manually and I admit to do it occasionally, but it can 
sometimes break your system if you don't pay particular attention and you 
inadvertently remove some critical toolchain software - e.g. python, glibc, 
gcc, et al.  It is safer to run:

emerge --depclean -v -p <some_package>

and check what dependencies of <some_package> are complaining about your 
attempt to remove it.  Should you come across python or something portage 
depends on, it's best to back off and ask before you decide how to proceed.  
Soft blockers (b) are dealt with automatically by emerge, it is hard blockers 
(B) you'd have to pay attention to.

My typical update runs like this:

eix-sync
emerge -uaNDv @world
dispatch-conf
emerge --depclean -a -v
eclean-dist

If the emerge output asks me to, I also run:

revdep-rebuild

and when perl itself goes through a major update, I run:

perl-cleaner --reallyall

Enjoy your gentoo!

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: emerge - Tips and Tricks

[Nuno Silva]

On 2024-09-02, Michael wrote:

> On Monday, 2 September 2024 07:59:20 BST Wols Lists wrote:
>> On 02/09/2024 06:11, Dale wrote:
>> > If you have a laptop where heat is a issue, you may want to do things
>> > different but if you can, that will give you the most stable system for
>> > updates.
>> 
>> Another tip - if you run into any problems, try to emerge @system, not
>> @world.
>> 
>> If you know you've successfully emerged @system and you get loads of
>> stuff blocking with an @world, I tend to just unmerge all the blockers
>> until @world fires successfully. You need to be a bit careful, you could
>> still unmerge something important, but it's unlikely. Although these
>> problems also tend to be fixed by backtrack=100.
>> 
>> Cheers,
>> Wol
>
> You can remove blockers manually and I admit to do it occasionally, but it can 
> sometimes break your system if you don't pay particular attention and you 
> inadvertently remove some critical toolchain software - e.g. python, glibc, 
> gcc, et al.  It is safer to run:
>
> emerge --depclean -v -p <some_package>
>
> and check what dependencies of <some_package> are complaining about your 
> attempt to remove it.  Should you come across python or something portage 
> depends on, it's best to back off and ask before you decide how to proceed.  
> Soft blockers (b) are dealt with automatically by emerge, it is hard blockers 
> (B) you'd have to pay attention to.
>
> My typical update runs like this:
>
> eix-sync
> emerge -uaNDv @world
> dispatch-conf
> emerge --depclean -a -v
> eclean-dist
>
> If the emerge output asks me to, I also run:
>
> revdep-rebuild
>
> and when perl itself goes through a major update, I run:
>
> perl-cleaner --reallyall
>
> Enjoy your gentoo!

Could --ignore-world be of use in cases where blockers are complicating
things too much? Might make sense e.g. if an emerge upgrade is needed
before other upgrades but python eclass changes are blocking things
creating cyclic dependencies.

(Requires a lot of careful analysis, of course...)

-- 
Nuno Silva

Re: [gentoo-user] emerge - Tips and Tricks

[Matt Connell]

On Sun, 2024-09-01 at 18:56 -0500, Dale wrote:
> FEATURES="-usersync userpriv usersandbox buildpkg sandbox
> parallel-fetch parallel-install"

No candy?  You struck me as a candy guy.

Re: [gentoo-user] emerge - Tips and Tricks

[Dale]

Matt Connell wrote:
> On Sun, 2024-09-01 at 18:56 -0500, Dale wrote:
>> FEATURES="-usersync userpriv usersandbox buildpkg sandbox
>> parallel-fetch parallel-install"
> No candy?  You struck me as a candy guy.
>
>
>


I'll admit, I haven't touched that setting in ages.  Likely a decade or
more.  I'm not sure what options are even available now that wasn't
before. 

This thing has candy?  I like candy.  The area below my ribs likes candy
too.  Candy tends to stick around.  LOL 

Dale

:-)  :-) 

Re: [gentoo-user] emerge - Tips and Tricks

[Wols Lists]

On 02/09/2024 00:56, Dale wrote:
> Obviously, a news item can change that process.  If there is a news item
> with a different process, follow that for sure.  Following the news item
> to the letter is the best way.  The devs work out all the kinks and bugs
> before they post the news item.

Find the other commands (like perl-cleaner) that you really ought to run 
but are not part of emerge - CPAN predates even linux I believe, so they 
expect us to adjust to them ...

I followed the Python update to the letter, and it just refused to run 
... until I ran perl-cleaner.

perl-cleaner is basically "emerge for perl" - it goes through and sorts 
out all your CPAN dependencies.

Cheers,
Wol

Re: [gentoo-user] emerge - Tips and Tricks

[Dale]

Wols Lists wrote:
> On 02/09/2024 00:56, Dale wrote:
>> Obviously, a news item can change that process.  If there is a news item
>> with a different process, follow that for sure.  Following the news item
>> to the letter is the best way.  The devs work out all the kinks and bugs
>> before they post the news item.
>
> Find the other commands (like perl-cleaner) that you really ought to
> run but are not part of emerge - CPAN predates even linux I believe,
> so they expect us to adjust to them ...
>
> I followed the Python update to the letter, and it just refused to run
> ... until I ran perl-cleaner.
>
> perl-cleaner is basically "emerge for perl" - it goes through and
> sorts out all your CPAN dependencies.
>
> Cheers,
> Wol

This is true.  I always forget to run perl update and python tools as
well.  I rarely have issues but it is likely a good idea to run it when
one of those are updated, just to be safe. 

Joe, add that to your list.  ;-) 

Dale

:-)  :-) 

Re: [gentoo-user] emerge - Tips and Tricks

[ralfconn]

Il 02/09/24 01:56, Dale ha scritto:
> FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch
> parallel-install"
> 
> 
> The ones I care about.  The buildpkg tells it to save binary copies.
> This is a must if done in a chroot and you want to install elsewhere as
> binaries but comes in handy if you accidentally remove something and
> need it back fast or you need to restore something you removed and broke
> portage.  The fetch option just tells it to fork the download part and
> keep downloading until it has everything it needs to update.  The
> install option I think tells it to do more than one install at a time
> instead of one at a time.  I've never had a problem with this.  If
> something is going to clash, emerge sets a lock file and waits until the
> other package is installed.  I think the others were the default when I
> installed.  Check the man page maybe????
> 


Thanks for bringing this up, it got me wondering what my FEATURES were. 
Mine contains only -userfetch (I don't know why I set that, I will have 
to test) but many other options are set by default:

$ portageq envvar FEATURES | xargs -n 1
assume-digests
binpkg-docompress
binpkg-dostrip
binpkg-logs
binpkg-multi-instance
buildpkg-live
config-protect-if-modified
distlocks
ebuild-locks
fixlafiles
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
userpriv
usersandbox
usersync
xattr

raf

Re: [gentoo-user] emerge - Tips and Tricks

[Dale]

ralfconn wrote:
> Il 02/09/24 01:56, Dale ha scritto:
>> FEATURES="-usersync userpriv usersandbox buildpkg sandbox parallel-fetch
>> parallel-install"
>>
>>
>> The ones I care about.  The buildpkg tells it to save binary copies.
>> This is a must if done in a chroot and you want to install elsewhere as
>> binaries but comes in handy if you accidentally remove something and
>> need it back fast or you need to restore something you removed and broke
>> portage.  The fetch option just tells it to fork the download part and
>> keep downloading until it has everything it needs to update.  The
>> install option I think tells it to do more than one install at a time
>> instead of one at a time.  I've never had a problem with this.  If
>> something is going to clash, emerge sets a lock file and waits until the
>> other package is installed.  I think the others were the default when I
>> installed.  Check the man page maybe????
>>
>
>
> Thanks for bringing this up, it got me wondering what my FEATURES
> were. Mine contains only -userfetch (I don't know why I set that, I
> will have to test) but many other options are set by default:
>
> $ portageq envvar FEATURES | xargs -n 1
> assume-digests
> binpkg-docompress
> binpkg-dostrip
> binpkg-logs
> binpkg-multi-instance
> buildpkg-live
> config-protect-if-modified
> distlocks
> ebuild-locks
> fixlafiles
> 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
> userpriv
> usersandbox
> usersync
> xattr
>
> raf
>
>


If you find a place that explains all those and what they do, please
share a link.  I'd like to know too.  I didn't find anything on the
wiki.  I added to the defaults on this new rig but didn't change what
was already there.  Adding something may help me as well.  We both need
to know what each one does as it could have unintended effects. 

This is my list using the same command you used.  It seems some are set
in other places. 


root@Gentoo-1 / # portageq envvar FEATURES | xargs -n 1
assume-digests
binpkg-docompress
binpkg-dostrip
binpkg-logs
binpkg-multi-instance
buildpkg
buildpkg-live
config-protect-if-modified
distlocks
ebuild-locks
fixlafiles
ipc-sandbox
merge-sync
merge-wait
multilib-strict
network-sandbox
news
parallel-fetch
parallel-install
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
xattr
root@Gentoo-1 / #

Thanks. 

Dale

:-)  :-) 

Re: [gentoo-user] emerge - Tips and Tricks

[Arve Barsnes]

On Tue, 3 Sept 2024 at 09:49, Dale <rdalek1967@gmail.com> wrote:
> If you find a place that explains all those and what they do, please
> share a link.  I'd like to know too.  I didn't find anything on the
> wiki.

They're in the man pages.
man 4 make.conf
https://devmanual.gentoo.org/eclass-reference/make.conf/index.html

Cheers,
Arve

Re: [gentoo-user] emerge - Tips and Tricks

[Arve Barsnes]

On Tue, 3 Sept 2024 at 11:05, Arve Barsnes <arve.barsnes@gmail.com> wrote:
>
> On Tue, 3 Sept 2024 at 09:49, Dale <rdalek1967@gmail.com> wrote:
> > If you find a place that explains all those and what they do, please
> > share a link.  I'd like to know too.  I didn't find anything on the
> > wiki.
>
> They're in the man pages.
> man 4 make.conf
> https://devmanual.gentoo.org/eclass-reference/make.conf/index.html

That should be:
man ***5*** make.conf

Re: [gentoo-user] emerge - Tips and Tricks

[Dale]

Arve Barsnes wrote:
> On Tue, 3 Sept 2024 at 11:05, Arve Barsnes <arve.barsnes@gmail.com> wrote:
>> On Tue, 3 Sept 2024 at 09:49, Dale <rdalek1967@gmail.com> wrote:
>>> If you find a place that explains all those and what they do, please
>>> share a link.  I'd like to know too.  I didn't find anything on the
>>> wiki.
>> They're in the man pages.
>> man 4 make.conf
>> https://devmanual.gentoo.org/eclass-reference/make.conf/index.html
> That should be:
> man ***5*** make.conf
>
>


Well, I searched first on the wiki then did a DDG search, the duck
search thing.  None of them found that.  o_O 

Thanks for the link.  Now we both have some reading to do.  At first
glance, I don't see anything I think I should change. 

Dale

:-)  :-) 

Re: [gentoo-user] emerge - Tips and Tricks

[ralfconn]

Il 02/09/24 00:44, Joe ha scritto:

> Normally i run emerge -uavDU --with-bdeps=y @world when i don't want a 
> reinstall of everything after a emerge --sync
> 
> I run emerge -uavDN --with-bdeps=y @world when i want to reinstall or 
> like the manual says if there is a use flag that has been changed by me 
> or the dev.
> 

My make.conf:

EMERGE_DEFAULT_OPTS="--quiet-build --keep-going --jobs 24 --load-average 
24.0"
MAKEOPTS="-j24 -l24.0"

I don't know if I got the load-average and company right, anyway the 
system is always responsive (Ryzen 9 with 64Gb) even when using all 24 
CPU threads. The ebuilds have gotten a long way towards stability even 
in ~amd64, I rarely have build problems (except when cross-compiling for 
ARM, but that's a different story).

My command line is 'emerge -auDvN @world'. Let the system decide if 
there are USE flag changes that require a rebuild, computers should do 
the boring stuff for us 🙂

raf