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.
Mike A. Harris wrote:
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.
some apps have hardcoded -L/usr/X11R6/lib in there makefiles (which allready make problems on multilib systems)
dragoran wrote :
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
dragoran wrote:
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
On Tue, 30 Aug 2005, Mike A. Harris wrote:
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.
# ln -s /usr /usr/X11R6
and forget about this problem...
Peter Lemenkov wrote :
# 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
On Wed, 2005-08-31 at 12:08 +0200, Matthias Saou wrote:
Peter Lemenkov wrote :
# 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 wrote:
On Wed, 2005-08-31 at 12:08 +0200, Matthias Saou wrote:
Peter Lemenkov wrote :
# 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
Hans de Goede wrote :
IOW: 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
On Wed, 2005-08-31 at 12:35 +0200, Hans de Goede wrote:
"(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
I get this:
[rodd@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.
Hi.
Rodd Clarkson rodd@clarkson.id.au wrote:
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.
ons, 31,.08.2005 kl. 13.25 +0200, skrev Ralf Ertzinger:
Hi.
Rodd Clarkson rodd@clarkson.id.au wrote:
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
On 8/31/05, Kjartan Maraas kmaraas@broadpark.no wrote:
My additions are:
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
On Wed, 2005-08-31 at 10:05 -0400, Jeff Spaleta wrote:
On 8/31/05, Kjartan Maraas kmaraas@broadpark.no wrote:
My additions are:
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
Ralf Ertzinger wrote:
Hi.
Rodd Clarkson rodd@clarkson.id.au wrote:
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.
Rodd Clarkson wrote :
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
Rodd Clarkson wrote:
[rodd@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
Hans de Goede wrote:
"(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.
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)
Peter Lemenkov wrote:
On Tue, 30 Aug 2005, Mike A. Harris wrote:
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.
# 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 wrote: [SNIP]
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:
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.
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.
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
Hi,
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
Paul F. Johnson wrote:
Hi,
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 wrote:
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
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