<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Thu, 2009-12-03 at 08:04 -0800, Jamey Sharp wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Thu, Dec 3, 2009 at 5:40 AM, Dan Nicholson <<A HREF="mailto:dbn.lists@gmail.com">dbn.lists@gmail.com</A>> wrote: > On Thu, Dec 3, 2009 at 1:05 AM, Julien Cristau <<A HREF="mailto:jcristau@debian.org">jcristau@debian.org</A>> wrote: >> On Thu, Dec  3, 2009 at 13:46:32 +0600, Mikhail Gusarov wrote: >>> libpthread-stubs0-dev: /usr/share/pkgconfig/pthread-stubs.pc >>> >> The last one sounds like a bug.  pthread-stubs.pc is arch-dependent. > > On fedora (at least), they move it to $datadir since on linux since > it's no arch dependent (it's just a .pc file). This is drifting off-topic, but... pthread-stubs.pc has different contents depending on what libc your system uses--that's the whole point. Therefore it is platform-dependent and I'd expect it to be in /usr/lib. Looks to me like we still have the upstream git repo configured that way, so I guess the distros are deliberately breaking this? If a distro wants to support only glibc, I suppose they can build their own, nearly empty, pthread-stubs replacement package, containing nothing but a /usr/share/pkgconfig/pthread-stubs.pc. That would make it clear that they don't support any other platforms, while patching the real pthread-stubs makes it seem otherwise. Debian's packaging is clearly just broken though, since Debian does support multiple libc implementations. Jamey __ </PRE> </BLOCKQUOTE> Thanks, that's useful. No one disputes the FSH standard, nor the fact that distros and OS are expecting xorg to follow it. The first 2 modules to put there heads on the chopping block were lixtrans and macros. The former one not really by choice and the latter just woke up realizing there was a standard. There was mention numerous times about an unacceptable large amount of work for developers going about there daily work if some pc files were moved to datadir. This assumption lead to the large technical debate on how things can still work in libdir. I have not seen any details about that work, other than the the PKG env variables. It would help reviewers to assess the trade-offs. Given by the looks of it that we have no choice but to accept the libxtrans situation, the work needs to be done anyway. Whether we do 1 module or 36, the cost is the same. It may be more easily accepted by those who are impacted by the change, if we tell them it is for the greater good of the project. Consideration should be given to the long term. For how many months/years can we avoid datadir? We also need to review backward compatibility issues. And I'd like to shift the focus to protocol extension headers, xbitmaps, fonts. These are much better candidates than the first 2. As we have seen with the pthread file, a case by case review will be required. Regards, Gaetan <BLOCKQUOTE TYPE=CITE> <PRE> _____________________________________________ xorg-devel mailing list <A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A> <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A> </PRE> </BLOCKQUOTE> </BODY> </HTML>