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

[Terechkov Evgenii]

08.06.2009 Alexey Tourbin писал:

> Давайте рассмотрим конструкцию по делу.
> 
> У нас есть несколько файлов:
> /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 работает правильно, насколько что по смыслу можно
> объяснить как она должна работать.

Спасибо за объяснение. Виноват - обратил внимание на отсутствие
python2.5(PIL*), но не заметил странных python2.5(Image)

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

Я попробовал пересобрать пакет без этого файла (в т.ч. и в %buildroot)
- Provides остались в том же виде - python2.5(Image). Видимо надо
действовать как-то ещё.

-- 
                                                С уважением, Терешков
                                                Евгений, ALT Linux
                                                Team
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20090608/f393164d/attachment.bin>