Bug 26728

У меня были такие пакеты, заталкивание файлов *.py* в /usr/lib64/... решает проблему.

(В ответ на комментарий №1)
> У меня были такие пакеты, заталкивание файлов *.py* в /usr/lib64/... решает
> проблему.

это руками нужно делать, а хочется пакет собирать роботом :(
вопрос в том, что проблема искусственная, и создана некорректной реализацией самой указанной проверки.
Ведь файлы установлены корректно, это же не .so в /usr/lib.

Как отличить файлы, легально помещенные в /usr/lib/python2.7/, от файлов, помещенных туда по ошибке вместо /usr/lib64/python2.7/ ?

"Как отличить файлы, легально помещенные в /usr/lib/python2.7/, от файлов,
помещенных туда по ошибке вместо /usr/lib64/python2.7/ ?"

Мне тоже в голову ничего не идёт. На глаз можно, а вот робот вряд ли справится.

по расширению.
*.py, 
*.pyo, 
*.pyc, 
легальные,
все остальное -- нелегально

Разве *.pyo легален уже? :)

(В ответ на комментарий №5)
> по расширению. *.py, *.pyo, *.pyc, легальные,
> все остальное -- нелегально

или, вместо исключения на noarch files, добавить правило на отсутствие blobs
`file` !~ / ELF /: 

в крайнем случае правило на рсширение. почти все блобы - *.so,
но в rpmquery -l -p python-module-* 
попался /usr/lib64/python2.7/site-packages/Ft/Lib/DistExt/stubmain.exe

(В ответ на комментарий №6)
> Разве *.pyo легален уже? :)

Чесно говоря, не знаю, не понимаю.
Немного офтопик, про *.pyo, но хотелось бы разобраться.
я хочу научить робота корректно конвертировать python-* модули,
но наше текущее python policy непонятно где и какое.

Похоже, до сих пор никому это полиси так и не понадобилось сильно, что до сих пор
его и не существует ;)

(В ответ на комментарий №8)
> > Разве *.pyo легален уже? :)
> Чесно говоря, не знаю, не понимаю.
> Немного офтопик, про *.pyo, но хотелось бы разобраться.
> я хочу научить робота корректно конвертировать python-* модули,
> но наше текущее python policy непонятно где и какое.

т.е. приложение установило *.py файл. 
1) надо ли этот файл компилировать на стадии install?
2) если надо, то кто это делает штатно?
3) что из откомпилированного упаковывать?

