Не собирается новый syslog-ng (3.7). В спеке файл описывается так: %python_sitelibdir_noarch/syslogng-1.0-py2.7.egg-info При сборке не проходит проверка для x86_64 http://git.altlinux.org/tasks/165052/logs/events.1.1.log /.out/syslog-ng-python-3.7.3-alt1.x86_64.rpm: invalid x86_64 python module path: /usr/lib/python2.7/site-packages/syslogng-1.0-py2.7.egg-info sisyphus_check: check-python ERROR: python modules packaging violation hsh-rebuild: pkg.tar: sisyphus_check failed.
Ваше мнение о том, что можно пропускать внутри /usr/lib/ в x86_64 пакете? https://lists.altlinux.org/pipermail/devel/2016-May/201463.html : Может быть, в sisyphus_check недостаточно разумная проверка?.. Когда её писали, не знали про существование .egg-info? Там на x86_64 сначала считаются плохими все файлы в /usr/lib/, потом это отменяется для .py[co] (потому что считается, что они архитектурно-независимы и имеют права лежат в общем месте). А .egg-info забыто? Разумно ли добавить? А что-то ещё тогда не нужно ли тоже добавить? Там и просто всякие README могут лежать. Хотелось бы, чтобы те, кто практикуют упаковку питона, поделились мыслями на этот счёт (ещё лучше -- вместе с патчами на sisyphus_check, если такие изменения оправданы). (Возможно, часть случаев, с которыми я сейчас массово борюсь, пряча их -- mv в spec-ах из /usr/lib в /usr/lib64, объясняется тем, что мейнтейнеры столкнулись с этой проверкой? У меня ещё есть подозрение, что всякие namespace-ы для чего-то вроде zope.чего-то-там не заработают, если они окажутся в разных физических директориях. Это было бы объяснением части случаев.) local bad_dirs= noarch_pattern= case "$rpm_arch" in noarch|i?86|pentium*|athlon*) bad_dirs='/usr/lib64/python[23]([.][0-9])?/site-packages/' ;; x86_64|amd64) noarch_pattern='^d[^ ]+ /usr/lib/python[23]([.][0-9])?/site-packages/|^-[^ ]+ /usr/lib/python[23]([.][0-9])?/site-packages/.*\.py([co])?$' bad_dirs='/usr/lib/python[23]([.][0-9])?/site-packages/' ;; esac local bad_files= if [ -n "$bad_dirs" ]; then bad_files="$(printf %s "$rpm_perms_filenames" | egrep "^[^ ]+ $bad_dirs" ||:)" fi if [ -n "$bad_files" -a -n "$noarch_pattern" ]; then bad_files="$(printf %s "$bad_files" | egrep -v "$noarch_pattern" ||:)" fi if [ -n "$bad_files" ]; then bad_files="$(printf %s "$bad_files" |cut -d' ' -f2-)" FileError "invalid $rpm_arch python module path: $(oneliner "$bad_files" |fmt -w 128 |head -n1)" "$f" rc=1 fi
(In reply to comment #1) > Ваше мнение о том, что можно пропускать внутри /usr/lib/ в x86_64 пакете? Текстовые файлы, наверное. Но вот как их корректно определять... Если us-ascii, то понятно, но если начинаются национальные кодировки, или uft8, то могут, наверное, возникнуть проблемы. > Хотелось бы, чтобы те, кто практикуют упаковку питона, поделились мыслями > на этот счёт (ещё лучше -- вместе с патчами на sisyphus_check, если такие > изменения оправданы). Честно говоря, я пытаюсь паковать компоненты пакетов на Питоне только тогда, когда они попападаются. У упомянутого syslog-ng 3.7 таковой компонент просто появился, а нужен ли он, я не знаю. Мне он пока, думаю, не очень нужен, хотя, вроде бы, это отладочный компонент для syslog-ng.
(In reply to comment #2) > (In reply to comment #1) > > > Ваше мнение о том, что можно пропускать внутри /usr/lib/ в x86_64 пакете? > > Хотелось бы, чтобы те, кто практикуют упаковку питона, поделились мыслями > > на этот счёт (ещё лучше -- вместе с патчами на sisyphus_check, если такие > > изменения оправданы). > > Честно говоря, я пытаюсь паковать компоненты пакетов на Питоне только тогда, > когда они попападаются. У упомянутого syslog-ng 3.7 таковой компонент просто > появился, а нужен ли он, я не знаю. Мне он пока, думаю, не очень нужен, хотя, > вроде бы, это отладочный компонент для syslog-ng. Пока policy не найдено, которое бы разрешило такие файлы, могу предложить запаковать всю питоновскую часть в настоящий noarch пакет (python?-module-NNNN). Вроде тогда честно и понятно: noarch он и есть noacrh. (Это возможно. Например, [http://git.altlinux.org/gears/e/emacs24.git?p=emacs24.git;a=blob;f=.gear/emacs.spec;h=ac103c9f93e228e6a8fea17b2787e3ae2220ddc6;hb=HEAD#l230 emacs24-el] с Emacs Lisp собирается как noarch-подпакет вместе с другими архитектурно-зависимыми пакетами, в т.ч главным, из одного спека.) Если главный пакет архитектурно-зависимый, придётся использовать %python{,3}_sitelibdir_noarch. (А если главный -- noarch, макрос переключился бы сам.) А, ну да. Это я лишнее пишу, у Вас уже так сделано.
(In reply to comment #3) > могу предложить запаковать всю питоновскую часть в настоящий noarch пакет > (python?-module-NNNN). Вроде тогда честно и понятно: noarch он и есть noacrh. /.out/python2.7-module-syslog-ng-debuggercli-3.7.3-alt1.noarch.rpm: package NAME should start with the "python-module-" prefix sisyphus_check: check-python ERROR: python modules packaging violation Решили python и python3 делать ? В общем, собралось с noacrh python-module-syslog-ng-debuggercli, отправил в репозиторий.
(In reply to comment #4) > (In reply to comment #3) > > > могу предложить запаковать всю питоновскую часть в настоящий noarch пакет > > (python?-module-NNNN). Вроде тогда честно и понятно: noarch он и есть noacrh. > > /.out/python2.7-module-syslog-ng-debuggercli-3.7.3-alt1.noarch.rpm: package > NAME should start with the "python-module-" prefix > sisyphus_check: check-python ERROR: python modules packaging violation > > Решили python и python3 делать ? Так сложилось (довольно давно). > В общем, собралось с noacrh python-module-syslog-ng-debuggercli, отправил в > репозиторий. Хорошо!
