Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 07:32:33AM +0100, Mike Hommey wrote: On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow [EMAIL PROTECTED] wrote: Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. Shouldn't the fonts ans other such files go in /usr/*share*/X11, instead ? Thanks to Eugene Konev's work, we've just put the fonts in to /usr/share where they belong. That should resolve the last of the issues raised in this thread. Thanks for all the feedback everyone! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote: David Nusinow wrote: Currently, it fakes FHS compliancy by creating various symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate directories in /usr/X11R6. For 7.0, we need to make those symlinks become actual directories. I thought that the idea instead was to move everything directly into /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories? /usr/include/X11 is obvious enough (#include X11/*). There is some software that contains hardcoded paths to executables in /usr/bin/X11; for example, sshd hardcodes the path to /usr/bin/X11/xauth. sshd stats whatever it thinks is the location of xauth to find out whether it can do X11 forwarding, so it's not entirely trivial to unhardcode this path. Note that the FHS has this to say about /usr/bin/X11 and friends: In general, software must not be installed or managed via the above symbolic links. They are intended for utilization by users only. I always interpreted this as meaning that packages couldn't install files there via the symlink, but that it was OK to refer to files via the symlink. Current Ubuntu makes /usr/bin/X11 a symlink to . (i.e. /usr/bin) which means that this all continues to work fine after xauth and friends move to /usr/bin. David's paragraph above implies something different. David? Also, moving stuff to /usr/bin/X11 and making it a real directory will break things for anyone having /usr/X11R6/bin in their path instead. One example of such a path is in pbuilder. That much would continue to work fine if binaries were moved to /usr/bin rather than /usr/X11R6/bin, and with a /usr/bin/X11 - . symlink paths hardcoded as specified in policy (11.8.7, Installation directory issues) would continue to work as well. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Russ Allbery wrote: (Or is imake going away completely?) Yep. Imake is still being shipped for the benefit of third-party packages, but it is not used by anything in Xorg 7.0 IIRC. Doing a quick check, I think very few if any other packages in Debian use imake. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Nathanael Nerode [EMAIL PROTECTED] writes: Yep. Imake is still being shipped for the benefit of third-party packages, but it is not used by anything in Xorg 7.0 IIRC. Doing a quick check, I think very few if any other packages in Debian use imake. I think you should perhaps check a little more thoroughly before jumping to conclusions. Here's a list of packages that install binaries into /usr/X11R6/bin and don't have lintian overrides for it. In spot checks, about a quarter of these packages use imake. And that's just the packages with binaries; there are a number of other packages that don't install binaries but that still use imake (I happen to maintain one of them, a font package). bugsx buici-clock ctwm emelfm fte-xwindow fvwm95 gerstensaft gipsc gradio hamsoft hanterm-classic hanterm-xf ibp isdnutils-xtools ivtools-bin ivtools-dev kdrill kinput2-canna kinput2-canna-wnn kinput2-wnn kterm lbxproxy lm-batmon lsb-core lwm mctools-lite mgp olvwm olwm oneko pgaccess pixmap plotmtv ppxp ppxp-x11 proxymngr qcam seyon skkinput tkdesk twlog twm videogen vtwm wmavgload wmcpu wmdate wmnet wmscope xautolock xbase-clients xbatt xbattbar xcal xcalendar-i18n xcb xclip xclips xdkcal xdm xdmx xdu xengine xfaces xfishtank xfm xfs xfwp xgdipc xinput xipmsg xlbiff xli xlockmore xlockmore-gl xmeter xmix xmon xnest xpostit xrn xserver-common xserver-xorg xsysinfo xtel xtoolwait xtrlock xutils xvfb xview-clients xviewg xviewg-dev xvkbd xxkb xzoom yank -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Matthias Klose wrote: Joey Hess writes: Debian GCC Maintainers debian-gcc@lists.debian.org gcc-snapshot no. must be a false positive. Yes, didn't anchor the pattern and it matched stuff in /usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/ -- see shy jo signature.asc Description: Digital signature
Re: Pre-Depends for Xorg 7.0
Joey Hess writes: Debian GCC Maintainers debian-gcc@lists.debian.org gcc-snapshot no. must be a false positive. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Russ Allbery wrote: Here's a list of packages that install binaries into /usr/X11R6/bin and don't have lintian overrides for it. In spot checks, about a quarter of these packages use imake. And that's just the packages with binaries; there are a number of other packages that don't install binaries but that still use imake (I happen to maintain one of them, a font package). Well, let's see what the scope of imake in the /usr/X11R6/bin issue specifically is. (The fonts issue seems to be more of an issue.) Actually, it seems that there are an even larger percentage than you thought. So I was very wrong. Sigh. Imake is considered dead-except-for-routine-maintenance upstream as far as I can tell, so best practice would be to migrate away from it. Unless someone plans to adopt it. Doing some sorting of this list, I find that these originate from Xorg, so will no longer use Imake: lbxproxy proxymngr twm xbase-clients xdm xdmx xfs xfwp xnest xserver-common xserver-xorg xutils xvfb These don't build-depend on xutils (so either they don't use imake or they have a serious missing Build-Depends bug): buici-clock emelfm fte-xwindow fvwm95 (fvwm95 is desperately obsolete software which should really be removed anyway.) gerstensaft gipsc gradio hamsoft ibp lm-batmon lsb-core pgaccess Orphaned, QA. ppxp ppxp-x11 qcam tkdesk twlog videogen wmcpu wmscope xclips xdkcal xgdipc xlockmore xlockmore-gl xvkbd yank This leaves a list of possible Imake users. I went through these by hand, and most of them did use Imake. Probable non-imake users: hanterm-classic hanterm-xf (These two appear to have both Imake and configure/Make build systems, but the latter is used.) Definite imake users: bugsx ctwm -- should be straightforward to convert, by copying configury from twm, of which it is a fork isdnutils-xtools ivtools-bin ivtools-dev ivtools: severely out of date and busted packages, with a particularly insane configuration and build system. kdrill kinput2-canna (source kinput2) kinput2-canna-wnn (source kinput2) kinput2-wnn (source kinput2) kterm -- should be trivial to convert, by copying configury from xterm, of which it is a fork lwm olvwm (source xview) olwm (source xview) mctools-lite mgp oneko -- very simple Imakefile, should be an easy conversion pixmap plotmtv seyon skkinput vtwm wmavgload wmdate wmnet xautolock xbatt xbattbar xcal xcalendar-i18n xcb xclip xdu xengine xfaces -- has an alternate noimake Makefile xfishtank xfm xinput xipmsg xlbiff xli xmeter xmix xmon xpostit xrn xsysinfo -- orphaned, QA. xtel xtoolwait xtrlock -- has a 'noimake' Makefile xview-clients (source xview) xviewg (source xview) xviewg-dev (source xview) xxkb xzoom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Nathanael Nerode [EMAIL PROTECTED] writes: Imake is considered dead-except-for-routine-maintenance upstream as far as I can tell, so best practice would be to migrate away from it. Unless someone plans to adopt it. imake the program, and xmkmf, are *probably* not that horribly difficult to maintain, apart from obnoxious C preprocessor issues. However, imake is very, *very* heavily dependent on the exact details of the X configuration. If upstream is abandoning imake, my worry on trying to maintain it would be that the X configuration may drift away from what imake can deal with. I've done that sort of X configuration hacking to make imake install things in appropriate locations and use the right compilers in the past. It's not fun work; it's painful, tedious, and exceedingly boring, and I wouldn't recommend it if you can avoid it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
On Sun, Jan 22, 2006 at 09:22:24PM -0500, David Nusinow wrote: Because the remainder of the Xorg 7.0 packages will require this change to have taken place, they will have to pre-depend upon an appropriate version of x11-common. As such, I'm writing to the list in accordance with policy. AIUI, that policy requirement is mostly in place since pre-depends in the pre-apt days would require users to do an extra [U]npack/[I]nstall cycle in dpkg. While it's still a good idea to be reluctant to add Pre-Depends, it's not the big problem it once was, and this seems to qualify as pretty legit. Cheers, aj signature.asc Description: Digital signature
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 08:55:00AM +, Colin Watson wrote: There is some software that contains hardcoded paths to executables in /usr/bin/X11; for example, sshd hardcodes the path to /usr/bin/X11/xauth. sshd stats whatever it thinks is the location of xauth to find out whether it can do X11 forwarding, so it's not entirely trivial to unhardcode this path. Ok, thanks for clarifying that. I wasn't aware of that issue. It also explains some of the errors I've had with partial upgrades from 6.9 to 7.0. Current Ubuntu makes /usr/bin/X11 a symlink to . (i.e. /usr/bin) which means that this all continues to work fine after xauth and friends move to /usr/bin. David's paragraph above implies something different. David? Right, I'm sorry. I'd forgotten about that part and had misread the script before sending the mail. /usr/bin/X11 is still a symlink to . (or rather ../bin), so anything installing to /usr/bin/X11 will actually install to /usr/bin. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
On Sun, Jan 22, 2006 at 09:54:54PM -0800, Russ Allbery wrote: David Nusinow [EMAIL PROTECTED] writes: Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. I understand why /usr/include/X11 and /usr/lib/X11 would stay; after all, those are perfectly reasonable names for what they are currently symlinks to. I don't understand why /usr/bin/X11 wouldn't go away completely, at least for the programs that come with X. Maybe that's the plan and the above is just a bit confusing since all three of those directories aren't treated quite the same way? Right. See Colin's mail and my reply for /usr/bin/X11. I'd forgotten that this one is a symlink to /usr/bin. The others are made in to directories. /usr/share/X11 is as well. Does upstream imake still dump everything into /usr/X11R6 or has it too been modified to use a more conventional installation structure? (Or is imake going away completely?) I'd love it if imake itself just used a better directory layout, since it's going to be a *long* time before everything that currently uses imake switches to some other build system (even if that's been in progress for years). Nathanael is right about imake. No one upstream is interested in maintaining it. I'm planning on packaging it for use in Debian (I'm still not sure which package it'll be in eventually) but as it's not being used for X any more I'm not particularly inclined to do much with it myself. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 07:32:33AM +0100, Mike Hommey wrote: On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow [EMAIL PROTECTED] wrote: Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. Shouldn't the fonts ans other such files go in /usr/*share*/X11, instead ? I don't have a good answer for you beyond speculation but I'll try and find out. Currently very little gets put in to /usr/share/X11 (XErrorDB and XKeysymDB on my partial install) so I'm not entirely sure what its role is as of yet. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 02:48:33AM -0500, Joey Hess wrote: David Nusinow wrote: Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. /usr/include/X11 makes some sense, it was mostly /usr/bin/X11 that I didn't see the point of. However, even /usr/include/X11 could potentially cause a problem, if a third party package currently installs headers in /usr/X11R6/include/foo and xorg updates /usr/include/X11 to be a directory rather than a symlink, then #include X11/foo will stop working. Switching any of these directories from symlinks to real directories seems likely to require some coordination beyond xorg. Well, Xorg 7.0 is currently deployed in Gentoo, Ubuntu, and Fedora's developmental branches, with more to come. So a great many apps are building and working with it as we speak. I'm sorry I forgot that /usr/bin/X11 is a symlink to /usr/bin (thanks to Colin again for pointing that out) so hopefully that'll put at least one issue to rest :-) As for the include location breaking things, I can imagine it but most build systems should be looking in /usr/include for headers anyway... The fonts directory issue can be fixed in policy easily enough, although again if a new version of X looks for fonts in /usr/lib/X11 and some third party packages install them in /usr/X11R6/lib, when the former directory stops being a symlink, those fonts won't be found. This is true, but breaking third party packages has never been a huge concern for Debian (or myself really ;-) Here's a maintainer-sorted list of packages that install files in /usr/X11R6: Thanks for putting this together! - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Pre-Depends for Xorg 7.0
Hi all, One of the changes happening for Xorg 7.0 is that it will finally become FHS compliant. Currently, it fakes FHS compliancy by creating various symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate directories in /usr/X11R6. For 7.0, we need to make those symlinks become actual directories. We're currently using the x11-common package to do this, although the XSF is considering unifying this package with xorg-common and naming the single common package xorg-common. Either way, this transition will be done by one of the -common packages. Because the remainder of the Xorg 7.0 packages will require this change to have taken place, they will have to pre-depend upon an appropriate version of x11-common. As such, I'm writing to the list in accordance with policy. The code to enact this change has been deployed successfully in Ubuntu and should translate just fine to Debian. I'll be uploading packages to experimental shortly to test for this, although I don't recommend anyone use it outside of a chroot until we have a more or less complete X suite available in experimental. If you have any questions or comments, please feel free to ask. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
David Nusinow wrote: One of the changes happening for Xorg 7.0 is that it will finally become FHS compliant. FWIW, the FHS 2.1 specifies /usr/X11R6 in section 4.1. I can't see anything FHS-incompliant about the current setup. Currently, it fakes FHS compliancy by creating various symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate directories in /usr/X11R6. For 7.0, we need to make those symlinks become actual directories. I thought that the idea instead was to move everything directly into /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories? Note that the FHS has this to say about /usr/bin/X11 and friends: In general, software must not be installed or managed via the above symbolic links. They are intended for utilization by users only. Because the remainder of the Xorg 7.0 packages will require this change to have taken place, they will have to pre-depend upon an appropriate version of x11-common. As such, I'm writing to the list in accordance with policy. What about all the packages that you don't control that also still put things in /usr/X11R6? Recall that policy allows this for anything still using Imake, as well as mandating it for any package containing X fonts. If the idea is to make /usr/*/X11 real directories and stop using /usr/X11R6 then all those package would also need to be updated and have a predependency added too. Seems easier just to move everything in X to /usr/bin, /usr/include, and /usr/lib. Also, moving stuff to /usr/bin/X11 and making it a real directory will break things for anyone having /usr/X11R6/bin in their path instead. One example of such a path is in pbuilder. -- see shy jo signature.asc Description: Digital signature
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote: David Nusinow wrote: One of the changes happening for Xorg 7.0 is that it will finally become FHS compliant. FWIW, the FHS 2.1 specifies /usr/X11R6 in section 4.1. I can't see anything FHS-incompliant about the current setup. As far as I understand it, this is simply grandfathered in. I'm not that up on the FHS details though, so I may be wrong. Remember also that this isn't X11R6 any more, but X11R7. Currently, it fakes FHS compliancy by creating various symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate directories in /usr/X11R6. For 7.0, we need to make those symlinks become actual directories. I thought that the idea instead was to move everything directly into /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories? Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. Note that the FHS has this to say about /usr/bin/X11 and friends: In general, software must not be installed or managed via the above symbolic links. They are intended for utilization by users only. Because the remainder of the Xorg 7.0 packages will require this change to have taken place, they will have to pre-depend upon an appropriate version of x11-common. As such, I'm writing to the list in accordance with policy. What about all the packages that you don't control that also still put things in /usr/X11R6? Recall that policy allows this for anything still using Imake, as well as mandating it for any package containing X fonts. Right, they're still allowed to as far as I'm concerned. It's basically that Xorg is giving up claim on that directory in a sense. I don't know about the fonts issue given the above, I'll look in to that. If the idea is to make /usr/*/X11 real directories and stop using /usr/X11R6 then all those package would also need to be updated and have a predependency added too. Seems easier just to move everything in X to /usr/bin, /usr/include, and /usr/lib. Also, moving stuff to /usr/bin/X11 and making it a real directory will break things for anyone having /usr/X11R6/bin in their path instead. One example of such a path is in pbuilder. As far as I currently know, all the apps will go to /usr/bin so it shouldn't break anything. I haven't packaged most of the apps though yet, so I can't say this for certain. I'll investigate it when I get to that stage of the process. We also have to consider that these decisions were made by upstream, not myself. These choices were made to make X a good citizen in the current unix world, and the fact that they are disruptive is the reason for the bump from X11R6 to 7. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
David Nusinow [EMAIL PROTECTED] writes: On Mon, Jan 23, 2006 at 12:15:23AM -0500, Joey Hess wrote: David Nusinow wrote: Currently, it fakes FHS compliancy by creating various symlinks (/usr/include/X11, /usr/bin/X11, /usr/lib/X11) to the appropriate directories in /usr/X11R6. For 7.0, we need to make those symlinks become actual directories. I thought that the idea instead was to move everything directly into /usr/include, /usr/bin, and /usr/lib. Why keep the X11 subdirectories? Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. I understand why /usr/include/X11 and /usr/lib/X11 would stay; after all, those are perfectly reasonable names for what they are currently symlinks to. I don't understand why /usr/bin/X11 wouldn't go away completely, at least for the programs that come with X. Maybe that's the plan and the above is just a bit confusing since all three of those directories aren't treated quite the same way? What about all the packages that you don't control that also still put things in /usr/X11R6? Recall that policy allows this for anything still using Imake, as well as mandating it for any package containing X fonts. Right, they're still allowed to as far as I'm concerned. It's basically that Xorg is giving up claim on that directory in a sense. I don't know about the fonts issue given the above, I'll look in to that. Does upstream imake still dump everything into /usr/X11R6 or has it too been modified to use a more conventional installation structure? (Or is imake going away completely?) I'd love it if imake itself just used a better directory layout, since it's going to be a *long* time before everything that currently uses imake switches to some other build system (even if that's been in progress for years). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
[David Nusinow] As far as I understand it, this is simply grandfathered in. I'm not that up on the FHS details though, so I may be wrong. Remember also that this isn't X11R6 any more, but X11R7. Branden toyed with the idea of setting ProjectRoot to /usr when packaging XFree86 4.0. I was sorta hoping he'd just do it. But in any case I'm glad it's being done now. everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. Well, /usr/include/X11 continues to make sense, particularly for Xlib and Xt, and probably for Xaw, SM, etc. /usr/bin/X11, not so much. signature.asc Description: Digital signature
Re: Pre-Depends for Xorg 7.0
On Mon, Jan 23, 2006 at 12:48:24AM -0500, David Nusinow [EMAIL PROTECTED] wrote: Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. Shouldn't the fonts ans other such files go in /usr/*share*/X11, instead ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
David Nusinow wrote: As far as I understand it, this is simply grandfathered in. I'm not that up on the FHS details though, so I may be wrong. Remember also that this isn't X11R6 any more, but X11R7. Ok, /usr/X11R7 would probably violate either the spirit or the letter of the FHS (probably not both :-), so I see why you want to move away from it, it's just the issue of converting these symlinks to directories that concerns me. Right. The everything that you'd expect to go in to /usr/bin and /usr/lib will install there, at least as far as Xorg goes. An example of that is that the new xterm package installs to /usr/bin rather than /usr/X11R6/bin. I haven't finished the packaging of everything, but it seems that some of the header files are put in to differenct dirs of /usr/include. I'll investigate the reasoning for this further. As for /usr/lib/X11, data files like fonts currently go in there. /usr/include/X11 makes some sense, it was mostly /usr/bin/X11 that I didn't see the point of. However, even /usr/include/X11 could potentially cause a problem, if a third party package currently installs headers in /usr/X11R6/include/foo and xorg updates /usr/include/X11 to be a directory rather than a symlink, then #include X11/foo will stop working. Switching any of these directories from symlinks to real directories seems likely to require some coordination beyond xorg. What about all the packages that you don't control that also still put things in /usr/X11R6? Recall that policy allows this for anything still using Imake, as well as mandating it for any package containing X fonts. Right, they're still allowed to as far as I'm concerned. It's basically that Xorg is giving up claim on that directory in a sense. I don't know about the fonts issue given the above, I'll look in to that. The fonts directory issue can be fixed in policy easily enough, although again if a new version of X looks for fonts in /usr/lib/X11 and some third party packages install them in /usr/X11R6/lib, when the former directory stops being a symlink, those fonts won't be found. Here's a maintainer-sorted list of packages that install files in /usr/X11R6: MJ Ray (Debian) [EMAIL PROTECTED] wily Clint Adams [EMAIL PROTECTED] xmaddressbook Russ Allbery [EMAIL PROTECTED] xfonts-jmk Juan Alvarez [EMAIL PROTECTED] ipsc Tore Anderson [EMAIL PROTECTED] xfonts-ay Ryuichi Arafune [EMAIL PROTECTED] toolbar-fancy Hakan Ardo [EMAIL PROTECTED] xfaces Enrique Robledo Arnuncio [EMAIL PROTECTED] mctools-lite Lars Bahner [EMAIL PROTECTED] xcal Miros/law L. Baran [EMAIL PROTECTED] xenophilia Michael Beattie [EMAIL PROTECTED] xdkcal Jon Bernard [EMAIL PROTECTED] xfonts-knickers Edward Betts [EMAIL PROTECTED] cmatrix Bastian Blank [EMAIL PROTECTED] gpa Eduard Bloch [EMAIL PROTECTED] emelfm Philip Brown [EMAIL PROTECTED] kdrill Rob Browning [EMAIL PROTECTED] guile-core Martin Buck [EMAIL PROTECTED] xview Randolph Chung [EMAIL PROTECTED] xgdipc Artem Chuprina [EMAIL PROTECTED] xxkb Debian GCC Maintainers debian-gcc@lists.debian.org gcc-snapshot Debian X Strike Force debian-x@lists.debian.org libxrender renderext xcursor xft xorg-x11 Eric Delaunay [EMAIL PROTECTED] xtel Scott M. Dier [EMAIL PROTECTED] xmeter Randall Donald [EMAIL PROTECTED] gradio nvidia-graphics-drivers nvidia-graphics-drivers-legacy Mattia Dongili [EMAIL PROTECTED] xfree86-driver-synaptics Benjamin Drieu [EMAIL PROTECTED] w9wm Baruch Even [EMAIL PROTECTED] xclip Anthony Fok [EMAIL PROTECTED] xcingb xfonts-cmex-big5p Gordon Fraser [EMAIL PROTECTED] wmavgload Philipp Frauenfelder [EMAIL PROTECTED] wmnet Peter S Galbraith [EMAIL PROTECTED] libforms1 Bdale Garbee [EMAIL PROTECTED] xtrkcad Guenter Geiger [EMAIL PROTECTED] ivtools Debian QA Group [EMAIL PROTECTED] dosemu goldedplus hanterm-classic hanterm-xf lmodern oneko pgaccess ppxp xmailbox xmem xsysinfo Francois Gurin [EMAIL PROTECTED] xvkbd Chris Halls [EMAIL PROTECTED] ayttm Mikael Hedin [EMAIL PROTECTED] plotmtv Joey Hess [EMAIL PROTECTED] big-cursor Ralf Hildebrandt [EMAIL PROTECTED] xscreensaver Simon Horman [EMAIL PROTECTED] xfont-nexus Simon Horman [EMAIL PROTECTED] xfonts-nexus Daniel Jacobowitz [EMAIL PROTECTED] ircii-pana Guillem Jover [EMAIL PROTECTED] glide Takao KAWAMURA [EMAIL PROTECTED] cmail xbatt Tomohiro KUBOTA [EMAIL PROTECTED] xearth xfonts-efont-unicode Zdenek Kabelac [EMAIL PROTECTED] fte Tatsuya Kinoshita [EMAIL PROTECTED] bitmap-mule Gerd Knorr [EMAIL PROTECTED] openmotif tv-fonts Alexander Kotelnikov [EMAIL PROTECTED] fvwm-icons Joshua Kwan [EMAIL PROTECTED] nethack Rafael Laboissiere [EMAIL PROTECTED] tipa Warren A. Layton [EMAIL PROTECTED] wmcpu wmdate wmscope A Lee [EMAIL PROTECTED] xfonts-artwiz Aaron Lehmann [EMAIL
