You broke the gentoo-x86 by masking these virtuals without the already converted reverse dependencies. Plus I told you to not bother me about this until there is something broken, or you get this banned by the PMS, or you get this feature dropped from the PM.
I took the liberty to unbreak the tree for you. Don't ever touch my packages again unless they are broken. On 28/03/14 23:48, Rick "Zero_Chaos" Farina wrote: > Recently, without discussion as suggested by the dev manual, new > virtuals were added for libudev and libgudev. > > These virtuals are different than any virtuals use in gentoo in the > past, and due to this, I fell the discussion step is critical. As such, > I have put a temporary QA mask on these virtuals. > > All below information is based on my understanding of what is happening > and why, since these new virtuals were added with no previous > discussion, I can only guess why things were done as they were. > > These new virtuals represent a new idea in how to avoid needless subslot > rebuilds. In this case, it occurs that libudev and libgudev (both part > of the udev package at this time) can (and do) change soname separately. > This means that it is impossible to perform just needed subslot > rebuilds since the package udev can only have one subslot. > > To battle this, virtual/libudev and virtual/libgudev were introduced, > each with the subslot indicating version of their namesake. In this > way, packages which currently dep on virtual/udev can be adjusted to dep > on one or both of the new virtuals and possibly avoid unneeded subslot > rebuilds. > > All in all, this isn't a bad idea on the surface, but the first > arguement shows immediately when this is scaled up. How many other > packages have multiple libs with different sonames? Off hand, I can > think of poplar, but I'm sure there must be more. Is it really > scalable, desirable, or sane, to break each package on the system into > multiple different virtuals like this? > > Discussion, go. > > Thanks, > Zero >
