Did you ever look into backports? There are newer kernal versions hosted there, as well as many newer packages.
http://backports-master.debian.org/ – Chris On Thu, Feb 14, 2013 at 10:47 PM, Hendrik Boom <[email protected]>wrote: > On Fri, Feb 15, 2013 at 03:39:06AM +0100, Michael wrote: > > Hendrik, > > > > I see. Now that's another statement ! > > > > Maybe you should move to grub then, within Squeeze, and also try to > upgrade only the 'problem' packages first ? if that's all fine, to the rest > ? > > In one of my tries, one of the problem packages I was advised to remove > was aptitude itself! > > I didn't think that was a good idea. > > Normally, when tracking testing, there are a few packages that can't be > updated because of dependency problems. But usually, the dependencies > drift in from sid in a few days. I had hundreds of such packages. It > told me that the upgrade path hadn't really been debigged yet, and that > my server might not be the best place to tinker with it. > > That sais, I really do want the LVM mods that implement a proper > write barrier. Apparently that came in with the first kernel version > after stable. It is necessary for file systems to reliably remain > consistent during power failures and the like. > > I suppose I'll try again sometime when other things arenn't too > pressing. > > > > > I always do such things within aptitude, maybe in several cycles, since > it gives me more choices than just running --upgrade. Including the choice > to simply deinstall some apps temporarily (keep a list) and reinstall when > everything else is fine. > > I normally use aptitude safe-upgrade on my testing systems, once every > week or so. > > > > > I admit this is not what you would expect from a package management that > provides --upgrade, but at least, there is a chance. > > I do expect that these problems will be mostly sorted out by the time > wheezy gets close to being stable. > > > > > There should be good reason why you would upgrade an Ubuntu (for > example) only in minor consecutive version steps. In Debian, this resembles > tracking 'testing' all the time. The only alternative that i know, is > temporarily deinstall blocking / broken things, and manually decide and > process major changes (like moving to grub or upstart). > > -- hendrik > > > -- > To UNSUBSCRIBE, email to [email protected] > with a subject of "unsubscribe". Trouble? Contact > [email protected] > Archive: http://lists.debian.org/[email protected] > >
