>>>>> On Tue, 01 Apr 2014, Samuli Suominen wrote: >> Mar 28 10:10:11 <ulm> so who will fix the mess resulting from >> virtual/libgudev? >> Mar 28 10:10:44 <ulm> such things should be package masked, instead >> of breaking the tree >> >> Mar 28 10:33:01 <ulm> blueness: eudev-1.5.3-r1 depends on >> virtual/udev depends on virtual/libgudev depends on >=eudev-9999 >> Mar 28 10:33:02 <ulm> ??? >> Mar 28 10:33:12 <ulm> that doesn't make any sense
> At this time, the compability =virtual/udev-208-r2 was not in > Portage yet and nothing depended on those two new virtuals. > So ulm made an observation, that there is an unfinished work in the > tree. And indeed, there was, you know, we handle packages in a > monolithic way in tree, not everything can go in at the same time > like in git. > First, the 2 virtuals were committed to tree, then eudev-1.5.3-r1 > was converted to multilib, then the libgudev was converted for the > 1.5.3-r1, and then the compability virtual was committed to Portage. > So not, at any time, eudev users saw their implementation being > replaced by another by the PM. Sorry, but this is not entirely accurate. I have eudev installed on my system. After syncing, emerge reported blockers and something was trying to pull in udev. In fact, that was how I noticed the issue, in the first place. Latest unstable virtual/udev definitely depended on virtual/libgudev at that point. Ulrich
pgpkafIBCXRUK.pgp
Description: PGP signature
