ports/137373: x11/libX11: make dependance on x11/libxcb

[Carlos A. M. dos Santos]

On Wed, Nov 18, 2009 at 11:47 AM, Robert Noland <rnoland at freebsd.org> wrote:
> On Tue, 2009-11-17 at 22:50 -0200, Carlos A. M. dos Santos wrote:
>> On Tue, Nov 17, 2009 at 7:11 PM, John Hein <jhein at symmetricom.com> wrote:
>> > Carlos A. M. dos Santos wrote at 18:22 -0200 on Nov 17, 2009:
>> >  > On Tue, Nov 17, 2009 at 3:07 PM, Robert Noland <rnoland at freebsd.org> wrote:
>> >  > > There is a pretty fair risk of breaking several other ports with this.
>> >  > > Other ports that also expect xcb to be present would need to be modified
>> >  > > to either have xcb disabled or fail if libX11 does not have the needed
>> >  > > functionality.
>> >  >
>> >  > That's exactly why I made it optional, default on, keeping the
>> >  > default behavior.
>> >
>> > I think that what Robert may be saying is that even if it's default is
>> > 'on', people will turn it off, and we might see lots of questions
>> > about why this port or that port isn't working.
>>
>> If such reasoning had any value then you should start removing all the
>> options on all ports right now. Run!
>>
>> > Maybe you can investigate a few ports that may need the xcb-ness
>> > of libX11 and see what it takes to make them work in an xcb-free
>> > flavor of libX11 (or hint at build time that they won't work
>> > if libX11 doesn't have xcb).
>>
>> Ports that explicitly require xcb must do it via *DEPENDS in their
>> respective makefiles, not by means of some under-the-hood dependency
>> via libX11, which is an error.
>
> The issue I believe is that xcb is special... Ports which depend on xcb
> do have options and/or dependencies on xcb, however I don't think that
> is sufficient WRT libX11.  i.e. if you build a port with xcb enabled,
> but libX11 was built without, I think you may be in for trouble.

In this case something is already broken, either libX11, the
application, or both. Building libX11 with xcb means that the Xlib API
is implemented as wrappers around xcb calls instead of the original
Xlib internals and X protocol requests. One can argue that building
libX11 without xcb could result on ABI breakage but this would be a
bug in libX11 that ought to be fixed.

> I might be incorrect here, but I would like to see an EXP run proving it.
> Preferably with some actual run-time testing as well.

I have been running XFce, Firefox, Seamonkey and dozens of X
applications for *months* without any issue. Most of those
applications were written years before it started to depend on xcb. In
fact, most of the X apps and the libraries they require were written
years before xcb started to exist!

>> > The alternative is to commit this change and just see what breaks.
>>
>> Ports that break are already broken and must be fixed. Of course we
>> can pretend they are not broken and keep going, but that would be a
>> shame.
>>
>> > But doing a little investigation ahead of time to give us a heads up
>> > about what to expect would be useful.
>>
>> Simply put, turn off the dependency of libX11 on libxcb. Then mark
>> libxb as FORBIDDEN and rebuild all packages that depend on libX11. Any
>> port whose build breaks is ... well, broken.
>
> If xcb is disabled for everything, then it will be fine.

I'm not proposing this, except as an investigation approach.

> My concern is for cases where libX11 doesn't have xcb enabled and
> later a user installs a port that does have xcb enabled.

You are missing the point. Applications that require libX11 rely on
the *Xlib* API, not on the xcb API. So libX11 just - optionally - uses
the xcb API, without exposing or extending it. I'd like to emphasize
that this is *optional*. That's why the configuration script provides
the "--without-xcb" option at all!

-- 
My preferred quotation of Robert Louis Stevenson is "You cannot
make an omelette without breaking eggs". Not because I like the
omelettes, but because I like the sound of eggs being broken.