On 01/04/14 21:08, Ulrich Mueller wrote: >>>>>> 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. > >
Are you sure? Then it was an accident, caused by too early commit of the virtual from mgorny It couldn't have been more, than few minutes, but mirrors managed to sync in between? I surely apologize I didn't communicate it clearly enough to him, that was not something that was supposed to be happening at all But hey, we are all humans, accidents happen, and it was only ~arch, for one mirror sync :/ - Samuli
