# seven steps to upgrade Gentoo System

## sipingal

There is no a full HOWTO introducing whole system upgrading. I hope this simple document can help someone else.

1. sync portage tree(eix-sync is recommended)

```
# eix-sync
```

or

```
# emerge --sync

```

2. upgrade whole system

```
# emerge -avuDN --with-bdeps y --keep-going world
```

3. make configuration file(s) up to date

```
# etc-update
```

or

```
# dispatch-conf
```

4.  fix static library

```
# lafilefixer --justfixit | grep -v skipping 
```

5. uninstall useless packages

```
# emerge -av --depclean
```

6. Reverse dynamic library Dependency

```
# revdep-rebuild
```

7. clean source code of the old packages

```
# eclean -d distfiles
```

Last edited by sipingal on Thu Dec 17, 2009 6:38 am; edited 2 times in total

----------

## alunduil

I like it, but I'm not sure I'd agree with the --keep-going on the world update.  I've seen that cause a few problems that would have been easier to handle if the emerge had died at the first sign of trouble.

On a different note, is a full system upgrade the process of checking everything for updates?  If so, then you need to add at least an:

```

emerge -DuvaN system

```

Otherwise you can also consider rebuilding the entire set (Due to modifications to gcc or another piece of the toolchain) via:

```

emerge -ave system && emerge -ave system && emerge -ave world

```

That last one isn't really an upgrade, but it might be appropriate to mention it and when it's applicable.

Just a couple of suggestions.

Thanks for the document.

Regards,

Alunduil

----------

## huckabuck

i'd definitely run revdep-rebuild after --depclean , and not before ... since thats the warning posted when you run it anyway.  And i run it as 

```
emerge -pv --depclean
```

 before i execute it. I've had shit break after it cleans up.

----------

## sipingal

 *huckabuck wrote:*   

> i'd definitely run revdep-rebuild after --depclean , and not before ... since thats the warning posted when you run it anyway.  And i run it as 
> 
> ```
> emerge -pv --depclean
> ```
> ...

 

Thanks, fixed.  :Wink: 

----------

## Bircoph

1) Sometimes depclean should be run twice: before and after revdep-rebuild.

2) You missed very important step between 2 and 3: fix dozen of compilation/install failures  :Wink: .

3) lafixer is often needed during world update due to failed packages because some "useless" *.la file was removed from the system.

----------

## NotQuiteSane

I though  this was how you kept the system up to date?

NQS

----------

## d2_racing

For my concern, I always run this :

```

# emerge -auDNv world

# dispatch-conf

# revdep-rebuild -i

# eclean-dist -id

```

----------

## d2_racing

I'm not really sure if it's a good thing this command :

```

# emerge -avuDN --with-bdeps y --keep-going world

```

If it crash, I want to see it actually, so --keep-going is maybe not a good idea for someone who is new to Gentoo.

----------

## keenblade

 *d2_racing wrote:*   

> I'm not really sure if it's a good thing this command :
> 
> ```
> 
> # emerge -avuDN --with-bdeps y --keep-going world
> ...

 

I think "--keep-going" is very good most times. When I wake up, I don't want to see a world update has interrupted at the beginning, because Frozen-Bubble failed to emerge. If an important package fails, mostly it and some depended packages fails and nothing more. It is very very rare that something bad can happen. I am using it since it is available. Nothing wrong has gone with it. Also at the end, portage gives a list of failed emerges.

My update way:

```

layman -S ; eix-sync ; emerge -vuDNf world ; emerge -vuD --reinstall changed-use --keep-going world --with-bdeps=y ; update-live-ebuilds ; emerge -v1 --keep-going @preserved-rebuild ; etc-proposals

```

This way I first fetch all the sources, then update if necessary.

----------

## Bircoph

 *d2_racing wrote:*   

> I'm not really sure if it's a good thing this command :
> 
> ```
> 
> # emerge -avuDN --with-bdeps y --keep-going world
> ...

 

This is very good command indeed, it saved several days of my life.

When you performing large updage (e.g. 2100+ packages installed and update once per two months) on ~arch, some packages will definitely cease to compile. Usually I have one failure per 50-100 packages being updated.

