Re: potato -> woody upgrade not smooth...
I'm subscribed no need to CC me.
On Thu, 5 Jul 2001, Joost Kooij wrote:
> On Thu, Jul 05, 2001 at 11:13:48AM +0200, T.Pospisek's MailLists wrote:
> > Mind you that with testing, dselect would regulary **anyhilate** my
> > system if I used it. Every other day it is trying to remove half of the
> > installed packages due to some funky-update-of-the-day-basic-labrary.
>
> 1. Never happened to me.
[...]
Nice.
> 2. The problem is not in dselect, it is only the messenger. The archive
> just contains a package set with inconsistent dependencies.
[...]
> 3. Never will dselect all by itself nuke a system.
[...]
> Please look up the meaning of the 'Q' and 'R' keys in dselect.
[...]
Admittedly, I did not know R before. I do now, thanks.
But FYI, to explain how this "nuking" happens - it happens after I do an
update in dselect. (I haven't tried to do a R yet in that situation, it
might be that it'd cure the problem). Then sometimes I'm facing the fact
that dselect wants to deinstall half of my system. I'm *guessing* what's
happening is:
1. I fire up dselect
2. I do an update
3. an updated package has a high priority
4. it gets automaticaly selected for update
5. but it conflicts with some other library
6. which *does not* get selected for update (for whatever reason)
7. so that other library, since it is conflicting gets selected for
removal (and *this* is what is IMHO *bad* behaveour!!!)
8. and since it is a base libray, half of my system that depends on it
also gets selected for removal
9. It might be that at this point I might press 'R' and I get back to the
installation situtation before the update - I'll try next time - but if
that doesn't happen I might be facing a completely messed up selection,
which requires a lot of work to bring back to a usable state.
You will notice that point 7. is the one that I strongly dislike. I mean
when I *do* select a package for installation, it's because I want it that
way. And so it's wrong if dselects heuristics take over "for me" and
remove it.
> You cannot blame dselect for the state of dependencies at any time in
> testing or unstable. At least you cannot do so while pretendending to
> make sense.
Consider my point above.
*t
----------------------------------------------------------------------------
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
----------------------------------------------------------------------------
Reply to: