Discussion:
Request for volunteers to help track down packages that use /usr/X11R6
(too old to reply)
Mike A. Harris
2005-08-30 23:06:35 UTC
Permalink
Overview:
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.

Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.

A year or two ago, I knew this change would be coming in the
future, and sent out email to inform other package maintainers
that they should update their packages to install their files
in FHS compliant directories instead of abusing the /usr/X11R6
heirarchy. I'm not sure how many people actually listened
though, so we're about to find out. ;o)


What's changing specifically:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
at all. It uses /usr, and installs files where you'd expect
them to be found within that heirarchy more or less (although
it is a bit buggy in this regard currently, that'll be fixed
prior to X11R7's final release). The libraries, binaries,
fonts, config files, data files - everything is moving.

Along with this upstream X.Org change, there will be a number
of backward compatibility issues that we'll face, where we
may need to provide backward compatible symlinks for cases like
applications hard coding the path to X binaries instead of
using "which <appname>" and similar. We'll be keeping an
eye on such issues and considering where we should provide
compatibility links.


What we'd like volunteers to help with:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) A lot of existing Fedora Core, Fedora Extras and other 3rd
party packages currently install themselves into /usr/X11R6,
need to be updated to install themselves in a more
appropriate location under /usr, using %{_datadir} and
friends in their rpm specfiles. Volunteers are needed who
are willing to take on the task of reporting bugs against
the offending packages, and preferably also attaching
patches to fix the rpms.

2) A number of packages might have shell scripts, .desktop
files, or other things with hard coded paths to binaries
such as /usr/X11R6/bin/xterm, or to data files, or other
files traditionally installed under /usr/X11R6. Please
report bugs against these packages, and where possible,
change them to use "which <appname>" instead of hard
coding the path to the executable/file directly. In some
cases dynamic solution might not work, so hard code the
new path in that case unless there's another appropriate
solution apparent.

3) If you can personally think of any application or compat
problems that might occur when the changeover is made,
please report them to me via email in advance, so we can
try to find a solution sooner than later.


This message is being sent out to encourage community
involvement in the process, and to help weed out problems
sooner in the development cycle than later on, as there
is likely to be a fair amount of package churn, so we'd
like to get things in order far far in advance of
FC5test1.

Thanks in advance for any feedback, and also to any
volunteers who decide to help out.
dragoran
2005-08-31 07:08:54 UTC
Permalink
Post by Mike A. Harris
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.
Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.
A year or two ago, I knew this change would be coming in the
future, and sent out email to inform other package maintainers
that they should update their packages to install their files
in FHS compliant directories instead of abusing the /usr/X11R6
heirarchy. I'm not sure how many people actually listened
though, so we're about to find out. ;o)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
at all. It uses /usr, and installs files where you'd expect
them to be found within that heirarchy more or less (although
it is a bit buggy in this regard currently, that'll be fixed
prior to X11R7's final release). The libraries, binaries,
fonts, config files, data files - everything is moving.
Along with this upstream X.Org change, there will be a number
of backward compatibility issues that we'll face, where we
may need to provide backward compatible symlinks for cases like
applications hard coding the path to X binaries instead of
using "which <appname>" and similar. We'll be keeping an
eye on such issues and considering where we should provide
compatibility links.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) A lot of existing Fedora Core, Fedora Extras and other 3rd
party packages currently install themselves into /usr/X11R6,
need to be updated to install themselves in a more
appropriate location under /usr, using %{_datadir} and
friends in their rpm specfiles. Volunteers are needed who
are willing to take on the task of reporting bugs against
the offending packages, and preferably also attaching
patches to fix the rpms.
2) A number of packages might have shell scripts, .desktop
files, or other things with hard coded paths to binaries
such as /usr/X11R6/bin/xterm, or to data files, or other
files traditionally installed under /usr/X11R6. Please
report bugs against these packages, and where possible,
change them to use "which <appname>" instead of hard
coding the path to the executable/file directly. In some
cases dynamic solution might not work, so hard code the
new path in that case unless there's another appropriate
solution apparent.
3) If you can personally think of any application or compat
problems that might occur when the changeover is made,
please report them to me via email in advance, so we can
try to find a solution sooner than later.
This message is being sent out to encourage community
involvement in the process, and to help weed out problems
sooner in the development cycle than later on, as there
is likely to be a fair amount of package churn, so we'd
like to get things in order far far in advance of
FC5test1.
Thanks in advance for any feedback, and also to any
volunteers who decide to help out.
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which
allready make problems on multilib systems)
Matthias Saou
2005-08-31 08:05:35 UTC
Permalink
Post by dragoran
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which
allready make problems on multilib systems)
Indeed, that one will be a bit of a problem. Which brings an interesting
question : Will the new X11R7 use pkgconfig? That would be nice, as
replacing the above with "pkg-config --libs xorg-x11" should be easy, as
well as modifying configure checks.

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 0.36 0.36 0.26
Matthias Saou
2005-08-31 08:05:35 UTC
Permalink
Post by dragoran
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which
allready make problems on multilib systems)
Indeed, that one will be a bit of a problem. Which brings an interesting
question : Will the new X11R7 use pkgconfig? That would be nice, as
replacing the above with "pkg-config --libs xorg-x11" should be easy, as
well as modifying configure checks.

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 0.36 0.36 0.26
Mike A. Harris
2005-09-04 12:35:40 UTC
Permalink
Post by dragoran
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which
allready make problems on multilib systems)
Indeed... -I/usr/X11R6/lib/X11/include is another problem case perhaps
too. Fortunately, the modular X libraries all provide pkg-config files
now. Any packages or Makefiles that hard code -L or -I paths, etc.
will now need to be updated to use pkg-config.

The X server provides pkgconfig files so apps/tools know where things
like the module directory is also. There's only 2 or 3 packages in
the OS that that should affect though:

synaptics
linuxwacom
vnc

Can anyone think of any others?

TIA
Mike A. Harris
2005-09-04 12:35:40 UTC
Permalink
Post by dragoran
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which
allready make problems on multilib systems)
Indeed... -I/usr/X11R6/lib/X11/include is another problem case perhaps
too. Fortunately, the modular X libraries all provide pkg-config files
now. Any packages or Makefiles that hard code -L or -I paths, etc.
will now need to be updated to use pkg-config.

The X server provides pkgconfig files so apps/tools know where things
like the module directory is also. There's only 2 or 3 packages in
the OS that that should affect though:

synaptics
linuxwacom
vnc

Can anyone think of any others?

TIA
Peter Lemenkov
2005-08-31 14:00:56 UTC
Permalink
Post by Mike A. Harris
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.
Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.
# ln -s /usr /usr/X11R6

and forget about this problem...
--
With best regards, Peter Lemenkov.
Matthias Saou
2005-08-31 10:08:23 UTC
Permalink
Post by Peter Lemenkov
# ln -s /usr /usr/X11R6
and forget about this problem...
Not sure how serious you're meaning to be, but it's worth pointing out
that this is a typical complete blocker with rpm : Replacing a directory
with a symlink is impossible, unless the directory is empty and some %pre
scriplet takes care of removing it. Well, you've also got the option of
"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he
should! ;-)).

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 0.61 0.38 0.30
Ignacio Vazquez-Abrams
2005-08-31 10:24:01 UTC
Permalink
Post by Matthias Saou
Post by Peter Lemenkov
# ln -s /usr /usr/X11R6
and forget about this problem...
Not sure how serious you're meaning to be, but it's worth pointing out
that this is a typical complete blocker with rpm : Replacing a directory
with a symlink is impossible, unless the directory is empty and some %pre
scriplet takes care of removing it. Well, you've also got the option of
"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he
should! ;-)).
The only packages that own the dir are filesystem and (ugh) vnc-server.
--
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050831/13be16d0/attachment.bin
Hans de Goede
2005-08-31 10:35:35 UTC
Permalink
Post by Ignacio Vazquez-Abrams
Post by Matthias Saou
Post by Peter Lemenkov
# ln -s /usr /usr/X11R6
and forget about this problem...
Not sure how serious you're meaning to be, but it's worth pointing out
that this is a typical complete blocker with rpm : Replacing a directory
with a symlink is impossible, unless the directory is empty and some %pre
scriplet takes care of removing it. Well, you've also got the option of
"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he
should! ;-)).
The only packages that own the dir are filesystem and (ugh) vnc-server.
"(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the
following output on my system:
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
fonts-xorg-truetype-6.8.2-1
multimedia-2.1-21
openmotif-2.2.3-10
playmidi-X11-2.4-16
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xdm-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7

IOW:
multimedia
openmotif
playmidi
xscreensaver-base
xterm

Are the only non xorg packages on my system which use /use/X11R6 and
thus need fixing.

Regards,

Hans
Matthias Saou
2005-08-31 10:44:19 UTC
Permalink
Post by Hans de Goede
multimedia
openmotif
playmidi
xscreensaver-base
xterm
Are the only non xorg packages on my system which use /use/X11R6 and
thus need fixing.
I've got vim-X11 to add to the above :-)
In the end, it's very little, I guess Mike's previous warning did get
taken seriously ;-)

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 0.42 0.51 0.44
Rodd Clarkson
2005-08-31 11:01:33 UTC
Permalink
Post by Hans de Goede
"(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
fonts-xorg-truetype-6.8.2-1
multimedia-2.1-21
openmotif-2.2.3-10
playmidi-X11-2.4-16
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xdm-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7
multimedia
openmotif
playmidi
xscreensaver-base
xterm
I get this:

