Opened 12 years ago

Closed 12 years ago

#19503 closed defect (fixed)

xorg-libX11, xrender: some build dependencies should be lib dependencies

Reported by: ryandesign (Ryan Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 1.7.1
Keywords: Cc:
Port: xorg-libX11, xrender

Description

php5-gtk failed to install, saying it couldn't find gtk2, though it was installed. I found that pkg-config was unable to tell me about gtk2 because parts it required had been uninstalled, by me, when I used port_cutleaves to remove ports it said were not depended on by anything.

$ pkg-config --modversion gtk+-2.0
Package xproto was not found in the pkg-config search path.
Perhaps you should add the directory containing `xproto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xproto', required by 'Xrender', not found
$ port install xorg-xproto
$ pkg-config --modversion gtk+-2.0
Package renderproto was not found in the pkg-config search path.
Perhaps you should add the directory containing `renderproto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'renderproto', required by 'Xrender', not found
$ port install xorg-renderproto
$ pkg-config --modversion gtk+-2.0
Package kbproto was not found in the pkg-config search path.
Perhaps you should add the directory containing `kbproto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'kbproto', required by 'X11', not found
$ port install xorg-kbproto
$ pkg-config --modversion gtk+-2.0
2.16.1
$

It seems to me that xorg-xproto and xorg-renderproto should be declared as library dependencies, not build dependencies, of xrender, and that xorg-kbproto should be declared as a library dependency, not a build dependency, of xorg-libX11, and that perhaps the same change needs to be made for any other *proto ports that are currently being declared as build dependencies.

Change History (7)

comment:1 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Well technically, the protos are not required to run and are not linked against. They are headers.

Adding them to depends_lib is not the right solution. It would be a hack, because you should be able to remove them, and they should be installed again when you try to build something that needs them. depends_lib does not satisfy that usage. depends_build does, but not in an optimal way.

As it is now, php-gtk is expected to depends_build on xorg-xproto, and everything that gtk2 had in depends_build... but then THAT would over-depend on things... for example, some ports depends_build on autoconf, but only that port needs autoconf...

comment:2 Changed 12 years ago by ryandesign (Ryan Schmidt)

My issues with the situation are:

  1. xorg-libX11, for example, installs x11.pc, therefore any port that depends on xorg-libX11 should be able to fully use x11.pc, but currently this is not the case because x11.pc references ports which could be uninstalled because they were only listed as build dependencies
  2. *-proto ports are strange. It is not normal in MacPorts for headers to be in a separate port from libraries. MacPorts maintainers expect a port to provide both libraries and headers. Since they're distributed as separate distfiles it makes sense to implement them as separate ports, but by using depends_lib to ensure the headers cannot be uninstalled, you could continue to give port authors the experience they expect when depending on e.g. xorg-libX11.

comment:3 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

The -proto headers are not tied to any particular lib. There is no lib associated with xproto, for example... They are not what rpm distros use '-dev' for. They are completely separate packages that just contain data structures describing the X11 communication protocol and its various extensions. The X11 libs depend on them to build, and the X11 server depends on them to build.

libX* provide all the headers to access the API of the particular library.

I understand the argument that we should continue to give port authors the experience they expect, but what about the argument to give users the experience they expect (like being able to remove ports only needed at build time).

It is a small number of bytes and a few changes in the tree... and I'd be glad to do it, but I feel like we're swapping one incorrect behavior for another incorrect behavior. Granted the incorrect behavior you are suggesting is certainly favorable to the existing behavior... but it's still wrong, and I wish we had a correct solution.

comment:4 Changed 12 years ago by ryandesign (Ryan Schmidt)

I cannot run pkg-config --modversion gtk+-2.0 unless xorg-xproto, xorg-renderproto and xorg-kbproto are installed. This means I cannot build any port that depends on gtk2 unless those other ports are installed. gtk2's gtk+-2.0.pc doesn't itself mention these requirements. But some other pkgconfig files do. So it feels to me like the responsibility of those ports to declare dependencies on the proto ports their pc files say they require. For example:

$ grep ' xproto' /mp/lib/pkgconfig/*.pc 
/mp/lib/pkgconfig/ice.pc:Requires: xproto
/mp/lib/pkgconfig/libfs.pc:Requires: xproto fontsproto
/mp/lib/pkgconfig/sm.pc:Requires: ice xproto
/mp/lib/pkgconfig/x11.pc:Requires: xproto kbproto
/mp/lib/pkgconfig/xau.pc:Requires: xproto
/mp/lib/pkgconfig/xaw6.pc:Requires: xproto xt xmu
/mp/lib/pkgconfig/xaw7.pc:Requires: xproto xt xmu
/mp/lib/pkgconfig/xcomposite.pc:Requires: xproto compositeproto >= 0.4 xfixes
/mp/lib/pkgconfig/xcursor.pc:Requires: xproto
/mp/lib/pkgconfig/xdamage.pc:Requires: xproto damageproto >= 1.1 xfixes
/mp/lib/pkgconfig/xdmcp.pc:Requires: xproto
/mp/lib/pkgconfig/xevie.pc:Requires: xproto
/mp/lib/pkgconfig/xfixes.pc:Requires: xproto fixesproto >= 4.0
/mp/lib/pkgconfig/xfont.pc:Requires: xproto fontsproto
/mp/lib/pkgconfig/xft.pc:Requires: xproto, xrender, fontconfig, freetype2
/mp/lib/pkgconfig/xmu.pc:Requires: xproto x11 xt
/mp/lib/pkgconfig/xmuu.pc:Requires: xproto x11
/mp/lib/pkgconfig/xrandr.pc:Requires: xproto randrproto >= 1.3
/mp/lib/pkgconfig/xrender.pc:Requires: xproto renderproto >= 0.9 x11
/mp/lib/pkgconfig/xres.pc:Requires: xproto
/mp/lib/pkgconfig/xt.pc:Requires: xproto x11 sm
/mp/lib/pkgconfig/xv.pc:Requires: xproto videoproto
/mp/lib/pkgconfig/xvmc.pc:Requires: xproto videoproto xv

Beginning with the first, ice.pc:

$ port provides /mp/lib/pkgconfig/ice.pc
/mp/lib/pkgconfig/ice.pc is provided by: xorg-libice
$ port deps xorg-libice
xorg-libice has build dependencies on:
        pkgconfig
        xorg-xproto
        xorg-xtrans

So the ice.pc file that xorg-libice installs says it requires "xproto", provided by the xorg-xproto port. Ports that depend on xorg-libice will probably use pkg-config to find out how to link with libice. This pkg-config call will fail unless xorg-xproto is installed. Therefore, xorg-libice must declare a lib dependency on xorg-xproto, to indicate that it may not be uninstalled after a build.

It is not reasonable that every port that wants to use xorg-libice should be required to know what other proto ports xorg-libice requires and to declare dependencies on them. What if a new version of xorg-libice requires another proto port? It's not reasonable to have to update all ports that use xorg-libice to also list that dependency. This is what the dependency engine is for -- handling this for us by declaring dependencies at the source.

"depends_build foo" means foo is required to build this software. "depends_run foo" means foo is required to run this software. I feel that running pkg-config against a .pc file installed by this port is included in the definition of running this software. "depends_lib foo" is equivalent to "depends_build foo\ndepends_run foo".

comment:5 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Right, I understand your concern 100%, and I admit it is a problem. I'm just pointing out that the solution you offer is not free of problems either. I agree that it is *less* problematic than the current state, but it is not the end goal. We need to look for a better solution as an end goal and just deal with it like it is (after moving these depends into lib) for now.

comment:6 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

r50534 has the protos moved to depends_lib.

comment:7 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.