I just installed net-misc/openssh-4.2_p1-r1 on one of my Gentoo servers, as required by GLSA 200602-11. My profile is: root # ls -ld /etc/make.profile lrwxrwxrwx 1 root root 40 Nov 4 2004 /etc/make.profile -> ../usr/portage/profiles/hardened/x86/2.6 Here are two problems I noticed: 1) When I tried to "/etc/init.d/sshd restart", I immediately noticed I couldn't log in any more, because the old "/etc/pam.d/pamd" changed from... auth required pam_stack.so service=system-auth auth required pam_shells.so auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth ...to... auth include system-auth auth required pam_shells.so auth required pam_nologin.so account include system-auth password include system-auth session include system-auth Notice I have last stable pam version: root # equery list pam [ Searching for package 'pam' in all categories among: ] * installed packages [I--] [ ] sys-apps/pam-login-3.14 (0) [I--] [ ] sys-libs/pam-0.78-r3 (0) 2) If i do "ps aux" i see "[...]/usr/sbin/sshd -o PidFile=/var/run/.pid" instead of "[...]/var/run/sshd.pid"! This is because "/etc/init.d/sshd" requires the SVCNAME variable. This variable is defined in "/etc/init.d/runscript.sh" but unfortunately this file is not included in old baselayouts like the one I have on this server: root # equery list baselayout [ Searching for package 'baselayout' in all categories among: ] * installed packages [I--] [M ] sys-apps/baselayout-1.9.4-r6 (0) So I suppose it would be wise to include some baselayout dependancy in openssh ebuild. I flagged this bug as "blocker" because I risked to loose control of my remote server... luckly, after restarting the service, I tried to login from a second shell and I noticed the first problem before closing the main shell.
Upgrade your ridiculously outdated baselayout.
(In reply to comment #1) > Upgrade your ridiculously outdated baselayout. That's exactly my point! Upgrading my ridiculously outdated baselayout its of course the right thing to do, but I expect portage to tell me about it, not having to find it out myself: that's what dependancies are for! In such situation I expect portage to tell me one of the following: 1) Your profile is deprecated 2) [blocks B] <sys-apps/baselayout-x.y.z (is blocking net-misc/openssh-x.y.z) 3) Say nothing and upgrade baselayout to the minimum required version together with the new openssh version. I manage several servers spread across several firms: I don't usually do system upgrades on production servers unless there is some GLSA or the customer requests some new functionality, and I think this is a quite common sys admin behaviour. For this reason I expect portage to manage package dependancies, even if I have some very old packages on my system.
(In reply to comment #2) > For this reason I expect portage to manage package dependancies, > even if I have some very old packages on my system. Portage will manage your dependencies just fine when using 'emerge -uD world' and will upgrade your non-existant baselayout version just fine as well. Every init script has an implicit dependency on baselayout that *at least* exists in the tree, not one that has been removed half year ago. baselayout-1.11.x has been marked stable 8 months ago, plenty time to upgrade; and current stable udev depends on it anyway. Closing.
