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