On Thursday 20 May 2010 11:36:46 Willie Wong wrote: > On Thu, May 20, 2010 at 10:20:54AM +0200, Alan McKinnon wrote: > > > Ah... I see, I was trying to figure out what they meant by deprecated > > > and how they determined it. It seems that the only thing common to > > > those packages is that their ebuilds are no-longer in the tree. > > > > Each one of those packages you list has more up to date versions > > available in the tree. > > Precisely. But the exact version that is installed is no longer in > the tree. Seeing that I don't recall the portage system introducing a > deprecated flag (short of the removal notice and package.mask), I was > curious how eclean determined that those packages are deprecated. > > And also seeing that for many of the ones I listed, neither > emerge --update --deep world > nor > emerge --update --deep --with-bdeps=y world > suggest their updates, in my case they are probably just cruft that > ought to go away once the system is brought up to date and I can run > depclean.
I remember something about a "deprecated" feature somewhere. Can't remember where now, and grep doesn't reveal it... > > But am I wrong in my impression that with bdeps, the common thing to > do is to update them only when absolutely necessary? So in this case > the deprecation warning might introduce unnecessary cycles spent on > building those packages (among those who don't want to track down the > origins of those packages and just want the block of text to go away). Yes, that's pretty much true. bdeps are are deps that are only used to build stuff, not run them. So portage will only update them when it needs to build something using them. You can use bdeps=y in make.conf but most folks just leave it at the sensible default. -- alan dot mckinnon at gmail dot com
