On Tuesday 02 February 2010 17:34:42 Tom Hendrikx wrote: > Peter Humphrey wrote: > > On Tuesday 02 February 2010 12:47:46 David Relson wrote: > >> I've been running unstable versions of portage for many months and > >> currently have 2.1.7.17, which _is_ the newest non-masked version. > > > > Nevertheless, it isn't the latest version. To get that you need an entry > > in package.unmask; then portage will be able to sort out far more complex > > problems than the unmasked version can. Don't worry - many people here > > have been doing this for many months, with no problems attributable to > > portage. > > I'm not sure if upgrading portage to a masked version is a sane solution > for the OP's issue (i.e. resolving a single dependency issue). > Reading the error output from portage (and sometimes the ebuild) to > solve the blocker (as people do who run a stable portage) would suffice, > imho.
The list of benefits from using latest unstable portage is very long. The list of persons running stable systems who have reported problems here with latest unstable portage is very short, tending to zero in fact. Whereas willy-nilly mixing stable and unstable is normally condemned as a bad idea (with good reason), it generally considered OK with portage for the above reason. Portage is self-contained, unmasking it doesn't contaminate the system with legions of other unstable $STUFF > As for the issue with openrc: > > =sys-apps/openrc-0.6.0-r1 depends on =sys-apps/sysvinit-2.87-r3, and > both are in ~arch. Unmask both, emerge them, run etc-update and be fine. Portage's blocker list has historically been confusing and difficult for users to parse. They often don't know what to do - how many posts like that have you answered where the answer is simply "unmerge this, merge that, merge world"? It makes sense to me, probably to you too, and not much sense to a large chunk of gentoo userland. Latest portage fixes all that and makes it a non-issue. -- alan dot mckinnon at gmail dot com
