On Mon, Aug 05, 2013 at 09:18:38PM +0100, Neil Bothwick wrote > On Mon, 05 Aug 2013 10:24:27 -0400, Tanstaafl wrote: > > > > But there's not a lot of point as eudev isn't that different to udev > > > now, AFAICT, and a recent update forced me to switch back to udev > > > because eudev hadn't been updated (on ~amd64). > > > > Can you elaborate on what this update was that forced you to go back to > > regular udev? > > I can't remember what it was now, and it may have been avoidable by > making virtual/udev-206 (or whichever version it was that needed a higher > udev version than eudev could provide). It's moot now as eudev has been > updated and portage is happy again, but it would be a concern if this > happened regularly.
I ran into this. Here is what I think happened... - I specified "sys-fs/eudev-1.2-r1-beta ~amd64" (or something similar) in my /etc/portage/package.keywords file - I ran "emerge --sync". On that particular day, it removed the beta version ebuild, and replaced it with eudev-1.2.ebuild - "emerge --changed-use --deep --update @world" could no longer find an unmasked version of sys-fs/eudev that satisfied virtual/udev. So it fell back to a version of sys-fs/udev - My workaround, *UNTIL SUCH TIME AS EUDEV HITS STABLE AMD64*, is... <sys-fs/eudev-9999 ~amd64 in my /etc/portage/package.keywords file. This specifies to accept the highest ebuild number that is smaller than 9999 (the "bleeding edge" version). -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
