https://bugzilla.redhat.com/show_bug.cgi?id=1187713 --- Comment #18 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to jiri vanek from comment #17) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #16) > > The patch to load libraries is wrong. It makes the jar file architecture > > dependent, > yes, intentionally > > > but it should not be. Just try loading from /usr/lib64, and then from > > /usr/lib. > > This will work on both 64 and 32 bit archs. > > Well - this patch is fedora only, and fedora do not support multilib jni > packages > (http://fedoraproject.org/wiki/Packaging: > Java#Packaging_JAR_files_that_use_JNI - uttermost end - ". Java packages > using JNI do not support multiarch installation." > > Although I see your point, I would rather stay with my approach - to fail > immediately if wrong arch is found. > > If you disagree, and insists, I will follow your opinion. I do disagree. It generates an unnecessary conflict (which is detected only during transaction check, which is nasty for users): $ sudo dnf install results/netty-tcnative-1.1.30-0.fc22.x86_64.rpm ... Error: Transaction check error: file /usr/lib/java/netty-tcnative/netty-tcnative.jar from install of netty-tcnative-1.1.30-0.fc22.x86_64 conflicts with file from package netty-tcnative-1.1.30-0.fc22.i686 file /usr/share/maven-metadata/netty-tcnative.xml from install of netty-tcnative-1.1.30-0.fc22.x86_64 conflicts with file from package netty-tcnative-1.1.30-0.fc22.i686 > > [!]: License file installed when any subpackage combination is installed. > > No license is installed with -javadocs. > > Eh... No license file does exists in whole project. Ah, OK. > > > > [!]: Package requires other packages for directories it uses. > > Note: No known owner of /usr/share/maven-poms/netty-tcnative, /usr/lib64 > > /netty-tcnative, /usr/lib/java/netty-tcnative > > [!]: Package must own all directories that it creates. > > Note: Directories without known owners: /usr/share/maven-poms/netty- > > tcnative, /usr/lib64/netty-tcnative, /usr/lib/java/netty-tcnative > > Those should be added. > > fixed (sorry, I thought mvn_install is handling those three) > > > ...snip... > > file > > from upstream, the packager SHOULD query upstream to include it. > > [!]: Final provides and requires are sane (see attachments). > > See comments below > > > > [x]: Fully versioned dependency in subpackages if applicable. > > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in netty- > > tcnative-javadoc > > Not needed. > > > > [?]: Package functions as described. > > The testclass runs fine on both x86_64 and i386 I wasn't trying to say that the package does not work, but only that I didn't test it :) > > [x]: Latest version is packaged. > > [x]: Package does not include license text files separate from upstream. > > [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. > > [-]: Description and summary sections in the package spec file contains > > translations for supported Non-English languages, if available. > > [?]: Package should compile and build into binary rpms on all supported > > architectures. > I have not tested arms... > > > I don't think it would actually build, because of the binary conflict. > > What do you mean?/Wy do you think so? I thought that it would detect the conflict between files. Apparently it does not, the check is only done for noarch packages. So the build is OK. > > Requires > > -------- > > netty-tcnative (rpmlib, GLIBC filtered): > > apr > > java-headless > > jpackage-utils > > libapr-1.so.0()(64bit) > > libc.so.6()(64bit) > > libcrypto.so.10()(64bit) > > libcrypto.so.10(OPENSSL_1.0.1)(64bit) > > libcrypto.so.10(OPENSSL_1.0.1_EC)(64bit) > > libcrypto.so.10(libcrypto.so.10)(64bit) > > libdl.so.2()(64bit) > > libpthread.so.0()(64bit) > > libssl.so.10()(64bit) > > libssl.so.10(libssl.so.10)(64bit) > > openssl > > This also seems unecessary. IIUC, only ssl libs are required, and that > > dependency is provided automatically. > Ok, I have removed (how had you found it?) It links to the library, but does not seems to call any binaries directly. > Requires: apr > Requires: openssl > But added > Requires: java-headless > Requires: jpackage-utils > (http://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires ?) I think they are added automatically because of the BR:maven-local, but adding them explicitly does not hurt. > > > > rtld(GNU_HASH) > > > > netty-tcnative-javadoc (rpmlib, GLIBC filtered): > > jpackage-utils > > This seems unnecessary. > This seems to be autoadded -javadoc should be noarch! I think it might go away when the package is noarch. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review