Здравствуйте! Возвращаясь к вопросу про нестандартные пакеты с питоновскими модулями и характером .so в них: Чтобы голову не ломать, есть ли зависимость у пакета на ABI питона (в виде .so, который будет грузиться в /usr/bin/python3 или линковаться с libpython3), сейчас rpm-build-python3 ставит такую зависимость, если в составе пакета есть .so-файл, про который is_python3_path из /usr/lib/rpm/python3.req.files говорит да. Можно сказать, сделано для перестраховки. Собственно код: is_python3_path() { local f p f="$1"; shift for p in ${RPM_PYTHON3_PATH-} ${RPM_PYTHON3_COMPILE_INCLUDE-}; do if [ -z "${f##${RPM_BUILD_ROOT-}${p%%/}/*}" ]; then return 0 fi done return 1 } ... *ELF*" shared object"*) if is_python3_path "$f"; then echo "$f" fi continue ;; ... (Им же в verify_elf делается LD_PRELOAD, чтобы не засорять лог сборки несущественными сообщениями об undefined symbols. Для случая, когда такая библиотека кладётся в системные /usr/lib/, есть макрос %requires_python_ABI_for_files; пример -- пакет boost или python3-module-pygobject или python-module-pygobject3. Иначе пакет не пропустят.) Под новое правило уже успел попасться свежесобранный gedit. А в случае свежей сборки ещё попадётся некоторое количество пакетов. Например, (сейчас проверил) rhythmbox и totem. Но они пока не успели попасться под новое правило. Так что вместе с python3-3.5 мы их пересобирать не вынуждены по формальным причинам. Так что на усмотрение мейнтейнеров: если нужно, пересоберите потом. Если такой зависимости на питоновское ABI реально нет, можно уточнить %_python3_compile_include (чтобы она формально не появлялась). %_python3_compile_include стандартное ведёт в /usr/lib{,64}/python3/site-packages/. Есть пакеты с нестандартным местом, куда кладутся питоновские модули-плагины (например, упомянутые выше gedit, rhythmbox, totem); но там плагины необязательно питоновские, так что уточнение %_python3_compile_include неплохой выход, по-моему. On Wed, 9 Mar 2016, Ivan Zakharyaschev wrote: > On Fri, 4 Mar 2016, Ivan Zakharyaschev wrote: > >> Если отделить множество пакетов, в которых есть .so (все остальные, мы >> предполагаем, не линкуются с libpython при работе и их можно, переложив и >> обработав автогенератором зависимостей, оставить и они будут работать с >> python3-3.5), то можно насчитать 250 пакетов (которые будут пересобираться >> одновременно в одном задании с новой версией python3, на втором этапе): >> >> $ ./print-section_unmets events.5.1.log | cut -d'#' --fields=1 | sort -u | >> join -t$'\t' -2 2 - <(sort -t$'\t' -k2 < >> /ALT/Sisyphus/x86_64/base/contents_index) | egrep '\.so($|\.)' | cut >> -d$'\t' --fields=1 | uniq | wc -l >> 259 > >> Напишу в конце список. > > Сейчас, когда в целом всё подготовлено для пересборки с более точными и во > множестве пакетов более слабыми зависимостями, хочется разобраться вот в > таком вопросе про эти .so: > > python3.req.py получает на рассмотрение только .so по шаблону */python3*/*.so > > Я же выше на всякий случай искал все .so в пакетах. > > Проверим несовпаденя. > > Из этого списка файлов .so и пакетов уберём сначала те, в которых есть пути в > site-packages (чтобы сразу много убрать из рассмотрения). > (На самом деле зря. Надо было всё проверять.) > > Оставшееся пакеты проверим на то, чтобы у них либо была зависимость на > libpython, либо файлы, подпадающие под этот шаблон */python3*/*.so, который > будет вызывать зависимость на python3.3-ABI. > > Если ни того, ни другого нет, гарантирующего привязку к версии питона, > обратим внимание на этот пакет (внизу в скрипте напротив него будет пусто): > > $ for p in $(./print-section_unmets events.5.1.log | cut -d'#' --fields=1 | > sort -u | fgrep -v -x $'LibreOffice-common\npython3-test' | join -t$'\t' -2 2 > - <(sort -t$'\t' -k2 < /ALT/Sisyphus/x86_64/base/contents_index) | egrep > '\.so($|\.)' | egrep -v '/usr/lib(|64)/python3\.3/site-packages' | cut > --fields=1 | sort -u ); do echo -n "$p: "; f="$(./getRPMForPkgnames.sh > "$p")"; { rpm -qp "$f" --requires | fgrep libpython; } || { rpm -qp "$f" -l | > egrep '/python3.*/.*\.so$' | xargs echo; } || echo '???'; done > boost-python3-devel: > engrid: > eog-plugins: > gedit: > gedit-plugins: > gitg: > gnome-builder: libpython3.3m.so.1.0()(64bit) >= > set:ojiZhTKylwsDM9yCCTgb9vw6pALZpBUm7xVLRPiAeqW9H1Y9aUJ8ym1Uy0FARIu66V2GO8XU0EMGpshMY2Y4hRYR0 > gnome-music: > gnome-shell: > libgit2-glib: > libnumpy-py3-devel: > /usr/lib64/python3.3/site-packages/numpy/core/lib/libnpymath3.so > libpeas-python3-loader: libpython3.3m.so.1.0()(64bit) >= > set:oiqVkAUsy8ACvxk2p2DofRKiVrEBAfEh67iZFcdYqiCKsR9XTWp9i3GH8LAXnhwZhuniyiZbI3uAfVMTy0lOqHDNx1Qp5se8LlOeeETCrpeP51oB1pshw8LsIR4iR > libpyside-qt4-py3: libpython3.3m.so.1.0()(64bit) >= > set:oha0ppmlcyDVIRMBvVYf4Rm8icJ22i94FZkJ8Ye46OjpH0hyzSt9zRHY0WEoaHqMEUVnD1YRTcPWBrabQi0Su0YQ6r1ZK80wWscDkKx991pvmeo4sWj0x4or4dslC5fc0l9mDVjUw7IJN5mtmi7xsX9TxGI7myC1qzNsuItJqlAYwC1XNqENXTzk9qs95 > libshiboken-py3: libpython3.3m.so.1.0()(64bit) >= > set:ohEBjfqtP4bZym5H659cQQdkFKFW295y81ktTswkAwbTNB1Qygt8Z7dE6cKJ9FLYZfoe1kWZ5VNDwbxRDeFTQR4nYY7iysOpV2VGVWYuIMjvnvBn3ZdWNiA2SBm2kehAiFoYG1rkK30Iz38h3j62gtZAC13wgItp53ZL8vmt778QY9tss2MRUAXglS3bhzlkMVtMNwThxLb0VHFk4z1actCqM817rZ043vgi9q0 > pitivi: > python3-module-CVC4: /usr/lib64/python3.3/site-packages/_CVC4.so > python3-module-pygobject: /usr/lib64/python3.3/site-packages/glib/_glib.so > /usr/lib64/python3.3/site-packages/gobject/_gobject.so > python3-module-pygobject-devel: > totem-plugins: > weechat-plugin-python: libpython3.3m.so.1.0()(64bit) >= > set:oipC2yNcWvlG7aFZp9VWLsm3CohA4KmZjOlyrNPA8gsq8sc4suj8zRUNKVfK0Qa04r1oZhf0dxsJHZrXfahnOvhgq1hrTBZisDZJ > > (добавил ещё потом проверку на 'python3 =', список не изменился.) > > Вот вопрос: если у python сменится версия с 3.3 на 3.5, будут ли они > работать? Или привязка к версии питона как-то реализована в их зависимостях? > > Вопрос про те, у которых пусто; *-devel можно пропустить: > > engrid > eog-plugins > gedit > gedit-plugins > gitg > gnome-music > gnome-shell > libgit2-glib > pitivi > totem-plugins > > Если есть связь с версией питона, как её можно было бы обнаруживать? -- Best regards, Ivan