[PATCH] util-macros: Addition of a meta data file xorg-macros.pc.in used by XORG_INSTALL

[Gaetan Nadon]

On Thu, 2009-12-03 at 08:04 -0800, Jamey Sharp wrote:

> On Thu, Dec 3, 2009 at 5:40 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> > On Thu, Dec 3, 2009 at 1:05 AM, Julien Cristau <jcristau at debian.org> 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
> __

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





> _____________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20091203/f94cd6df/attachment.htm