I recently added dev-libs/libgudev to the tree. This package replaces the libgudev library provided by sys-fs/eudev[gudev], sys-fs/udev[gudev], and sys-apps/systemd[gudev]. When I added dev-libs/libgudev, I also revbumped virtual/libgudev to add the new provider. However, it seems quite difficult to get portage to automatically switch to using dev-libs/libgudev. A world update produces blocker messages and slot conflicts. It only works if you explicitly specify the new package. > emerge --oneshot =sys-apps/systemd-9999 dev-libs/libgudev I think the only workable solution here is to eliminate the || dep in virtual/libgudev and make dev-libs/libgudev the only provider. This probably makes the most sense long-term anyway. Here's what needs to happen: 1. Add revbumps of eudev, udev, and systemd with gudev forcably disabled. At the same time, add virtual/libgudev-230 with RDEPEND="dev-libs/libgudev". 2. Stabilize dev-libs/libgudev. 3. Stabilize the new versions of eudev, udev, systemd and virtual/libgudev-230. Does this sound workable to the eudev and udev teams? If so, please let me know which versions I should revbump for step 1. My preference would be to revbump current stable + current ~arch.
I did some testing with other options, and nothing seems better than this one. I also confirmed that we can't add virtual/libgudev-230 without the ebuilds that drop gudev from IUSE being available in the tree.
(In reply to Mike Gilbert from comment #0) > > Does this sound workable to the eudev and udev teams? > > If so, please let me know which versions I should revbump for step 1. My > preference would be to revbump current stable + current ~arch. Sounds workable for eudev. Let's revbump eudev-3.1.2 for the ~arch version which I added to the tree today. Future versions of eudev will have no libgudev.
(In reply to Ian Stakenvicius from comment #1) > I also confirmed that we can't add virtual/libgudev-230 without the ebuilds > that drop gudev from IUSE being available in the tree. Slight revision to that: I plan on using package.mask to hide the new versions, and then drop the mask once we are ready.
*** Bug 552718 has been marked as a duplicate of this bug. ***
+ 10 Jul 2015; Mike Gilbert <floppym@gentoo.org> package.mask: + Unmask systemd/udev 222 mask and virtual/libgudev-230. +*eudev-3.1.2-r10 (10 Jul 2015) + + 10 Jul 2015; Mike Gilbert <floppym@gentoo.org> +eudev-3.1.2-r10.ebuild: + Revbump for libgudev, bug 552036.
So how do we resolve the blockers? [blocks B ] dev-libs/libgudev ("dev-libs/libgudev" is blocking sys-fs/udev-220-r3) [blocks B ] sys-fs/udev[gudev(-)] ("sys-fs/udev[gudev(-)]" is blocking dev-libs/libgudev-230)
(In reply to Nikos Chantziaras from comment #6) > So how do we resolve the blockers? > > [blocks B ] dev-libs/libgudev ("dev-libs/libgudev" is blocking > sys-fs/udev-220-r3) > [blocks B ] sys-fs/udev[gudev(-)] ("sys-fs/udev[gudev(-)]" is blocking > dev-libs/libgudev-230) Remove the gudev USE flag for both sys-fs/udev and virtual/udev
(In reply to Tobias Klausmann from comment #7) > (In reply to Nikos Chantziaras from comment #6) > > So how do we resolve the blockers? > > > > [blocks B ] dev-libs/libgudev ("dev-libs/libgudev" is blocking > > sys-fs/udev-220-r3) > > [blocks B ] sys-fs/udev[gudev(-)] ("sys-fs/udev[gudev(-)]" is blocking > > dev-libs/libgudev-230) > > Remove the gudev USE flag for both sys-fs/udev and virtual/udev Since the packages are unmasked now, shouldn't that mean that this happens automatically? I don't have the USE flag explicitly set.
The gudev use flag was removed from the following packages: sys-apps/systemd-222 sys-fs/udev-222 sys-fs/eudev-3.1.2-r10 Patrick has since re-masked udev-222, leading to the blocker situation we have now. Once that has been resolved, the blockers should auto-resolve.
Looks like this was sorted out long ago.
