Re: ssh fails - SOLVED (was: Re: git pull fails with OpenSSL version mismatch error)
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
Reply to: