Re: A case study of a new user turned off debian
"Julian Mehnle" <lists@mehnle.net> writes:
> First, I think what Daniel Jacobowitz said is entirely true. Why didn't you
> start with "testing"?
Sure testing is less likely to trigger this.
But testing isn't infallible either. And it shouldn't be mean Debian shouldn't
have better error handling. The easier it is for people to manage a Debian
system when things go wrong the better, regardless of how much the chances of
going wrong are minimized.
> > All he had to do was install an older version of libc6 and every other
> >package would have been happy. All the infrastructure is there to do this,
> >the old packages are all on the ftp/http sites, the package may even be
> >sitting in apt's cache. But there's no interface for it.
>
> Wrong. If, on a "unstable" system, Apt sources for "testing" are also listed
> in /etc/apt/sources.list, you can always do a `apt-get -t testing install
> libc6` or `apt-get install libc6/testing`.
Unfortunately not. apt won't downgrade an already installed package like that.
In any case that doesn't really help. What do you do if testing is 2 months
old as is often the case with things like mozilla. Or if installing the
testing version is exactly what caused the problem?
All I want to do is give up on this new version and go to an earlier version,
most likely the version I had installed five minutes ago. Downgrading to
testing would probably require a whole new set of libraries and more work.
> Or, you could create a file /etc/apt/preferences and pin the "testing" version
> of the package with a high enough priority. See `man apt_preferences`. Then do
> a `apt-get dist-upgrade`.
That's about the last place I would send a new user. I read that man page
about three times during this crisis before I decided it would be hopeless to
try to explain this procedure online.
This is what I meant about there not being an "interface".
If apt said "Hm, version 1.2 of libc failed to configure, would you like to
install the previous version (1.1) from testing and hold back the following
packages that depend on the new one (awk, grep, sed) [Yn]?" That would be an
interface.
If it didn't do anything but "apt-get -f -t testing libc" did that
automatically without explaining what it was doing, that would be an
interface.
Telling people, go edit this random file with to set "pin priorities" for
things to arbitrary numbers, find out what package dependencies fail, add
those to your list of pin priorities, etc. That's not a useful interface for
this case.
In any case having the granularity of "stable", "testing", "unstable" really
doesn't help. All the package versions are in the pool. I want to be able to
tell apt to try such and such version, or at least put back the version I had
before and restore whatever other packages it must to satisfy dependencies.
> > The only interface for rolling back is switching the entire machine to an
> >earlier distribution and telling apt to try to downgrade -- which is unlikely
> >to work. And worse, every time you run apt it only downloads and unpacks *more*
> >packages, all of which, of course, fail as well.
>
> This is probably one of the worst ways of rolling back few or even a single
> package.
Well it's the only way a new admin has idea about. He was told to put
"stable", "testing", or "unstable" in a spot, that didn't work. So he can try
putting a different word in that spot. He can't magically pull
"apt_preferences" from thin air and decide to go editing a file he's never
heard of. And even if it did, it wouldn't really do what he wanted.
I didn't say it was a good idea or that it was going to work.
My whole point is that that approach sucks and we should make
something more effective rather than leave the admin stuck.
--
greg
Reply to: