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. > 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. > 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 Bob
Attachment:
signature.asc
Description: Digital signature