On 2/10/08, Martin Mewes <email@example.com> wrote:
> Javier Vasquez schrieb:
> > Then the rest is kind of recipy for upgrading:
> > -- aptitude clean
> > -- aptitude update
> > -- aptitude safe-upgrade
> > -- aptitude full-upgrade
> If _I_ do this nearly the complete system would be erased when I
> _would_ answer "Y" in the end. Just my 2 cents ...
> bis dahin
> Martin Mewes
Well, aptitude is pretty good at managing upgrades. But I agree, most
of the software will be replaced by saying yes to the 1st
"safe-upgrade", however my experience is that if one is used to deal
with dependency problems and the like, that should not be a reason to
be scared. When "safe-upgrade" finds dependencies problems it won't
it'll leave the upgrade to "full-upgrade".
I suggest as well, having several iterations of "safe-upgrade" if
you're using an old aptitude, before the "full-upgrade" until there's
nothing else the "safe-upgrade" can deal with... I haven't found the
iterations necessary anymore, but I use the latest version under
It might be useful to also remove (purge if necessary) big packages
which dependencies are hard to deal with, and of course, it's better
if everything is done under console (no X)...
Beyond that, and some research, only experience will tell...
My last suggestion (which I did NOT follow due to lack of time and
disk space), make a separate partition, and try a n-boot (I can't say
for sure dual for sure) system. Start the trial one with stable, then
move to testing, and finally move to unstable with light environment
(include X though, since along the way there are pertinent changes to
be considered). At the end if everything goes OK, then whether remove
the original partition after moving the date to the unstable one, or
upgrade the original one with a bit more of experience,
. I said
partition, but it might actually be a logical volume if you'd like...
Again, before such a move, I'd look at what seems to be wrong in the
current version, to see if it's due to just a particular package
version. If so, I'd rather use backPorts, or install from upstream
the source and compile it myself, well that if I'm confortable with
the current version I work under, and the movement souds too risky.
There are always different alternatives to solve a single problem,
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org