Description of problem: $ rpm -q --provides hadoop-common-native hadoop-common-native = 2.0.5-11.fc21 hadoop-common-native(x86-64) = 2.0.5-11.fc21 libhadoop.so.1.0.0()(64bit) The last provides - libhadoop.so.1.0.0()(64bit) - shouldn't be there. It is a private library outside the default library search path and nothing should link to it ever. These kinds of provides should be filtered out. Version-Release number of selected component (if applicable): hadoop-common-native-2.0.5-11.fc21.x86_64 Additional info: Add to specfile %filter_provides_in %{libdir}/%{name}/.*\.so.*$ %filter_setup PS: lintian complains about devel-file-in-non-devel-package also for hadoop-common-native: hadoop-common-native.x86_64: W: devel-file-in-non-devel-package /usr/lib64/hadoop/libhadoop.so Private libraries outside the default library search path should normally not have sonames. Is there a reason for this being libhadoop.so.1.0.0 instead of just libhadoop.so? If it was without soname like normal private libraries lintian would not complain. PS #2: Shouldn't hadoop-common have a Requires on hadoop-common-native?
Removed the provides and requires of libhadoop.so.1.0.0()(64bit) from the common-native package. The devel-file-in-non-devel-package also for hadoop-common-native is spurious. Neither rpmlint nor lintian (apparently) are able to recognize a library that is used through a JNI interface. The libhadoop library is called out to from the hadoop-common.jar via JNI, and part of that constraint is that the library must end in .so. So, the libhadoop.so must be in the common-native package for it to function properly. The hadoop-common-native package is optional. It provides native libraries for some functions, thus it can provide a speed increase, but the code has had compilation problems on non-intel architectures in my experience. You can run hadoop w/o the native libs.
hadoop-2.0.5-12.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/hadoop-2.0.5-12.fc20
I think you overdid the filtering a bit: %global __requires_exclude_from ^%{_libdir}/%{name}/.*$ %global __provides_exclude_from ^%{_libdir}/%{name}/.*$ The provides filtering is OK, but the requires filtering above filters out all requires generation from the jni module. I don't think that was what you wanted. The requires on the jni library itself (i.e. on the provides filtered out) is of course appropriate, but the rest of the requires should still be there I think. The following I think would be better: %global __requires_exclude ^libhadoop.so.*$ %global __provides_exclude_from ^%{_libdir}/%{name}/.*$ PS. I hope you don't mind that I file bugs on your hadoop package. It can not have been easy to prepare the packaging at all, with all those dependencies and versions. So I hope you take my comments as friendly hints to make a good work a tiny bit better rather than an enormous put-down.
(In reply to Robert Rati from comment #1) > The devel-file-in-non-devel-package also for hadoop-common-native is > spurious. Neither rpmlint nor lintian (apparently) are able to recognize a > library that is used through a JNI interface. The libhadoop library is > called out to from the hadoop-common.jar via JNI, and part of that > constraint is that the library must end in .so. So, the libhadoop.so must > be in the common-native package for it to function properly. I agree that the *.so symlink is a runtime dependency and should not be in a -devel package, since that would make the -devel package a runtime dependency, which would be bad. My point was that, normally, jni interface libraries are compiled without sonames and the library itself is named *.so. In this case there would be no need for a symlink and nothing for rpmlint to complain about. > The hadoop-common-native package is optional. It provides native libraries > for some functions, thus it can provide a speed increase, but the code has > had compilation problems on non-intel architectures in my experience. You > can run hadoop w/o the native libs. OK.
(In reply to Mattias Ellert from comment #4) > (In reply to Robert Rati from comment #1) > > The devel-file-in-non-devel-package also for hadoop-common-native is > > spurious. Neither rpmlint nor lintian (apparently) are able to recognize a > > library that is used through a JNI interface. The libhadoop library is > > called out to from the hadoop-common.jar via JNI, and part of that > > constraint is that the library must end in .so. So, the libhadoop.so must > > be in the common-native package for it to function properly. > > I agree that the *.so symlink is a runtime dependency and should not be in a > -devel package, since that would make the -devel package a runtime > dependency, which would be bad. > > My point was that, normally, jni interface libraries are compiled without > sonames and the library itself is named *.so. In this case there would be no > need for a symlink and nothing for rpmlint to complain about. Ah, I misunderstood your statement. I'm not sure if the libhadoop library can be used in a non-JNI type environment and thus there might be some benefit to the current approach. I just copy what upstream produces here but am not sure what their intention was in producing this setup. I have no problems naming the library to just an so, but it might be worthwhile to let hadoop get into fedora and see how it is used.
(In reply to Mattias Ellert from comment #3) > I think you overdid the filtering a bit: > > %global __requires_exclude_from ^%{_libdir}/%{name}/.*$ > %global __provides_exclude_from ^%{_libdir}/%{name}/.*$ > > The provides filtering is OK, but the requires filtering above filters out > all requires generation from the jni module. I don't think that was what you > wanted. The requires on the jni library itself (i.e. on the provides > filtered out) is of course appropriate, but the rest of the requires should > still be there I think. The following I think would be better: > > %global __requires_exclude ^libhadoop.so.*$ > %global __provides_exclude_from ^%{_libdir}/%{name}/.*$ I'll look into this the next time I spin a package. > PS. I hope you don't mind that I file bugs on your hadoop package. It can > not have been easy to prepare the packaging at all, with all those > dependencies and versions. So I hope you take my comments as friendly hints > to make a good work a tiny bit better rather than an enormous put-down. Not at all. Hadoop certainly has been a challenge, and as such I welcome areas to improve it or places I made mistakes.
Package hadoop-2.0.5-12.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hadoop-2.0.5-12.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18873/hadoop-2.0.5-12.fc20 then log in and leave karma (feedback).
(In reply to Robert Rati from comment #5) > I'm not sure if the libhadoop library > can be used in a non-JNI type environment and thus there might be some > benefit to the current approach. While it is possible for a library to be usable as both a JNI module and a shared library, I don't see that this is the case here. In order for the library to be usable as a shared library, there should be header files associated with it that declare the functions and classes in the library so that they can be used for development. No such header files exist in this case. On the other hand there are some header files installed by the hadoop-devel package (Pipes.hh, SerialUtils.hh, StringUtils.hh, TemplateFactory.hh) where the corresponding library is missing in the packaging. These headers declare functions and classes in the libhadooppipes and libhadooputils libraries. Without installing the libraries, the headers are not usable. So were these libraries supposed to be installed, or the headers not to be installed? The upstream build instructions seem to only build these libraries as static libraries though.
hadoop-2.0.5-12.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.