Bob Proulx wrote: > Joel Roth wrote: > > Bob Proulx wrote: > > > Joel Roth wrote: > > > > 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. > > > > I didn't know that. My first try was apt-get install ssh. > > If the packages were not previously installed then of course the > entire dependency tree is pulled in and installed in order to satisfy > the dependencies. And if a new version dependency appears such as > bind9 for example which always depends upon specific versions of > libraries then those new versions will be upgraded too. But if there > isn't a specific need by stated dependency to pull in a newer version > then it won't be triggered for an install. > > For example 'ssh' has: > > $ apt-cache show ssh | grep ^Depends: > Depends: openssh-client, openssh-server > > $ apt-cache show openssh-client | grep ^Depends: > Depends: libc6 (>= 2.11), libedit2 (>= 2.11-20080614-1), libgssapi-krb5-2 > (>= 1.10+dfsg~), libselinux1 (>= 1.32), libssl1.0.0 (>= 1.0.1), zlib1g (>= > 1:1.1.4), debconf (>= 1.2.0) | debconf-2.0, adduser (>= 3.10), dpkg (>= > 1.7.0), passwd > > I will focus on this part of that collection: > ... libssl1.0.0 (>= 1.0.1) ... > > At the time openssh-client was created and pushed out those were the > minimum versions it required. But then other libs such as libssl1.0.0 > will upgrade independently. They will either need to move forward due > to general needs such as compatibility. Or it might have a security > vulnerability. It will be upgraded to a newer version number. > > Meanwhile the ssh packaging will not have changed. That program is > only using the library. It won't change in order to specify a new > requirement until the next time it is rolled out for whatever reason. > In the meantime it will be perfectly fine. The dependency chain will > be satified with the installed version. Therefore running "install > openssh-client" will also be satisified. > > > Hmmm, and we don't have apt-get --update-dependencies install ssh, > > Of course it would be possible to create such a thing for Debian's APT > but the thinking is rather different. Because if one thing needs to > be upgraded then probably another thing needs to be upgraded too. One > could chase down a particular tree of dependencies only. But why do > that instead of more simply ensuring that everything is up to date. > If one thing is up to date manually but another thing is not then that > other thing is suffering and may be vulnerable to security problems or > other breakage. Better to make sure everything is up to date. > > > I see that I'm 1,680 packages behind... > > Things do change rapidly in Unstable! :-) > > > > On Sid/Unstable I upgrade daily with: > > > > > > # apt-get update > > > # apt-get upgrade > > > # apt-get dist-upgrade > > I should have added at the end that I run "clean" to empty out the > cache directory. Otherwise the buildup of cached packages can consume > all available disk space.
Not knowing that option, I had manually deleted them. > > The resolution of more complicated dependency issues, has > > improved a lot, in my subjective opinion. Let's see how my > > current upgrade goes.... > > There are some current problems. Bug#676485 for example. But I am > confident it will all be worked out before release. > > > Some 1300 were packaged installed by 'upgrade' another 340 > > packages installed by 'dist-upgrade'. > That is a good example of why 'upgrade' followed by 'dist-upgrade' > reduces the problem space for the resolver to deal with. Going from > 1300 to 340 is a huge reduction in problem space size. And for the > human looking over the "remove" list. :-) > > There were minor hiccups. In both cases errors were reported, and > > in both cases an extra apt-get install completed the process. > > Sounds about normal. If you had upgraded daily you would probably > have seen those and a handful more but one at a time as they > happened. The difference is spending time dealing with it lumped > versus amortized over the year. What *is* biting me is that the new multiarch organization won't allow me to (re)install skype, which is expecting ia32-libs and ia32-libs-gtk. > > Your descriptions of the upgrade procedure and how to > > review it and hold packages could be a useful reference > > for users of testing or unstable. > > Where would we put it? > > Also there is: > > > http://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2BAC8-sid_users.3F It would go with that subject matter, but your is text longer and more explanatory, the next level of detail. Many non-experts use unstable. They need to know. How do I keep my Sid-based system current? The best practice is to upgrade your system regularly, and deal with the occasional breakage that occurs. As (Bob Proulx | one expert ) describes it: On Sid/Unstable I upgrade daily with: # apt-get update # apt-get upgrade # apt-get dist-upgrade .... 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." Regards, Joel -- Joel Roth -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20121228024258.GA23311@sprite
