Alexey Tourbin <at-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

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

В данном случае, PIL вообще очень странная вещь. Они зачем-то
предоставлют и pth и __init__.py. Хотя если подумать, то вещи эти
вобщем-то противоположны.

Но из-за этого некоторые проекты используют PIL по разному. :(