# Yes I want the new gentoo-sources, no I don't

## randalla

I had a humorous (to me) situation happen in my weekly update this morning. My update routine is handled by a script which basically does the following:

1) emerge -quDNv world

2) emerbe -q --depclean

3) revdep-rebuild -q

Pretty simple, and has worked for me for some time. The humor is that when gentoo-sources-2.6.35-r4 was made stable on x86 my servers picked it up. Then it was masked on the 8th of this month, and the stable became 2.6.34-r1. Last night, my servers got the 2.6.34-gentoo-r6 update and installed it. However, when it got to the emerge --depclean phase, it immediately uninstalled 2.6.34-gentoo-r6 because the already existing (and masked) 2.6.35-r4 was newer. Note that I have never unmasked gentoo-sources, nor had it explicitly installed by version. It just failed to uninstall after it had been masked on the 8th.

It all worked out in the end after manually removing the 2.6.35-r4 version and running it again, but kind of humorous when you install something which is then immediately removed.

 :Smile: 

Here's the update log itself (truncated):

[ebuild  NS   ] sys-kernel/gentoo-sources-2.6.34-r6 [2.6.32-r7, 2.6.35-r4]

>>> Emerging (7 of  :Cool:  sys-kernel/gentoo-sources-2.6.34-r6

>>> Jobs: 6 of 8 complete, 1 running                Load avg: 1.24, 1.13, 0.56

>>> Jobs: 6 of 8 complete                           Load avg: 1.41, 1.26, 0.68

>>> Installing (7 of  :Cool:  sys-kernel/gentoo-sources-2.6.34-r6

>>> Jobs: 6 of 8 complete                           Load avg: 1.41, 1.26, 0.68

>>> Jobs: 7 of 8 complete                           Load avg: 1.05, 1.17, 0.74

>>> Jobs: 7 of 8 complete, 1 running                Load avg: 1.05, 1.17, 0.74

Cleaning dependencies:sys-kernel/gentoo-sources: 2.6.34-r6 none 2.6.32-r7 2.6.35-r4 

>>> Waiting 5 seconds before starting...

>>> (Control-C to abort)...

>>> Unmerging in:  5 4 3 2 1 

>>> Unmerging sys-kernel/gentoo-sources-2.6.34-r6...

----------

## PaulBredbury

 *randalla wrote:*   

> My update routine is handled by a script

 

Big mistake. Every distro, especially source-based distros with a live tree, can and do mess up the tree sometimes.

So, I bet your script works great - until the seemingly-random time when it doesn't.

Expecting kiddie volunteers who work for free, to produce perfection, is asking for trouble  :Wink: 

----------

## randalla

 *PaulBredbury wrote:*   

>  *randalla wrote:*   My update routine is handled by a script 
> 
> Big mistake. Every distro, especially source-based distros with a live tree, can and do mess up the tree sometimes.
> 
> So, I bet your script works great - until the seemingly-random time when it doesn't.
> ...

 

As best I can figure, you are trying to be a troll. How's that working out for you?

----------

## StringCheesian

emerge --depclean shows a big scary warning, including the following:

```
Always study the list of packages to be cleaned for any obvious mistakes.
```

So it sounds like scripting it is a bad idea.

----------

## randalla

 *StringCheesian wrote:*   

> emerge --depclean shows a big scary warning, including the following:
> 
> ```
> Always study the list of packages to be cleaned for any obvious mistakes.
> ```
> ...

 

If you don't run revdep-rebuild afterwards it can be. All depclean does is remove orphaned packages. The revdep-rebuild finds anything that might have been broken from the removal, and then installs it accordingly while fixing the dependency. In most normal cases that doesn't cause me problems. I do get a hickup in pecl-imagick sometimes because it doesn't quite get that it needs to be rebuilt when imagemagick changes (but not always).

The message is correct, though. You always need to review what it does. In my case, I let it do it's job and then review the overall process when I get into the office first thing. If these machines were more complicated installs, though, maybe I'd have more troubles. Mostly, they are just LAMP servers, with a few other world packages thrown in. They are well tuned.

Adam.

----------

## Etal

Not at all. Unattended update is bad enough; unattended depclean is asking for trouble.

For recent examples, see the Python 3 unmasking, or the recent Python 2.6.5_p20100801 debacle. For examples with stable, see updates for libpng or expat.

With depclean, a new version of Python/PHP/Perl/Ruby/etc goes stable, depclean removed the slotted version and down go your webapps.

You're supposed to review all updates before updating if you want to stay out of trouble, do a google search if the update looks suspicious, wait for a few days and see if it hasn't been pulled. After the update, read your elogs to see if you need any additional steps.

But an unattended update on production servers? Just wait.

----------

## jordanwb

 *randalla wrote:*   

> 1) emerge -quDNv world

 

Verbosely quiet?

----------

## Hu

No, he requested it be quietly verbose.  It says many things, but only in whispers.  :Wink: 

On a more serious note, while Paul's last paragraph is a bit more pointed than I would like, his point is sound.  Most of the Gentoo developers make a best effort at not committing packages that will break things, but the tree is sufficiently complex that there is no way for them to guarantee that it will work.

As for your assertions with regard to depclean being safe: yes, it is supposed to be safe by virtue of removing only orphans.  However, people have had occasions where depclean got confused and tried to remove important packages, such as the last remaining copy of sys-devel/gcc.  Although such occasions are likely bugs and have probably been fixed, their existence proves it is not absolutely safe.  An additional complication arises if depclean removes a package that is legitimately marked as an orphan, but an automagic dependency caused something important to rely on the package.

----------

## sylvain_

"Mostly, they are just LAMP servers, with a few other world packages thrown in. They are well tuned."

zoo you dont need to automatically uninstall packages. Even Microsoft wont do, they would change registry structure at boot-time but thats another story... Just install a good firewall front of your infrastructure and low your paranoid mode  :Laughing: 

----------

