Manjo;
I am interpreting what you are saying as meaning that _every time_
I run dselect, I have to choose hold (=) to prevent dselect from
upgrading automagically. Now since I KNOW that this is not correct,
ie: I frequently run dselect and I do not 'rechoose' hold to prevent
updating what I asked dselect not to upgrade in a previous session.
Due to a few 'surprises' that resulted in something akin to panic
here in early April (the 'frantic' time of the U.S. 'tax season'), I
have chosen NOT to allow dselect to do any upgrades from frozen without
my explicit choice. This 'decision' seems to be 'sticky' and dselect
has 'honored' my request through numerous seperate invokations.
I will admit that 1: I am NOT certain that I have NOT had priority
'required' packages added since I selected 'hold' and 2: I am not
certain that dselect's operation was the same under 'bo' but I think
that it was. I most definately have 'updated' the package list several
times since making that choice and dselect has yet to 'surprise' me by
installing something that I did not explicitly select.
BTW, if this is a 'voting' issue (and even if it is not), I do feel
that dselect's defaults are appropriate. Both with a 'bo' system and up
until about a month before the freeze of hamm, I was quite happy to have
dselect automagically perform upgrades. I also fully expect that I will
again be happy with that behaviour when hamm moves from 'frozen' to
'stable'.
--
best,
-bill
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
from a 1996 Micro$loth ad campaign:
"The less you know about computers the more you want Micro$oft!"
See! They do get some things right!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
