Joel Roth wrote: > Bob Proulx wrote: > > Joel Roth wrote: > > > I'm just so used to the dependencies being taken > > > care of by APT, that I was surprised to have to > > > lift my little pinkie. > > > > Uhm... An 'apt-get upgrade' should have offered those for upgrade. > > They do for me. They didn't for you? Perhaps you have pinning or > > other preventatives in place? Please say more! > > Ah, I didn't even think to try an apt-get upgrade. !!?? Shock! Surprise! It is the *first* thing I think of to try to fix something. > I usually just upgrade apps individually as I need to... As in 'apt-get install openssh-client' ? But that won't upgrade any of the dependencies. > an attitude based on (possibly) outdated fears of > getting stuck in between upgrades of C libraries > or other large-scale brokenness. As others commented (but I wanted to directly address this) you shouldn't have this worry like this. And actually not getting upgrades in a timely manor is a worse problem. On Sid/Unstable I upgrade daily with: # apt-get update # apt-get upgrade # apt-get dist-upgrade The first sync's the Packages files, the index of what is current. Then the 'upgrade' is a very restricted upgrade that only upgrades packages in place. It cannot pull in any new packages such as when a package is split or when a package gains new dependencies. But most important it cannot remove packages. Then 'dist-upgrade' and I look at the screen for dist-upgrade very carefully. I cannot stress this enough. Look at that very carefully. Most important is to check to see if any packages are going to be removed. If a bind9 update wants to install new liblwres80 that is okay. But if a netcf upgrade wants to remove kvm (Bug#694362 for example) then do not do it! Examine the problem and apply "hold" to dpkg as needed to whatever packages are appropriate 'apt-mark hold pkg' is a convenient frontend to 'echo pkg hold | dpkg --set-selections'. After holding try the dist-upgrade again. Repeat as needed until the result is satisfactory. If this is needed then file a bug report. I do this every day. Because the changes from one day to the next day are small enough that I can work through them and recognize them as they occur. If I were to wait six months then the amount of thrash in Sid/Unstable would make recognizing and reducing these problems much more difficult. Also a Sid/Unstable upgrade that was from a year ago to today may need special handling that was already taken care of in other ways. In a day to day transition everything will be current and rolling. But after a long time people forget and the upgrade may be broken in ways that don't matter to anyone else and therefore will never get fixed. Remember that only major release points such as Squeeze and Wheezy are extensively tested across long times and large changes. Major releases will work, within the documented procedures from the upgrade notes. But what amounts to a similar major upgrade between Sid-2011 and Sid-2012 won't be tested at all. You are on your own. > an attitude based on (possibly) outdated fears of > getting stuck in between upgrades of C libraries > or other large-scale brokenness. In summary if running Sid/Unstable or Testing too then I think it is best to keep current and not let the parts get too old and stale. It is just easier that way. "In for a penny, in for a pound." > Thanks for your comment. This list/community is a great support. It seriously is one of the best things! Bob
Attachment:
signature.asc
Description: Digital signature