Without --keep-going option update will stop after each error, and I personally can't monitor it 24/7, but only at evenings or spare time on weekends. Thus huge amount of time and my nerves will be lost due to near dozen of such breaks. With --keep-going option you can see in the end what dies, you can always read build logs in /var/tmp/portage/ and decide what action should be done to fix the problem. --keep-going way approach requires one/two time manual intervention in the build process, which saves both time and health.

And one additional point should be emphasized: always read emerge output, even if this takes several dozens of screens. Some notes are almost critical for normal further performance: e.g. you must rebuild all x11-drivers installed (even if they are not updated) if Xorg was updated from x0.y0.z0 to x1.y1.z1, where x or y changed; otherwise you will encounter very unpleasant situation when both keyboard and mouse cease to work after X upgrade.

----------

## d2_racing

 *Bircoph wrote:*   

> And one additional point should be emphasized: always read emerge output, even if this takes several dozens of screens. Some notes are almost critical for normal further performance: e.g. you must rebuild all x11-drivers installed (even if they are not updated) if Xorg was updated from x0.y0.z0 to x1.y1.z1, where x or y changed; otherwise you will encounter very unpleasant situation when both keyboard and mouse cease to work after X upgrade.

 

I use elogv to see that is going on my box too.

```

# emerge -av elogv

```

Then add this inside your make.conf

```

PORTAGE_ELOG_CLASSES="log warn error info"

PORTAGE_ELOG_SYSTEM="echo:log,warn,error,info  save:log,warn,error,info syslog:error"

```

----------

## drescherjm

 *Quote:*   

> Without --keep-going option update will stop after each error, and I personally can't monitor it 24/7, but only at evenings or spare time on weekends. Thus huge amount of time and my nerves will be lost due to near dozen of such breaks. With --keep-going option you can see in the end what dies, you can always read build logs in /var/tmp/portage/ and decide what action should be done to fix the problem. --keep-going way approach requires one/two time manual intervention in the build process, which saves both time and health. 

 

Agreed. To me this is a huge time saver. Before that I had to use external scripts for this. On most machines (even at work) I make that default with

```
EMERGE_DEFAULT_OPTS="--keep-going --jobs 6"
```

in my /etc/make.conf

and use emerge --ignore to disable that on the rare occasion that I do not want it to keep going.

I do adjust the jobs param for lesser powered systems to 2. This is a quad core.

----------

## Bircoph

 *d2_racing wrote:*   

> 
> 
> ```
> 
> PORTAGE_ELOG_CLASSES="log warn error info"
> ...

 

1. There is no need to duplicate message classes if you do not want to override $PORTAGE_ELOG_CLASSES for current output module. So

```

PORTAGE_ELOG_CLASSES="log warn error info"

PORTAGE_ELOG_SYSTEM="echo save syslog:error"

```

will be the same.

2. After some updates I removed 'info' from $PORTAGE_ELOG_CLASSES: it provides too much useless information. It's too hard to read all this spam for several hundreds of packages.

Ideal solution will be accept info messages for postinstall only, but neither portage's make.conf nor elogv itself provides this kind of filtering. Aside from postinstall info messages I doubt some would want to read about applied patches or auto* hooks.

----------

## diablo465

Thanks guys, very useful information, i just want to mark this post, but it seems post a reply is the only way, right?

----------

## steveL

@diablo465: a bookmark is better. Searching under "my posts", it'll drop out soon enough.

As for the "recipe" consider update. It does all the above, and @preserved-rebuild etc when required, as well as a whole lot more. You can configure practically everything, and it's designed for use in scripts as well as interactively.

(Use the git version, if you try it.)

----------

## gentoo_lamb

Very useful post. Thank you!

----------

## defer-

This howto should be added to wiki.gentoo.org

----------

## molec

great guide, thanks.

```
# eselect news list
```

and/or

```
# eselect news read
```

is something I'm trying to make a habit of. Not sure if it should be added to the guide. It's not essential, but it can save a lot of hassle later on.

----------

