On Sat, 10 Jun 2006 01:03:09 -0700, Rick Stout wrote: > Hi all, > I need some help in clearing up some issues with the nx package. It > seems to have two bigger problems at this point, and I really don't know > what to do about either. > > First, nx *does not* work on x86_64, so it has an Excludearch: x86_64 in > the spec. This is fine for the arch exclusion, but there is a package > that depends on nx, freenx which is noarch (its just a bunch of > scripts), so the build reports show that freenx has a broken dependency > on x86_64. I believe this to be a packaging design bug. In my view it makes no sense to have a dependency "noarch -> arch-specific". The benefit of having freenx as noarch is negligible. Currently, it's listed as 59K only. The opposite is the "arch-specific -> noarch" dependency. You could have avoided this breakage in FE5 by building these packages for Fedora Extras Development first, using it as the testbed it's supposed to be. > What is the best way to handle this? Can I Excludearch: > x86_64 on a noarch package? No. ExcludeArch is about the set of build target architectures, but your BuildArch is "noarch". > How about a requires: wrapped in an ifnarch conditional? Think twice. Why does freenx depend on nx? Would it make sense to drop the dependency altogether? If not, freenx should become arch-specific, since it depends on an arch-specific package anyway. > Second, nx is based on XFree86 4.3.0. The backend components come from a > full X11 build, and require a number of adapted libraries from this > build. The library of most concern right now is libX11.so.6.2. Nx > installs this library in /usr/lib/NX/lib, then when any of the nx > components are called, a wrapper puts the NX/lib path in front of the ld > path for just that application, so as not to step on any of the other > libraries already on the system. The problem, which was not apparent > until now, is that yum thinks that nx provides a valid libX11.so.6 so > certain applications requiring this file may download nx and its > dependencies. How do I fix this? You need to add a filter to rpmbuild's soname dependency check script from within your spec file. > I feel that this could actually be > considered a deficiency in yum or rpm in that the file is not in the > standard library path, so it really isn't provided to the system. Any > input would be greatly appreciated in this. No. It's not Yum's or RPM's business to tell which paths are standard and which are not. Any package can install files to customise the run-time linker's search paths, and neither Yum or RPM can know about that at build-time. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