думаю, что тема с *.pyo/*.pyc несколько офтопик в этом баге, 
стоит наверное в devel@ перенести.

(В ответ на комментарий №9)
> Похоже, до сих пор никому это полиси так и не понадобилось сильно, что до сих
> пор его и не существует ;)

вот народ вроде меня и пакует что попало, как попало, где попало, 
потому что нет полиси, которое его бы просвещало.
например, я бы с удовольствием узнал бы, какими граблями чревата упаковка *.pyc.

(В ответ на комментарий №10)
> т.е. приложение установило *.py файл. 
> 1) надо ли этот файл компилировать на стадии install?
> 2) если надо, то кто это делает штатно?
> 3) что из откомпилированного упаковывать?

на самом деле, очень полезно было бы обсудить, понять и решить.
те же *.pyc файлы. если с ними грабли --
надо их удалять принудительно еще на стадии %install в brp-fix=python.

"вот народ вроде меня и пакует что попало, как попало, где попало, 
потому что нет полиси"

Ну есть драфт, лично я им руководствуюсь. Писал не я, и там многое, наверно, уже поменять надо. Вот кто бы взялся за это...

PS. *.pyc ничем не чревато, в отличие от *.pyo (хотя я не на 100% уверен, что это так, глядя на python-module-pexpect).

"т.е. приложение установило *.py файл. 
1) надо ли этот файл компилировать на стадии install?"

Не надо, оно само после verify-elf компилируется.

(В ответ на комментарий №3)
> Как отличить файлы, легально помещенные в /usr/lib/python2.7/, от файлов,
> помещенных туда по ошибке вместо /usr/lib64/python2.7/ ?

можно ослабить проверку до `file $1` not match ' ELF '

(В ответ на комментарий №14)
> "т.е. приложение установило *.py файл. 
> 1) надо ли этот файл компилировать на стадии install?"
> Не надо, оно само после verify-elf компилируется.
спасибо, дальше разбираемся,
надо ли паковать 
1) *.pyo файлы
2) *.pyс файлы
?

В случае noarch *.pyo можно не паковать, для верности. Но лучше пусть выскажутся более просвещённые.

(В ответ на комментарий №17)
> В случае noarch *.pyo можно не паковать, для верности. Но лучше пусть
> выскажутся более просвещённые.

надо бы понять и разобраться - там много тонкостей.
я вот интересные грабли вытоптал.
когда-то я в hplip паковал только *.py файлы.
а некоторые пользователи в каких-то ситуациях пускали hplip-tools от рута.
при этом от рута создавали *.py[oc] файлы. Потом обновлялись и у них ничего не работало.
стал паковать все, чтобы такого не повторилось.

по поводу *.pyc / *.pyo и python-policy это отдельная тема,
не связанная напрямую с данным багом.

Данный баг о том, что sisyphus_check превышает свои полномочия, запрещая 
вместе с патологическими случаями и вполне разумную политику упаковки.
Более того, эта же проблема вылезла и в libsmbios, и как оказалось,
этот пакет родом из SuSE Build Factory. т.е. указанная схема упаковки 
(с раздельными noarch и arch частями) - это не выдумки федоры,
а распространенная дистрибутивная практика.

предлагаю ослабить проверку до проверки на отсутствие blobs,
т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /.

Дмитрий, если дадите добро, готов подготовить патч.

(In reply to comment #19)
> предлагаю ослабить проверку до проверки на отсутствие blobs,
> т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /.

как вы себе представляете применение file(1) в sisyphus_check?

2viy: PYTHONDONTWRITEBYTECODE=yes ?

(В ответ на комментарий №20)
> (In reply to comment #19)
> > предлагаю ослабить проверку до проверки на отсутствие blobs,
> > т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /.
> как вы себе представляете применение file(1) в sisyphus_check?

Да, стормозил. Перепутал с repocop :)
тогда по расширениям -- разрешить *.py *.pyo *.pyc файлы

(В ответ на комментарий №21)
> 2viy: PYTHONDONTWRITEBYTECODE=yes ?

Спасибо! буду знать.

Вообще хорошо бы обновить полиси по питону...
пока руки не доходят сесть и разобраться.
не  так часто с питоном сталкиваюсь.

(In reply to comment #22)
> (В ответ на комментарий №20)
> > (In reply to comment #19)
> > > предлагаю ослабить проверку до проверки на отсутствие blobs,
> > > т. е. для этих файлов в выводе file(1) не должно быть строки / ELF /.
> > как вы себе представляете применение file(1) в sisyphus_check?
> 
> Да, стормозил. Перепутал с repocop :)
> тогда по расширениям -- разрешить *.py *.pyo *.pyc файлы

Хорошо.

Просьба каким-нибудь образом передать мне исходный код какого-нибудь пакета, на котором это изменение можно было бы проверить.

Created attachment 5268 [details]
python-module-libhocr

Created attachment 5269 [details]
python-module-libsmbios

прикладываю src.rpm пакеты

sisyphus_check-0.8.29-alt1 -> sisyphus:

* Tue Dec 20 2011 Dmitry V. Levin <ldv@altlinux> 0.8.29-alt1
- 220-check-python: allow packaging of *.py* files in the
  arch-independent site-packages directory on x86-64 (closes: #26728).

(In reply to comment #25)
> Created an attachment (id=5268) [details]
> python-module-libhocr

Должен признать, что с целью тестирования я был вынужден увидеть этот libhocr.spec, и он пробудил во мне самые отвратительные чувства.

(В ответ на комментарий №28)
Спасибо!
> Должен признать, что с целью тестирования я был вынужден увидеть этот
> libhocr.spec, и он пробудил во мне самые отвратительные чувства.
я в devel@ поднял эту тему.

еще в сборочнице надо обновить:
http://git.altlinux.org/tasks/60714/logs/events.1.1.log
2011-Dec-21 00:06:17 :: [x86_64] #100 libhocr-0.10.17-alt1_9.src.rpm: build OK
x86_64/rpms/python-module-libhocr-0.10.17-alt1_9.x86_64.rpm: invalid x86_64 python module path: /usr/lib/python2.7/site-packages/hocr.py /usr/lib/python2.7/site-packages/hocr.pyc /usr/lib/python2.7/site-packages/hocr.pyo
sisyphus_check: check-python ERROR: python modules packaging violation
2011-Dec-21 00:06:21 :: #100: libhocr-0.10.17-alt1_9.src.rpm: sisyphus_check FAILED

Обновил.