ALT Linux Bugzilla – #32133

Ваше мнение о том, что можно пропускать внутри /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, отправил в
> репозиторий.

Хорошо!

Проверка актуальности: актуально. В sisyphus_check 0.8.71 (sisyphus_check.d/220-check-python:111) noarch_pattern для x86_64 по-прежнему пропускает в /usr/lib/python*/site-packages/ только каталоги и файлы *.py, *.pyc, *.pyo; текстовые *.egg-info и *.dist-info считаются ошибкой, обход — только отдельный noarch-подпакет.