[adding pkg-fglrx-devel@ to the discussion] On 2011-07-22 21:12, Cyril Brulebois wrote: > Julien Cristau <jcris...@debian.org> (22/07/2011): >> So in principle I dislike the idea of making the mesa packages messier >> to make the closed driver packages' life easier. One thing that's been >> a source of countless bug in the current system is diversions, because >> they're evil, and people keep getting them wrong, and users don't >> understand/expect them, and all kinds of fun ensues. If mesa were to >> not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but >> instead ship an alternative itself, would that be enough to put an end >> to the diversions? Not that I think alternatives are ideal either, but >> if we're going to have to put up with something I'd rather it wasn't >> *both* alternatives and diversions. >> >> Not sure what other X people think. > > I'd rather avoid the mess of diversions *AND* alternatives indeed. If > adding alternative support to mesa is the price to pay, I guess we could > work something out.
OK, that is a different solution that should simplify this even more. What is the correct approach to do alternatives of libraries in Multi-Arch: yes packages? * a separate alternative for each architecture (allows weird mixed configurations) * one alternative (from an extra Multi-Arch: foreign package) that covers all arches as slaves links? * the Ubuntu approach of dropping something in ld.so.conf.d/ - would we need one file/one alternative per arch? (I didn't look in detail at the Ubuntu packages, yet.) A gain handling config files with alternatives ... but this time config files that are not meant for user modification (compared to my approach to handle xorg.conf or xorg.conf.d/nvidia.conf with alternatives) libGL.so.1 is not the only file to be diverted, libglx.so is being replaced by the vendors drivers, too. Or is there some way of "search path magic" that would allow to place the "higher priority alternative" in a different location where it would be picked up before /usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid the diversion here. Something similar to /lib/modules/*/updates/ ... Andreas -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2da06d.1050...@abeckmann.de
