On Mon, 5 Aug 2013 21:10:27 -0400, Walter Dnes wrote: > > 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).
nothing that complicated, I have nothing in package.{un,}mask for eudev.
Something was pulling in virtual/udev-206, which no eudev releases at the
time could satisfy (except possibly the 9999 version but those are masked
by default) so portage needed to uinstall eudev and install udev to fulfil
the dependency.
--
Neil Bothwick
Sisko:"I won't be condescending to you this episode, Dr. Bashir."
signature.asc
Description: PGP signature
