#17956 closed update (fixed)
Some x11-apps install app-defaults to $x11prefix with +system_x11
Reported by: | mtalexander (Mike Alexander) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | ports | Version: | 1.8.0 |
Keywords: | Cc: | blb@…, jeremyhu (Jeremy Huddleston Sequoia), andrea.damore@… | |
Port: | bitmap, editres, oclock, viewres, xcalc, xclipboard, xclock, xconsole, xditview, xdm, xedit, xfd, xfontsel, xgc, xload, xlogo, xmag, xman, xmessage, xmh, xmore, xsm, mesa, xorg-libAppleWM, xrender, fslsfonts, appres, listres, luit, xeyes |
Description
I just upgraded my machine and in the process rebuilt all my ports from scratch. I decided to use the new system_x11 variant where available and in the process discovered a few problems.
There were a few ports (mesa, xorg-libAppleWM, and xrender) that wouldn't build with that variant unless they had first been built without it and not cleaned since then. The first patch attached fixes these.
There were a number of other ports (22 in all) that didn't have a system_x11 variant, but needed one since they install something in app-defaults. If the X11 libraries are built with system_x11, they try to install these files in /usr/X11/lib/X11/app-defaults which of course doesn't work. The second patch fixes these ports.
While I was at it I added a system_x11 variant to 5 other ports for which it seemed to make sense. This patch is the third patch below.
Attachments (3)
Change History (15)
Changed 16 years ago by mtalexander (Mike Alexander)
Attachment: | system_x11.fix.patch added |
---|
Changed 16 years ago by mtalexander (Mike Alexander)
Attachment: | system_x11.extra.patch added |
---|
Add a few more system_x11 variants
comment:2 Changed 16 years ago by mtalexander (Mike Alexander)
A number of the ports in the appdefault patch don't work right without the system_x11 variant when built on a case-insensitive file system. This is a upstream bug and results from the fact that the app-defaults file name is a mixed case version of the executable file name. This has been fixed upstream for some programs and will likely be fixed for others eventually. It would be possible to add a post-destroot rule to get around the bug in the meantime since the makefile always puts the executable in the conflicting file and leaves the other in a *.ad file.
Changed 16 years ago by mtalexander (Mike Alexander)
Attachment: | system_x11.appdefault.patch added |
---|
New version of patch to add system_x11 variant to ports that create app-default files. Previous copy had extra stuff in it.
comment:3 Changed 16 years ago by mtalexander (Mike Alexander)
I replaced the app-defaults patch (so it's now the third attachment) since the previous copy also had all or most of the fixes patch in it.
comment:4 Changed 16 years ago by jmroot (Joshua Root)
Cc: | jeremyhu@… andrea.damore@… added; mta@… removed |
---|---|
Owner: | changed from macports-tickets@… to blb@… |
Type: | defect → enhancement |
comment:5 follow-up: 6 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Cc: | blb@… added |
---|---|
Owner: | changed from blb@… to jeremyhu@… |
Priority: | Normal → Low |
Summary: | Fixes to make system_x11 variant work better → Some x11-apps install app-defaults to $x11prefix with +system_x11 |
I thought the use_configure no overrode the use_autoreconf yes. Interesting....
As for xeyes, luit, etc... they're not going to have +system_x11 variants.
What is xeyes trying to put in /usr/X11 ? xeyes doesn't have any app-defaults ... ditto for many others. The only app-defaults that you should see are:
Bitmap Bitmap-color Bitmap-nocase Chooser Clock-color Editres Editres-color KOI8RXTerm UXTerm Viewres XCalc XCalc-color XClipboard XClock XClock-color XConsole XFontSel XLoad XLogo XLogo-color XMore XSm XTerm XTerm-color Xditview Xditview-chrtr Xedit Xedit-color Xfd Xgc Xmag Xman Xmessage Xmessage-color Xmh
The app-defaults dir is determined by this in configure.ac: appdefaultdir=$(pkg-config --variable=appdefaultdir xt) AC_SUBST(appdefaultdir)
We'll need to update those to allow an envvar or configure option to override it. Of course if you have +system_x11, you probably don't need or want these x11-apps since you have them in $x11prefix already... and if you wanted them in MacPorts, you probably don't have +system_x11 set... because of this unlikelyhood, I'm going to drop this priority. The other issues have been fixed in svn.
Thanks.
comment:6 follow-up: 7 Changed 16 years ago by mtalexander (Mike Alexander)
As I said in my original note, the things changed in system_x11.extra.patch (including xeyes) are just things I added a system_x11 variant to for no good reason. If you think that's a mistake that's ok with me. The ports in system_x11.appdefault.patch did add stuff to app-defaults.
If you don't want to add a system_x11 variant to these ports, then you should remove them as dependents for other ports. Right now it's impossible to install things like gnome-desktop, nautilus, evince, and perhaps others since they all depend on xorg which depends on xorg-apps which depends on all of these programs. As it is, you can't install something like gnome-desktop if you've installed the X11 libraries with the system_x11 variant.
comment:7 follow-up: 8 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to mta@…:
If you don't want to add a system_x11 variant to these ports, then you should remove them as dependents for other ports.
Which ports (other than xorg and xorg-apps) depend on these application? Nothing in there should.
Right now it's impossible to install things like gnome-desktop, nautilus, evince, and perhaps others since they all depend on xorg
They shouldn't depend on xorg. They may be depending on lib:libX11:xorg, but that should be satisfied without bringing in the xorg package.
which depends on xorg-apps which depends on all of these programs.
Yes, because xorg-apps is a meta-package for all the x.org applications.
As it is, you can't install something like gnome-desktop if you've installed the X11 libraries with the system_x11 variant.
The solution is to figure out why gnome-desktop is pulling in xorg. My MBP just borked, so I'm short a dev box for a few days... =/ sorry I can't dive into this more right now
comment:8 Changed 16 years ago by mtalexander (Mike Alexander)
Replying to jeremyhu@…:
Which ports (other than xorg and xorg-apps) depend on these application? Nothing in there should.
The only thing that depends on xlogo (I didn't check all 22 apps) is xorg-apps. The only thing that depends on it is xorg, and the only thing that depends on xorg is gnucash-desktop. I.e., the dependency chain is gnucash-desktop->xorg->xorg-apps->xlogo.
As it is, you can't install something like gnome-desktop if you've installed the X11 libraries with the system_x11 variant.
The solution is to figure out why gnome-desktop is pulling in xorg. My MBP just borked, so I'm short a dev box for a few days... =/ sorry I can't dive into this more right now
Yes, I agree, gnome-desktop shouldn't pull in xorg. On the other hand these apps won't build at all if you built the X11 libraries with the system_x11 variant. This seems wrong. At the very least it seems that there should be something in the port file to warn people not to install them in this case. You could test for the location of the app-defaults directory and abort the install if it's outside the Macports prefix area. Letting the install proceed simply to fail later when it can't replace the non-Macports app-defaults file is going to be confusing.
comment:9 Changed 16 years ago by blb@…
Note that gnome-desktop uses lib:libX11:xorg
for its dependency on X11, which means if you have X11 installed (Apple's X11User and X11SDK and/or Xquartz), then that dependency is satisfied and the xorg port shouldn't be installed.
comment:10 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:11 Changed 16 years ago by jmroot (Joshua Root)
Type: | enhancement → update |
---|
Fix some ports that won't work with the system_x11 variant when cleaned