Applications which use the libraries, must add BuildRequires for the
individual libraries themselves.  The xorg-x11-proto-devel package has
no requirements.

When you start out with zero modular X packages available, and just have
the src.rpm packages, the first package you build is xorg-x11-util-macros,
then install it and then build xorg-x11-proto-devel.  Once xorg-x11-proto-devel
is built, you install it in order to build each of the library packages, as
many of them have "BuildRequires: xorg-x11-proto-devel".

If I were to add "Requires: lib<anything>-devel" to the proto devel package,
we have a dependency loop, and you can no longer build modular X unless you
already have parts of it installed.

The proto packages are in their infancy right now, and include some files
that should be in the library packages, or things that should be split
out much better than they are right now.  The upstream packaging will
improve over time, and the interdependencies of things will get worked
out.

For the time being however, xorg-x11-proto-devel will stay free of any
Requires: lines to avoid a build loop.  Packages that fail to build due
to headers missing such as X11/Xlib.h, should themselves have:

BuildRequires: libX11-devel

After all, it is only a problem if the package actually uses Xlib, and
if it does it should be specifying libX11-devel as a build dep already
anyway.

Adding this dep to the package being built, should solve or work around
the problem.

(In reply to comment #1)
I must say, I am really embarrassed about your answer.

To me it is evidence that current modular X is mal-designed and won't ever work

> Applications which use the libraries, must add BuildRequires for the
> individual libraries themselves.  The xorg-x11-proto-devel package has
> no requirements.
That's the core of the problems: Your assuptions in X11's internal dependencies
do not correspond to the library's dependencies.

> For the time being however, xorg-x11-proto-devel will stay free of any
> Requires: lines to avoid a build loop.
Well, this way you are simply lying to yourself. These deps exist, wether you
are handling them inplicitly or are pushing the burden of tracking them to
users. The latter case is error prone at best because it causes configure script
to fail.

>  Packages that fail to build due
> to headers missing such as X11/Xlib.h, should themselves have:
> 
> BuildRequires: libX11-devel
Simply wrong - devel-packages must automatically pull in all of their deps.
devel-packages not doing so are "plain broken".
 
> After all, it is only a problem if the package actually uses Xlib, and
> if it does it should be specifying libX11-devel as a build dep already
> anyway.
> 
> Adding this dep to the package being built, should solve or work around
> the problem.

I am not going to pollute my rpms with work arounds to modular X's design
defects nor am I willing to waste my time on immature packages not wanting to
obey elementary priniciples of packages.

I mentioned above that modular X is in a state of flux right now, and that
this problem should solve itself for X11R7 upstream when we update to
later packages, or at least that's what I was trying to say, although perhaps
my meaning wasn't well articulated.

In the mean time, the ability to bootstrap modular X builds without any
build dependency loops is mandatory during development, and that is not
possible if the proto package has Requires on packages that are not built
yet in the bootstrap build.

This means that for the time being, the dependencies you mention are
intentionally missing.  This is Fedora development cycle, and users
should expect that there will be breakages, inconsistencies, missing
dependencies and other problems during this transitional period.

As an orthagonal issue, any package which links to libX11 _must_ include a
"BuildRequires: libX11-devel" in order to bring in the X headers and .so
symlink, or it itself is not specifying its build dependencies correctly,
and will fail to build.

Due to this orthagonal issue, when all packages that use the proto headers
properly BuildRequire the correct library packages that they link to, the
problem reported in this bug report does not cause a problem in practice.

In other words, the only packages that should fail to build, due to the
problem described in this bug report, are packages that are not correctly
BuildRequires'ing libX11-devel like they should.  While these are 2
separate issues, the latter solves the former, which makes the proto
package problem a non-issue in practice.

This is not pollution of any rpm packages, this is getting the rpm packages
to properly BuildRequires the library-devel packages that they link to, which
in FC5 will be an absolute 100% mandatory requirement.

Hopefully this clarifies the problem, and what our current (and
changing) plans are going forward.  If this causes a problem for you,
then I'd recommend staying with FC4 or some other stable OS release
and waiting for Fedora Core 5 to be officially released as a final
product, or at least until our development cycle has entered a
stability phase.

This is an upstream X bug affecting the API, so we can't change it solely in
Fedora.  Please report it in X.org's bugzilla at bugs.freedesktop.org.