Re: [devel] rpm-build-python-0.34-alt1 regression

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3447 bytes --]

On Mon, Jun 08, 2009 at 06:41:36PM +0800, Terechkov Evgenii wrote:
> > > > Пересборка python-module-imaging-1.1.6-alt3 в среде с
> > > > rpm-build-python-0.33.2-alt1 даёт Provides: python2.5(PIL),
> > > > python2.5(PIL.*) в подпакете python-module-imaging. Я думаю, это
> > > > регрессия в rpm-build-python.
> > Я посмотрел эту проблему, но пока проблемы особо не понял.
> > $ hsh-install 'python2.5(PIL)'
> > <13>Jun  8 07:25:23 rpmi: python-module-imaging-devel-1.1.6-alt2 installed
> > $ hsh-run -- python -c 'import PIL'
> > Traceback (most recent call last):
> >   File "<string>", line 1, in <module>
> > ImportError: No module named PIL
> > $ 
> > Пространство питоновских зависимостей -- это имена модулей, которые
> > могут быть импортированы с помощью инструкции import.
> > Другими словами, если пакет предоставляет зависимость 'python(foo)',
> > то это должно значить, что будет работать команда python -c 'import foo'.
> 
> Это ошибка в пакете python-module-imaging: файл PIL.pth упакован в
> подпакет devel. Эту ошибку swi@ пытается починить сборкой alt3. Но
> натыкается на то, что пакет, содержащий и файл PIL.pth и
> соответствующую директорию site-packages/PIL/ (т.е. где python -c
> "import PIL" должно уже работать) таковую зависимость не предоставяет.
> 
> И это уже вторая ошибка. Я так понимаю, что сборка alt2 python2.5(PIL)
> предоставляла т.к. была собрана в среде с
> rpm-build-python-0.33.2-alt1. Для проверки я пересобрал
> python-module-imaging-1.1.6-alt3 в среде с
> rpm-build-python-0.33.2-alt1 (вместо 0.34... в Сизифе), в результате
> чего python2.5(PIL) стал провайдится пакетом python-module-imaging.
> 
> Судя по changelog-у 0.33.2->0.34, была пройзведена переписка кода
> python.prov.py, так что я предполагаю что в результате этого действия
> Provides: теперь корректно выставлены не у всех питон-пакетов в Сизифе
> (точнее у некоторых, собранных с rpm-build-python-0.34). Код изменения
> я пока не смотрел.

Уважаемые мужички!
Давайте рассмотрим конструкцию по делу.

У нас есть несколько файлов:
/usr/lib64/python2.5/site-packages/PIL.pth в нём написано "PIL" и допустим
/usr/lib64/python2.5/site-packages/PIL/__init__.py
/usr/lib64/python2.5/site-packages/PIL/Image.py

В предположении, что каждый файл может предоставлять только один модуль
(то есть в предположении, что PIL/Image.py должен дать только одну
Provides-зависимость в пространстве питоновских модулей) нам нужно
сформировать Provides.  При формировании Provides путь к файлу
разбивается на две компоненты: стандартный каталог и оставшийся путь
к модулю.  Причем стандартный каталог выбирается наиболее длинным,
поскольку, например, site-packages является подкаталогом в стандартном
каталоге.

Так вот, PIL.pth задает в качестве стандартного каталога подкаталог PIL,
и все Provides-зависимости отсчитываются от подкаталога PIL.  То есть
будет что PIL/Image.py предоставляет python2.5(Image).  Новая версия
python.prov.py работает правильно, насколько что по смыслу можно
объяснить как она должна работать.

Возможно, файл PIL.pth вообще не следует упаковывать.  Более того, его
нужно удалить в %buildroot.  Тогда образуются Provides вида python2.5(PIL*).

Примите и проч.

> Кроме того, хотелось бы, чтобы при сборке пакетов проверялось, реально
> ли пакет, содержащий *.pth-файл, может обеспечить python -c "import
> foo", чтобы застраховаться от подобный ошибок упаковки.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]