Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=889505 --- Comment #11 from Eric Radman <eradman@xxxxxxxxxxxxxxx> --- > one reviewer has told you not to package the .a and .la file, another > pointed out that the package would violate the static library > guidelines, but you've not commented on that yet. Fair point, I should have asking why he said this. Better to ask than to assume. And to your larger point, it wouldn't have hurt to start with a short list of questions about previous comments. I understand that the Fedora project does not want applications to be built with static libraries, but it didn't occur to me that users are not permitted to build their own utilities using cc -static. > Many things in the packaging guidelines are not in there just for fun, > but with the goal of avoiding packaging pitfalls. My tendency was to look at existing RPMs, but they're not always good templates to follow. > _Why_ is the static lib being built? Because it's useful. In some cases it's difficult to run utilities that are built on DSOs. The author of libkqueue agreed that we don't need to package the .a file, so I removed the static package. >> License: MIT and BSD > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text > > That's one of the early items on the following list: > https://fedoraproject.org/wiki/Packaging:ReviewGuidelines I added a COPYING file to the source and included it with %doc > > %{_configure} --prefix=%{_prefix} > > The %{_configure} macro expands to just "./configure", so using the > macro doesn't add any value. Better would be to add a comment to the > spec file that explains _why_ "./configure" is used. %{configure} breaks the build by setting --target to 'x86_64-redhat-linux-gnu' instead of 'linux', which changes the behavior of `uname`. The configure script needs to know the operating system type in order to build he right files (e.g src/solaris, src/linux) >> make install DESTDIR=$RPM_BUILD_ROOT LIBDIR=$RPM_BUILD_ROOT%{_libdir} >> MANDIR=$RPM_BUILD_ROOT%{_mandir} INCLUDEDIR=$RPM_BUILD_ROOT%{_includedir} > >Does it use DESTDIR at all? As a prefix for the "install" target? If so, that >raises the question why to override the other variables, too? Btw, there's the >%{make_install} macro these days, which saves some typing in the spec file. I think DESTDIR is used indirectly because the other variables (MANDIR, INCLUDEDIR) are based on it. You're right, we don't have to override these other variables. The only exception is LIBDIR which is set to $DESTDIR/usr/lib instead of $DESTDIR/usr/lib64. I'm not sure how to improve this. > > the base package which contains the man pages. > > That's the wrong package for them. They are development related. > Section 2 (system calls). ok, I moved the man page the devel package > > %{_includedir}/kqueue/sys/event.h > > The "unowned" directory issue is still present. Is the right way to do it? %dir %{_includedir}/kqueue %dir %{_includedir}/kqueue/sys > > %{_libdir}/libkqueue.so > > This file is included in the wrong package. Ok, moved libkqueue.so to then devel package > > %{_libdir}/pkgconfig/libkqueue.pc > > %{_libdir} is not substituted correctly in this file. It's hardcoded > to /usr/lib %here for x86_64 Are you saying that we should hard-code the path to /usr/lib/pkgconfig ? -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=awTjbUiuEA&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review