[rodd at localhost ~]$ (find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq
fonts-xorg-100dpi-6.8.2-1
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
linuxwacom-0.6.6-5
nvidia-glx-1.0.7174-0.lvn.4.4
nvidia-glx-devel-1.0.7174-0.lvn.4.4
openmotif-2.2.3-10
openmotif-devel-2.2.3-10
synaptics-0.14.3-3
vnc-server-4.1.1-16
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-deprecated-libs-devel-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-twm-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7

Don't know what this adds to the list.


R.
--
"It's a fine line between denial and faith.
It's much better on my side"
Ralf Ertzinger
2005-08-31 11:25:10 UTC
Permalink
Hi.
Post by Rodd Clarkson
Don't know what this adds to the list.
fluxbox-0.9.13-2.fc5
gv-3.5.8-29
iiimf-x-12.2-6
kterm-6.2.0-40
libXvMCW-0.9.3-1.2.fc4
mtr-gtk-0.69-3
transfig-3.2.4-11
x3270-x11-3.3.4-3
xawtv-3.88-6
xfig-3.2.4-11

I think I got all duplicates posted so far out.
--
"The reasonable man adapts himself to the world: the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man." -- George Bernard Shaw
Kjartan Maraas
2005-08-31 12:20:19 UTC
Permalink
Hi.
Post by Rodd Clarkson
Don't know what this adds to the list.
My additions are:

nedit-5.5-4
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xloadimage-4.1-34.FC3

Cheers
Kjartan
Jeff Spaleta
2005-08-31 14:05:55 UTC
Permalink
Post by Kjartan Maraas
nedit-5.5-4
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xloadimage-4.1-34.FC3
Checking the package scriptlets for items I have installed on my fc4 machine
rpm -qa --qf "%{NAME}:\n%{POSTIN}\n\n"

fonts-japanese
urw-fonts
as well as other packages already mentioned so far.

rpm -qa --qf "%{NAME}:\n%{TRIGGERSCRIPTS}\n\n"
freetype
man

Can repoquery be used to do this against all packages in the repos?

-jef"the references to X11R6 in trigger scripts sort of scares me"spaleta
Toshio Kuratomi
2005-08-31 14:32:27 UTC
Permalink
Post by Jeff Spaleta
Post by Kjartan Maraas
nedit-5.5-4
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xloadimage-4.1-34.FC3
Checking the package scriptlets for items I have installed on my fc4 machine
rpm -qa --qf "%{NAME}:\n%{POSTIN}\n\n"
fonts-japanese
urw-fonts
as well as other packages already mentioned so far.
rpm -qa --qf "%{NAME}:\n%{TRIGGERSCRIPTS}\n\n"
freetype
man
Can repoquery be used to do this against all pnckages in the repos?
Has the metadata been changed to include the scriptlets? A quick scan
of other.xml.gz from development seems to only show changelogs. So we
won't be able to scan scriptlets through any of the yum functions.

We could scan all spec files in FC and FE pretty easily to see what
could be there. (Download the cvs daily seed from cvs.fedora.redhat.com
then scan the spec files for /X11 references.)

For Mike's #1 I posted a quick and dirty script last night that scanned
filelists.xml.gz for files in /usr/X11* /usr/lib/X11* /usr/bin/X11/*.
Posted it in a reply to Mike's maintainer-list post instead of here,
oops. Too many mailing lists....

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050831/4ff9f954/attachment.bin
Toshio Kuratomi
2005-08-31 14:32:27 UTC
Permalink
Post by Jeff Spaleta
Post by Kjartan Maraas
nedit-5.5-4
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xloadimage-4.1-34.FC3
Checking the package scriptlets for items I have installed on my fc4 machine
rpm -qa --qf "%{NAME}:\n%{POSTIN}\n\n"
fonts-japanese
urw-fonts
as well as other packages already mentioned so far.
rpm -qa --qf "%{NAME}:\n%{TRIGGERSCRIPTS}\n\n"
freetype
man
Can repoquery be used to do this against all pnckages in the repos?
Has the metadata been changed to include the scriptlets? A quick scan
of other.xml.gz from development seems to only show changelogs. So we
won't be able to scan scriptlets through any of the yum functions.

We could scan all spec files in FC and FE pretty easily to see what
could be there. (Download the cvs daily seed from cvs.fedora.redhat.com
then scan the spec files for /X11 references.)

For Mike's #1 I posted a quick and dirty script last night that scanned
filelists.xml.gz for files in /usr/X11* /usr/lib/X11* /usr/bin/X11/*.
Posted it in a reply to Mike's maintainer-list post instead of here,
oops. Too many mailing lists....

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050831/4ff9f954/attachment-0002.bin
Jeff Spaleta
2005-08-31 14:05:55 UTC
Permalink
Post by Kjartan Maraas
nedit-5.5-4
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xloadimage-4.1-34.FC3
Checking the package scriptlets for items I have installed on my fc4 machine
rpm -qa --qf "%{NAME}:\n%{POSTIN}\n\n"

fonts-japanese
urw-fonts
as well as other packages already mentioned so far.

rpm -qa --qf "%{NAME}:\n%{TRIGGERSCRIPTS}\n\n"
freetype
man

Can repoquery be used to do this against all packages in the repos?

-jef"the references to X11R6 in trigger scripts sort of scares me"spaleta
Kjartan Maraas
2005-08-31 12:20:19 UTC
Permalink
Hi.
Post by Rodd Clarkson
Don't know what this adds to the list.
My additions are:

nedit-5.5-4
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xloadimage-4.1-34.FC3

Cheers
Kjartan
Mike A. Harris
2005-09-04 12:38:36 UTC
Permalink
Post by Ralf Ertzinger
Hi.
Post by Rodd Clarkson
Don't know what this adds to the list.
fluxbox-0.9.13-2.fc5
gv-3.5.8-29
iiimf-x-12.2-6
kterm-6.2.0-40
libXvMCW-0.9.3-1.2.fc4
mtr-gtk-0.69-3
transfig-3.2.4-11
x3270-x11-3.3.4-3
xawtv-3.88-6
xfig-3.2.4-11
I think I got all duplicates posted so far out.
Thanks, added to list.
Mike A. Harris
2005-09-04 12:38:36 UTC
Permalink
Post by Ralf Ertzinger
Hi.
Post by Rodd Clarkson
Don't know what this adds to the list.
fluxbox-0.9.13-2.fc5
gv-3.5.8-29
iiimf-x-12.2-6
kterm-6.2.0-40
libXvMCW-0.9.3-1.2.fc4
mtr-gtk-0.69-3
transfig-3.2.4-11
x3270-x11-3.3.4-3
xawtv-3.88-6
xfig-3.2.4-11
I think I got all duplicates posted so far out.
Thanks, added to list.
Matthias Saou
2005-08-31 11:43:07 UTC
Permalink
Post by Rodd Clarkson
linuxwacom-0.6.6-5
synaptics-0.14.3-3
vnc-server-4.1.1-16
These packages (and probably some more), are making proper usage
of /usr/X11R6 since they're actually installing extensions to the X
server. I guess they will need to be modified only once the new location
of the modules is known and working.

I confirm that vnc-server does have a bug in the %files section though,
since it owns /usr/X11R6 as pointed out already ;-)

I've filed a bug report for vim-X11 :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167176

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 1.20 0.41 0.35
Ralf Ertzinger
2005-08-31 11:25:10 UTC
Permalink
Hi.
Post by Rodd Clarkson
Don't know what this adds to the list.
fluxbox-0.9.13-2.fc5
gv-3.5.8-29
iiimf-x-12.2-6
kterm-6.2.0-40
libXvMCW-0.9.3-1.2.fc4
mtr-gtk-0.69-3
transfig-3.2.4-11
x3270-x11-3.3.4-3
xawtv-3.88-6
xfig-3.2.4-11

I think I got all duplicates posted so far out.
--
"The reasonable man adapts himself to the world: the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man." -- George Bernard Shaw
Matthias Saou
2005-08-31 11:43:07 UTC
Permalink
Post by Rodd Clarkson
linuxwacom-0.6.6-5
synaptics-0.14.3-3
vnc-server-4.1.1-16
These packages (and probably some more), are making proper usage
of /usr/X11R6 since they're actually installing extensions to the X
server. I guess they will need to be modified only once the new location
of the modules is known and working.

I confirm that vnc-server does have a bug in the %files section though,
since it owns /usr/X11R6 as pointed out already ;-)

I've filed a bug report for vim-X11 :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167176

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 1.20 0.41 0.35
Mike A. Harris
2005-09-04 12:37:57 UTC
Permalink
Post by Rodd Clarkson
[rodd at localhost ~]$ (find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq
fonts-xorg-100dpi-6.8.2-1
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
linuxwacom-0.6.6-5
nvidia-glx-1.0.7174-0.lvn.4.4
nvidia-glx-devel-1.0.7174-0.lvn.4.4
openmotif-2.2.3-10
openmotif-devel-2.2.3-10
synaptics-0.14.3-3
vnc-server-4.1.1-16
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-deprecated-libs-devel-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-twm-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7
Don't know what this adds to the list.
Thanks, I've added these to the master list. Once the list is populated
for a few days, I think I will make a web page somewhere with everything
in a table, with status column indicating what things have been fixed,
what still needs fixing, and what repo (FC/FE/Livna/etc.) it is in.

TTYL
Mike A. Harris
2005-09-04 12:37:57 UTC
Permalink
Post by Rodd Clarkson
[rodd at localhost ~]$ (find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq
fonts-xorg-100dpi-6.8.2-1
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
linuxwacom-0.6.6-5
nvidia-glx-1.0.7174-0.lvn.4.4
nvidia-glx-devel-1.0.7174-0.lvn.4.4
openmotif-2.2.3-10
openmotif-devel-2.2.3-10
synaptics-0.14.3-3
vnc-server-4.1.1-16
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-deprecated-libs-devel-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-twm-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7
Don't know what this adds to the list.
Thanks, I've added these to the master list. Once the list is populated
for a few days, I think I will make a web page somewhere with everything
in a table, with status column indicating what things have been fixed,
what still needs fixing, and what repo (FC/FE/Livna/etc.) it is in.

TTYL
Matthias Saou
2005-08-31 10:44:19 UTC
Permalink
Post by Hans de Goede
multimedia
openmotif
playmidi
xscreensaver-base
xterm
Are the only non xorg packages on my system which use /use/X11R6 and
thus need fixing.
I've got vim-X11 to add to the above :-)
In the end, it's very little, I guess Mike's previous warning did get
taken seriously ;-)

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 0.42 0.51 0.44
Rodd Clarkson
2005-08-31 11:01:33 UTC
Permalink
Post by Hans de Goede
"(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
fonts-xorg-truetype-6.8.2-1
multimedia-2.1-21
openmotif-2.2.3-10
playmidi-X11-2.4-16
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xdm-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7
multimedia
openmotif
playmidi
xscreensaver-base
xterm
I get this:

[rodd at localhost ~]$ (find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq
fonts-xorg-100dpi-6.8.2-1
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
linuxwacom-0.6.6-5
nvidia-glx-1.0.7174-0.lvn.4.4
nvidia-glx-devel-1.0.7174-0.lvn.4.4
openmotif-2.2.3-10
openmotif-devel-2.2.3-10
synaptics-0.14.3-3
vnc-server-4.1.1-16
Xaw3d-1.5E-4
Xaw3d-devel-1.5E-4
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-deprecated-libs-devel-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-twm-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7

Don't know what this adds to the list.


R.
--
"It's a fine line between denial and faith.
It's much better on my side"
Mike A. Harris
2005-09-04 12:32:32 UTC
Permalink
Post by Hans de Goede
"(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
fonts-xorg-truetype-6.8.2-1
multimedia-2.1-21
openmotif-2.2.3-10
playmidi-X11-2.4-16
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xdm-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7
multimedia
openmotif
playmidi
xscreensaver-base
xterm
Are the only non xorg packages on my system which use /use/X11R6 and
thus need fixing.
Thanks for the list hans. I've added these to my local hit-list.

Another issue I just thought of, is "imake". I wonder how many
things are going to now break since X no longer uses imake as its
build system. imake is now avail as a separate tarball, and I'm
sure we'll likely be providing it for compatibility for apps that
use it to build with for a while, but AFAIK, there wont be X
configs like host.def et al. so apps that use imake that way will
likely break.

I guess that's an opportunity to drop apps from Core, or convince
people to autotool them? ;o)
Mike A. Harris
2005-09-04 12:32:32 UTC
Permalink
Post by Hans de Goede
"(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
fonts-xorg-truetype-6.8.2-1
multimedia-2.1-21
openmotif-2.2.3-10
playmidi-X11-2.4-16
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xdm-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7
multimedia
openmotif
playmidi
xscreensaver-base
xterm
Are the only non xorg packages on my system which use /use/X11R6 and
thus need fixing.
Thanks for the list hans. I've added these to my local hit-list.

Another issue I just thought of, is "imake". I wonder how many
things are going to now break since X no longer uses imake as its
build system. imake is now avail as a separate tarball, and I'm
sure we'll likely be providing it for compatibility for apps that
use it to build with for a while, but AFAIK, there wont be X
configs like host.def et al. so apps that use imake that way will
likely break.

I guess that's an opportunity to drop apps from Core, or convince
people to autotool them? ;o)
Hans de Goede
2005-08-31 10:35:35 UTC
Permalink
Post by Ignacio Vazquez-Abrams
Post by Matthias Saou
Post by Peter Lemenkov
# ln -s /usr /usr/X11R6
and forget about this problem...
Not sure how serious you're meaning to be, but it's worth pointing out
that this is a typical complete blocker with rpm : Replacing a directory
with a symlink is impossible, unless the directory is empty and some %pre
scriplet takes care of removing it. Well, you've also got the option of
"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he
should! ;-)).
The only packages that own the dir are filesystem and (ugh) vnc-server.
"(find /usr/X11R6 -type f | xargs rpm -qf) | sort | uniq" gives the
following output on my system:
fonts-xorg-75dpi-6.8.2-1
fonts-xorg-base-6.8.2-1
fonts-xorg-truetype-6.8.2-1
multimedia-2.1-21
openmotif-2.2.3-10
playmidi-X11-2.4-16
xinitrc-4.0.19-1
xorg-x11-6.8.2-45
xorg-x11-Mesa-libGL-6.8.2-45
xorg-x11-Mesa-libGLU-6.8.2-45
xorg-x11-deprecated-libs-6.8.2-45
xorg-x11-devel-6.8.2-45
xorg-x11-font-utils-6.8.2-45
xorg-x11-libs-6.8.2-45
xorg-x11-tools-6.8.2-45
xorg-x11-xauth-6.8.2-45
xorg-x11-xdm-6.8.2-45
xorg-x11-xfs-6.8.2-45
xscreensaver-base-4.22-10
xterm-200-7

IOW:
multimedia
openmotif
playmidi
xscreensaver-base
xterm

Are the only non xorg packages on my system which use /use/X11R6 and
thus need fixing.

Regards,

Hans
Ignacio Vazquez-Abrams
2005-08-31 10:24:01 UTC
Permalink
Post by Matthias Saou
Post by Peter Lemenkov
# ln -s /usr /usr/X11R6
and forget about this problem...
Not sure how serious you're meaning to be, but it's worth pointing out
that this is a typical complete blocker with rpm : Replacing a directory
with a symlink is impossible, unless the directory is empty and some %pre
scriplet takes care of removing it. Well, you've also got the option of
"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he
should! ;-)).
The only packages that own the dir are filesystem and (ugh) vnc-server.
--
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050831/13be16d0/attachment-0002.bin
Matthias Saou
2005-08-31 10:08:23 UTC
Permalink
Post by Peter Lemenkov
# ln -s /usr /usr/X11R6
and forget about this problem...
Not sure how serious you're meaning to be, but it's worth pointing out
that this is a typical complete blocker with rpm : Replacing a directory
with a symlink is impossible, unless the directory is empty and some %pre
scriplet takes care of removing it. Well, you've also got the option of
"extreme ugliness", but I'm pretty sure Mike wants to avoid that (and he
should! ;-)).

Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.12-1.1398_FC4
Load : 0.61 0.38 0.30
Mike A. Harris
2005-09-04 12:29:09 UTC
Permalink
Post by Peter Lemenkov
Post by Mike A. Harris
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.
Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.
# ln -s /usr /usr/X11R6
and forget about this problem...
There are 2 reasons why that solution isn't suitable:

1) rpm is unable to replace a directory (/usr/X11R6 for example)
with a symlink when upgrading.

2) Numerous other pieces of software install themselves into
/usr/X11R6 even though they have no right to do so, and are
not part of "X11". Even if you remove the xorg-x11 rpm
packages from your system completely, there are still tonnes
of files in /usr/X11R6 that do not belong to the X Window
System. Some of these files are owned by other rpm packages,
and some of them might not be owned by any package, such
as files that are generated at runtime (fonts.dir for
example from packages that do not properly use %ghost), or
might be present from software installed from tarball sources.


Therefore, it isn't possible to remove the directory anyway, and
trying to "move" the directory would break the rpm packages that
are installed which contain files in there.

Having said that however, it certainly would be nice to be able
to symlink /usr/X11R6 to /usr if there weren't new technical
problems created in the process by doing so.

Thanks for the suggestion however.
Mike A. Harris
2005-09-04 12:29:09 UTC
Permalink
Post by Peter Lemenkov
Post by Mike A. Harris
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.
Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.
# ln -s /usr /usr/X11R6
and forget about this problem...
There are 2 reasons why that solution isn't suitable:

1) rpm is unable to replace a directory (/usr/X11R6 for example)
with a symlink when upgrading.

2) Numerous other pieces of software install themselves into
/usr/X11R6 even though they have no right to do so, and are
not part of "X11". Even if you remove the xorg-x11 rpm
packages from your system completely, there are still tonnes
of files in /usr/X11R6 that do not belong to the X Window
System. Some of these files are owned by other rpm packages,
and some of them might not be owned by any package, such
as files that are generated at runtime (fonts.dir for
example from packages that do not properly use %ghost), or
might be present from software installed from tarball sources.


Therefore, it isn't possible to remove the directory anyway, and
trying to "move" the directory would break the rpm packages that
are installed which contain files in there.

Having said that however, it certainly would be nice to be able
to symlink /usr/X11R6 to /usr if there weren't new technical
problems created in the process by doing so.

Thanks for the suggestion however.
Mike A. Harris
2005-08-30 23:06:35 UTC
Permalink
Overview:
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.

Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.

A year or two ago, I knew this change would be coming in the
future, and sent out email to inform other package maintainers
that they should update their packages to install their files
in FHS compliant directories instead of abusing the /usr/X11R6
heirarchy. I'm not sure how many people actually listened
though, so we're about to find out. ;o)


What's changing specifically:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
at all. It uses /usr, and installs files where you'd expect
them to be found within that heirarchy more or less (although
it is a bit buggy in this regard currently, that'll be fixed
prior to X11R7's final release). The libraries, binaries,
fonts, config files, data files - everything is moving.

Along with this upstream X.Org change, there will be a number
of backward compatibility issues that we'll face, where we
may need to provide backward compatible symlinks for cases like
applications hard coding the path to X binaries instead of
using "which <appname>" and similar. We'll be keeping an
eye on such issues and considering where we should provide
compatibility links.


What we'd like volunteers to help with:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) A lot of existing Fedora Core, Fedora Extras and other 3rd
party packages currently install themselves into /usr/X11R6,
need to be updated to install themselves in a more
appropriate location under /usr, using %{_datadir} and
friends in their rpm specfiles. Volunteers are needed who
are willing to take on the task of reporting bugs against
the offending packages, and preferably also attaching
patches to fix the rpms.

2) A number of packages might have shell scripts, .desktop
files, or other things with hard coded paths to binaries
such as /usr/X11R6/bin/xterm, or to data files, or other
files traditionally installed under /usr/X11R6. Please
report bugs against these packages, and where possible,
change them to use "which <appname>" instead of hard
coding the path to the executable/file directly. In some
cases dynamic solution might not work, so hard code the
new path in that case unless there's another appropriate
solution apparent.

3) If you can personally think of any application or compat
problems that might occur when the changeover is made,
please report them to me via email in advance, so we can
try to find a solution sooner than later.


This message is being sent out to encourage community
involvement in the process, and to help weed out problems
sooner in the development cycle than later on, as there
is likely to be a fair amount of package churn, so we'd
like to get things in order far far in advance of
FC5test1.

Thanks in advance for any feedback, and also to any
volunteers who decide to help out.
dragoran
2005-08-31 07:08:54 UTC
Permalink
Post by Mike A. Harris
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.
Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.
A year or two ago, I knew this change would be coming in the
future, and sent out email to inform other package maintainers
that they should update their packages to install their files
in FHS compliant directories instead of abusing the /usr/X11R6
heirarchy. I'm not sure how many people actually listened
though, so we're about to find out. ;o)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
at all. It uses /usr, and installs files where you'd expect
them to be found within that heirarchy more or less (although
it is a bit buggy in this regard currently, that'll be fixed
prior to X11R7's final release). The libraries, binaries,
fonts, config files, data files - everything is moving.
Along with this upstream X.Org change, there will be a number
of backward compatibility issues that we'll face, where we
may need to provide backward compatible symlinks for cases like
applications hard coding the path to X binaries instead of
using "which <appname>" and similar. We'll be keeping an
eye on such issues and considering where we should provide
compatibility links.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) A lot of existing Fedora Core, Fedora Extras and other 3rd
party packages currently install themselves into /usr/X11R6,
need to be updated to install themselves in a more
appropriate location under /usr, using %{_datadir} and
friends in their rpm specfiles. Volunteers are needed who
are willing to take on the task of reporting bugs against
the offending packages, and preferably also attaching
patches to fix the rpms.
2) A number of packages might have shell scripts, .desktop
files, or other things with hard coded paths to binaries
such as /usr/X11R6/bin/xterm, or to data files, or other
files traditionally installed under /usr/X11R6. Please
report bugs against these packages, and where possible,
change them to use "which <appname>" instead of hard
coding the path to the executable/file directly. In some
cases dynamic solution might not work, so hard code the
new path in that case unless there's another appropriate
solution apparent.
3) If you can personally think of any application or compat
problems that might occur when the changeover is made,
please report them to me via email in advance, so we can
try to find a solution sooner than later.
This message is being sent out to encourage community
involvement in the process, and to help weed out problems
sooner in the development cycle than later on, as there
is likely to be a fair amount of package churn, so we'd
like to get things in order far far in advance of
FC5test1.
Thanks in advance for any feedback, and also to any
volunteers who decide to help out.
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which
allready make problems on multilib systems)
Peter Lemenkov
2005-08-31 14:00:56 UTC
Permalink
Post by Mike A. Harris
~~~~~~~~
The X.Org Foundation has finally changed X11 to install itself
into the /usr heirarchy by default instead of the /usr/X11R6
hierarchy. The basic rationale is that with modern packaging
systems like rpm, deb, etc., there is no need to isolate the
X Window System into its own private hierarchy on the filesystem.
Originally, the /usr/X11R6 directory was intended to strictly
be the location where X11R6 itself would get installed. Over
time however various other 3rd party software packages, addons
and other stuff has infiltrated into the /usr/X11R6 heirarchy
for no really good reason, and some of it still sits in there
today.
# ln -s /usr /usr/X11R6

and forget about this problem...
--
With best regards, Peter Lemenkov.
Mike A. Harris
2005-09-04 11:26:09 UTC
Permalink
Mike A. Harris wrote:
[SNIP]
Post by Mike A. Harris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
at all. It uses /usr, and installs files where you'd expect
them to be found within that heirarchy more or less (although
it is a bit buggy in this regard currently, that'll be fixed
prior to X11R7's final release). The libraries, binaries,
fonts, config files, data files - everything is moving.
Along with this upstream X.Org change, there will be a number
of backward compatibility issues that we'll face, where we
may need to provide backward compatible symlinks for cases like
applications hard coding the path to X binaries instead of
using "which <appname>" and similar. We'll be keeping an
eye on such issues and considering where we should provide
compatibility links.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) A lot of existing Fedora Core, Fedora Extras and other 3rd
party packages currently install themselves into /usr/X11R6,
need to be updated to install themselves in a more
appropriate location under /usr, using %{_datadir} and
friends in their rpm specfiles. Volunteers are needed who
are willing to take on the task of reporting bugs against
the offending packages, and preferably also attaching
patches to fix the rpms.
2) A number of packages might have shell scripts, .desktop
files, or other things with hard coded paths to binaries
such as /usr/X11R6/bin/xterm, or to data files, or other
files traditionally installed under /usr/X11R6. Please
report bugs against these packages, and where possible,
change them to use "which <appname>" instead of hard
coding the path to the executable/file directly. In some
cases dynamic solution might not work, so hard code the
new path in that case unless there's another appropriate
solution apparent.
3) If you can personally think of any application or compat
problems that might occur when the changeover is made,
please report them to me via email in advance, so we can
try to find a solution sooner than later.
This message is being sent out to encourage community
involvement in the process, and to help weed out problems
sooner in the development cycle than later on, as there
is likely to be a fair amount of package churn, so we'd
like to get things in order far far in advance of
FC5test1.
Thanks in advance for any feedback, and also to any
volunteers who decide to help out.
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)

We will be finding/fixing anything obvious we find prior to
it hitting rawhide, however if we miss anything I'm sure that
we'll find out after it goes live in rawhide and everyone
suddenly becomes a volunteer. ;o)

Thanks again.
TTYL
Paul F. Johnson
2005-09-04 11:35:41 UTC
Permalink
Hi,
Post by Mike A. Harris
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)
Sorry for not replying to this, somehow the original version was chewed
and spat out into my spam bin.

I'm happy to help.

TTFN

Paul
--
"A lot of football success is in the mind. You must believe you are the
best and then make sure that you are. In my time at Liverpool we always
said we had the best two teams on Merseyside, Liverpool and Liverpool
Reserves." - Bill Shankly
Mike A. Harris
2005-09-04 12:42:12 UTC
Permalink
Post by Paul F. Johnson
Hi,
Post by Mike A. Harris
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)
Sorry for not replying to this, somehow the original version was chewed
and spat out into my spam bin.
I'm happy to help.
Seems like we both had a similar problem. ;o)
Mike A. Harris
2005-09-04 12:42:12 UTC
Permalink
Post by Paul F. Johnson
Hi,
Post by Mike A. Harris
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)
Sorry for not replying to this, somehow the original version was chewed
and spat out into my spam bin.
I'm happy to help.
Seems like we both had a similar problem. ;o)
Mike A. Harris
2005-09-04 12:23:24 UTC
Permalink
Post by Mike A. Harris
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)
We will be finding/fixing anything obvious we find prior to
it hitting rawhide, however if we miss anything I'm sure that
we'll find out after it goes live in rawhide and everyone
suddenly becomes a volunteer. ;o)
Ugh. It turns out that I have some rather major mail filtering
problems going on. 150Mb procmail.log to the rescue...

Word of advice: Do not use alpha version of "spambayes" spam
filtering software. It is horribly broken. I've now downgraded
to the 1.0.4 release and watching the procmail log more closely
now to try to catch failures.

A few people pointed out to me that people did in fact respond
to the thread, and I've acquired copies. I'll review them and
respond back to the list.

So.... Thanks very much to everyone who did respond, and my
apologies for missing things due to mail filtering quirks.

Now on to reading them...

TTYL
Paul F. Johnson
2005-09-04 11:35:41 UTC
Permalink
Hi,
Post by Mike A. Harris
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)
Sorry for not replying to this, somehow the original version was chewed
and spat out into my spam bin.

I'm happy to help.

TTFN

Paul
--
"A lot of football success is in the mind. You must believe you are the
best and then make sure that you are. In my time at Liverpool we always
said we had the best two teams on Merseyside, Liverpool and Liverpool
Reserves." - Bill Shankly
Mike A. Harris
2005-09-04 12:23:24 UTC
Permalink
Post by Mike A. Harris
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)
We will be finding/fixing anything obvious we find prior to
it hitting rawhide, however if we miss anything I'm sure that
we'll find out after it goes live in rawhide and everyone
suddenly becomes a volunteer. ;o)
Ugh. It turns out that I have some rather major mail filtering
problems going on. 150Mb procmail.log to the rescue...

Word of advice: Do not use alpha version of "spambayes" spam
filtering software. It is horribly broken. I've now downgraded
to the 1.0.4 release and watching the procmail log more closely
now to try to catch failures.

A few people pointed out to me that people did in fact respond
to the thread, and I've acquired copies. I'll review them and
respond back to the list.

So.... Thanks very much to everyone who did respond, and my
apologies for missing things due to mail filtering quirks.

Now on to reading them...

TTYL
Ignacio Vazquez-Abrams
2005-09-06 04:28:14 UTC
Permalink
I've gone ahead and created a tracker for the migration, with the alias
of X11R6-MIGRATE. Please make any existing or new migration entries
block this tracker.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167600
--
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050906/99b25837/attachment.bin
Mike A. Harris
2005-09-04 11:26:09 UTC
Permalink
Mike A. Harris wrote:
[SNIP]
Post by Mike A. Harris
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
X.Org X11 will no longer use the /usr/X11R6 directory hierarchy
at all. It uses /usr, and installs files where you'd expect
them to be found within that heirarchy more or less (although
it is a bit buggy in this regard currently, that'll be fixed
prior to X11R7's final release). The libraries, binaries,
fonts, config files, data files - everything is moving.
Along with this upstream X.Org change, there will be a number
of backward compatibility issues that we'll face, where we
may need to provide backward compatible symlinks for cases like
applications hard coding the path to X binaries instead of
using "which <appname>" and similar. We'll be keeping an
eye on such issues and considering where we should provide
compatibility links.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) A lot of existing Fedora Core, Fedora Extras and other 3rd
party packages currently install themselves into /usr/X11R6,
need to be updated to install themselves in a more
appropriate location under /usr, using %{_datadir} and
friends in their rpm specfiles. Volunteers are needed who
are willing to take on the task of reporting bugs against
the offending packages, and preferably also attaching
patches to fix the rpms.
2) A number of packages might have shell scripts, .desktop
files, or other things with hard coded paths to binaries
such as /usr/X11R6/bin/xterm, or to data files, or other
files traditionally installed under /usr/X11R6. Please
report bugs against these packages, and where possible,
change them to use "which <appname>" instead of hard
coding the path to the executable/file directly. In some
cases dynamic solution might not work, so hard code the
new path in that case unless there's another appropriate
solution apparent.
3) If you can personally think of any application or compat
problems that might occur when the changeover is made,
please report them to me via email in advance, so we can
try to find a solution sooner than later.
This message is being sent out to encourage community
involvement in the process, and to help weed out problems
sooner in the development cycle than later on, as there
is likely to be a fair amount of package churn, so we'd
like to get things in order far far in advance of
FC5test1.
Thanks in advance for any feedback, and also to any
volunteers who decide to help out.
At this time, I'd like to thank the large number of volunteers
who responded to this query (zero), as that will greatly help
to make sure everything works after modular X goes into
rawhide. ;o)

We will be finding/fixing anything obvious we find prior to
it hitting rawhide, however if we miss anything I'm sure that
we'll find out after it goes live in rawhide and everyone
suddenly becomes a volunteer. ;o)

Thanks again.
TTYL
Ignacio Vazquez-Abrams
2005-09-06 04:28:14 UTC
Permalink
I've gone ahead and created a tracker for the migration, with the alias
of X11R6-MIGRATE. Please make any existing or new migration entries
block this tracker.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167600
--
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050906/99b25837/attachment-0002.bin
Continue reading on narkive:
Loading...