Emerged dev-libs/libffi yesterday and it triggered 24 packages rebuild, to mention not the quickest packages to all re-merge on a @preserved-rebuild The next day on another emerge --sync Updated version of virtual/libffi to go with previous day updated packages, causes a @preserved-rebuild over the same 24 packages over no code was rebuilt idiocy... Might i suggest to actually update the virtual package to be dependent on exact version of dev-libs/libffi or release the virtual package at the same time...to avoid the behavior of double @preserved-rebuild For now i masked the exact version of the new virtual package to avoid merging the packages for no valid reason
Right. virtual/libffi should be slotted. dev-libs/libffi-3.2.1 provides libffi.so.6, and >=dev-libs/libffi-3.3 provides libffi.so.7. So, dev-libs/libffi-3.3_rc0 is subslotted(0/7). And, Packages depends on virtual/libffi must be rebuilt. But virtual/libffi is not slotted yet.
(In reply to Aki Taniguchi from comment #1) > Right. > virtual/libffi should be slotted. > > > dev-libs/libffi-3.2.1 provides libffi.so.6, and >=dev-libs/libffi-3.3 > provides libffi.so.7. > So, dev-libs/libffi-3.3_rc0 is subslotted(0/7). > > And, Packages depends on virtual/libffi must be rebuilt. > But virtual/libffi is not slotted yet. I assume you mean SUB-slotted (they all are in SLOT=0 now, slotting would mean allowing multiple versions at the same time). virtual/libffi was sub-slotted a few days ago as: https://gitweb.gentoo.org/repo/gentoo.git/commit/virtual/libffi?id=dcd94ee79fb552b1e483dda732950a818efa5af2 Sometimes dependent packages don't specify subslot-style depend of virtual/libffi:0=. They should.
