Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=226342
--- Comment #10 from Dave Malcolm dmalcolm@redhat.com 2010-01-26 18:53:18 EST --- (In reply to comment #8)
Thanks for your work on this.
I did a big reworking of the devel/python.spec last night; mostly to eliminate embedded copies of library sources; to ensure safety doing this I replaced the "dynfiles" code with an explicit list of the compiled modules in the payload (as a "safety net" to trap if modules went away).
I'm sorry about my lack of response on the review so far; I'm somewhat doomed with another issue right now :(
2.6.4-12.fc13 is building as: http://koji.fedoraproject.org/koji/taskinfo?taskID=1946933 and contains some fixes as follows:
* Tue Jan 26 2010 David Malcolm dmalcolm@redhat.com - 2.6.4-12 - Address some of the issues identified in package review (bug 226342): - update libs requirement on base package to use %%{name} for consistency's sake - convert from backticks to $() syntax throughout - wrap value of LD_LIBRARY_PATH in quotes - convert "/usr/bin/find" requirement to "findutils" - remove trailing periods from summaries of -devel and -tools subpackages - fix spelling mistake in description of -test subpackage - convert usage of $$RPM_BUILD_ROOT to %%{buildroot} throughout, for stylistic consistency - supply dirmode arguments to defattr directives
Further comments inline:
- mostly missing state of the patches w.r.t. upstream
Patch0: python-2.6-config.patch Patch1: Python-2.2.1-pydocnogui.patch
https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_...
Agreed; this is the biggest issue for me with the spec as it stands. I hope to address this when other things calm down.
- inconsistency in sub-packages "Requires" field:
- python-libs : Requires: %{python} = %{version}-%{release}
- python-tools: Requires: %{name} = %{version}-%{release}
in case it's expected to be %{python} -eq %{name} I'd prefer to land on %{name} here.
Fixed in 2.6.4-12.fc13
- inconsistency in patching
%patch6 -p1 -b .plural %patch7 -p1
Still TODO, I'm afraid. My preference is to use -b for C code, and omit it for .py code (to avoid accidentally shipping the backups in the payload).
- old-school exec, back-ticks are BASH specific and non-POSIX, even in Python
are now discouraged
topdir=`pwd` -> topdir=$(pwd)
I've updated these throughout the specfile to use $() in 2.6.4-12.fc13
- missing _"_ should cover LD_LIBRARY_PATH's value
- LD_LIBRARY_PATH=$topdir $topdir/python Tools/scripts/pathfix.py -i
"%{_bindir}/env python%{pybasever}" .
- LD_LIBRARY_PATH=$topdir PATH=$PATH:$topdir make -s OPT="$CFLAGS"
%{?_smp_mflags}
I've updated these two so to: LD_LIBRARY_PATH="$topdir" in 2.6.4-12.fc13 - is this correct?
- make install DESTDIR=$RPM_BUILD_ROOT
What's the issue here?
- from what is this preventing? Considering that this is the only occurrence.
[ -d $RPM_BUILD_ROOT ] && rm -fr $RPM_BUILD_ROOT ^^^^^^^^^^^^^^^^^^^^^^
Changed to "rm -rf $RPM_BUILD_ROOT" in 2.6.4-12.fc13 as per packaging guidelines.
- using path-based BR is discouraged /usr/bin/find, use "findutils" better, but
note, that are listed in packages not necessary to be pulled to BR's https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions and thus always expected to be present.
Changed to "findutils" in 2.6.4-12.fc13
- BuildRoot is non-standard, use one of this ones:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Already changed to be the 2nd one on the list
- is this hard-coded "/usr" necessary?
mkdir -p $RPM_BUILD_ROOT/usr $RPM_BUILD_ROOT%{_mandir}
->
mkdir -p $RPM_BUILD_ROOT%{_prefix} $RPM_BUILD_ROOT%{_mandir}
Fixed in 2.6.4-12.fc13
- don't mix variable and macro style (e.g. $RPM_BUILD_ROOT -> %{buildroot})
https://fedoraproject.org/wiki/Packaging:Guidelines#Using_.25.7Bbuildroot.7D...
Changed $RPM_BUILD_ROOT -> %{buildroot} in 2.6.4-12.fc13
- old-school defattr
%defattr(-, root, root) -> %defattr(-,root,root,-)
Fixed in 2.6.4-12.fc13
be consistent with
%dir %{_libdir}/python%{pybasever} %dir %{_libdir}/python%{pybasever}/site-packages
where when %{_prefix} is changed then %{_libdir} is changed too:
""" %if "%{_lib}" == "lib64" %attr(0755,root,root) %dir /usr/lib/python%{pybasever} %attr(0755,root,root) %dir /usr/lib/python%{pybasever}/site-packages %endif """
->
""" %if "%{_lib}" == "lib64" %dir %{_prefix}/lib/python%{pybasever} %dir %{_prefix}/lib/python%{pybasever}/site-packages %endif """
Already fixed
- hard-coded includedir
/usr/include/* -> %{_includedir}/%{name}%{pybasever}
Already fixed
- %defattr(-,root,root,755) -> %defattr(-,root,root,-)
Which subpackages?
- RPMLINT:
- python.x86_64: W: obsolete-not-provided python-elementtree
python-elementtree still present in F-9 and devel
- python.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/python
2.6/lib-dynload/_sqlite3.so ['/usr/lib64']
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
- python.x86_64: E: non-standard-executable-perm /usr/lib64/python2
.6/lib-dynload/_ssl.so 0555
[and a lot of others] should be 0755?
- python.x86_64: E: script-without-shebang /usr/lib64/python2.6/run
py.py
Add shebang, or remove exec perm.
I haven't yet looked into the ones above. RPath issue is possibly already fixed.
- python-devel.x86_64: W: summary-ended-with-dot The libraries and
header files needed for Python development.
- python-tools.x86_64: W: summary-ended-with-dot A collection of de
velopment tools included with Python.
Fix, please.
Fixed in 2.6.4-12.fc13
- python-test.x86_64: W: spelling-error-in-description pacakge pack
age
ditto
Fixed in 2.6.4-12.fc13
- python-test.x86_64: W: no-documentation
Ignore, perhaps...
- python-test.x86_64: E: non-executable-script /usr/lib64/python2.6
/test/test_multibytecodec_support.py 0644
Add 0755 perms, or remove shebang.
- python-test.x86_64: E: zero-length /usr/lib64/python2.6/test/null
cert.pem
Is it necessary for the test?
- python-test.x86_64: E: wrong-script-interpreter /usr/lib64/python
2.6/test/test_pep263.py "-*-"
rpmlint is confused here because of the leading _!_, which is hardly necessary there, MacCVS should be fixed, not that file.
- python-test.x86_64: E: wrong-script-end-of-line-encoding /usr/lib
64/python2.6/test/test_pep263.py
- python-tools.x86_64: W: devel-file-in-non-devel-package /usr/lib6
4/python2.6/Demo/embed/demo.c
Probably not necessary to create python-tools-devel for two tests/4 .c files.
I haven't yet looked at the ones above.
Thanks again for your review work; sorry for delay in resolving the issues you identified.