On Saturday 30 August 2008 16:59:02 Stroller wrote: > On 30 Aug 2008, at 13:56, Alan McKinnon wrote: > > The main reason these packages are behind at all is that they are > > usually > > build dependencies, not run dependencies. They will only be updated > > with > > emerge -uD when something that depends on them is rebuilt. > > > > To avoid this, use 'emerge --with-bdeps y' > > This has the side effect of knowing what to do with SLOTs > > So a periodic 'emerge --with-bdeps world' would be worthwhile?
Or you could just leave it as is, these apps are only used when you build something, and if the ebuild requires them, they will be updated. You can set --with-bdeps to always be used in make.conf - I was sure it was a FEATURE as some point in the past but a quick check of the man page reveals nothing. There is an option though to always pass specific options to emerge > > In general I find that emerge is infinitely better at knowing how > > to get what > > I want than I am, so it's always best to let it do what it wants to do > > I'd really debate this premise. Perhaps the problem is not with > `emerge` itself, perhaps with the ebuilds or with simple versioning > incompatibilities, but the number of cock-ups one sees with emerged > packages... well, I think "infinitely" good is stretching it just a > little. > > I'm not saying Portage is poor - other package managers have given me > more headaches per usage. Maybe the problem is with build-time > dependencies of the build-time dependencies, I don't know, but when I > had the libexpat.so.0 error the only thing that worked (having > followed a number of different advices posted here) was to rebuild > EVERY outdated package on my system - a total numbering in the region > of 250. I wouldn't have imagined I had so many packages installed, > never mind those "missed" by my regular updates. Perhaps I should explain in context. Portage and emerge are not perfect, no software is, but I have found with experience that trying to be clever with emerges is usually not worth the effort. I'm not saying you are doing that, I'm more thinking of worrying about whether some obscure build tool really should be at the latest version or not. To my mind, that really is a "who cares?" type question. You should treat my remark for what it really is - a throw-away comment :-) Having said that, portage is very good at dealing with the data it is given. It can work out what to update and when some conflict arises, it does a fine job of telling the human running the show so that said human can make a sane decision. (There is nothing we can do about daft ebuilds though). Compare portage to rpm/yum/urpmi etc ... no, let's rather not go there! apt/dpkg is pretty good too, but can't deal with orphaned deps (the things that --depclean fixes), although aptitude deals with those just fine. I've had rpm break many a system, never seen apt or aptitude do it, and neither has portage. I on the other hand, have done a great many very stupid things over the years. Funny thing is, each time it involved me ignoring the friendly output emerge had just given me. -- alan dot mckinnon at gmail dot com
