On Tue, Apr 16, 2013 at 09:18:00PM -0700, Brian Dolbec wrote:
> If udev is troublesome, then try eudev.  You might even be able to get
> the devs working on it to make it EAPI 5.

I think it needs to be the whole udev ecosystem, since mesa (which
caused #454184) only depends on virtual/udev.  We need the ABI
slotting to pass all the way through.  That means:

  gbm? ( virtual/udev:= )

in mesa and something like

  >=sys-fs/udev-197-r8:=[gudev?,…]
  >=sys-apps/systemd-198-r5:=[gudev?,
  kmod? ( >=sys-fs/eudev-1_beta2-r2:=[modutils,…] )
  !kmod? ( >=sys-fs/eudev-1_beta2-r2:=[gudev?,…] )

in virtual/udev-197-r2.  With sub-slotting in the different
implementation ebuilds.  The trouble is that sys-fs/udev installs both
libsystemd-daemon and libudev, which are versioned separately.  This
means you need virtuals for each ABI [1].  With a new virtual/udev-abi
and virtual/systemd-daemon-abi, you'd need to add virtual/udev-abi as
a dependency for mesa (otherwise, only virtual/udev would be rebuilt
on a libudev version bump :p).  It's not clear to me how to handle the
udev multiplexing in virtual/udev-abi.  I suppose there should be
separate versions for both systemd and eudev, but I'm still working
out the details.

However, none of this is really helping get a catalyst release out the
door.  jmbsvicetto's recent patches are dealing with two unrelated
issues: preserved-libs (3b83a6c, 462348d, and f6ad384) and stale
binpkgs (6c0a577).  I'm only taking issue with 6c0a577 (and its
predecessor e7ea409).  Also, 6c0a577 is a small enough change that I'm
fine with reverting that as well if I can talk folks over to my
binpkg-blacklist approach (after the release).  It would have been
nice if the commit message for 6c0a577 explained how it was different
from dol-sen's earlier proposal [2], as I suggested when the patch was
floated on gentoo-catalyst@.  It would also have been nice if we'd
caught the s/;/:/ typo in 462348d during ML review, but I didn't.  Now
that these patches have landed in `master`, I think we should just
roll with them and cut a new release :p.

We will certainly not have a fix for stale binpkgs in the near future,
other than disabling pkgcache.  I'm fine debating the best catalyst
workaround, but if y'all don't agree with me, I'm not going to blow
up ;).

Cheers,
Trevor

[1]: http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators#Multiple_ABIs_for_X.Org
[2]: http://article.gmane.org/gmane.linux.gentoo.catalyst/2166/

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy