[devel] Library + Python bindings build

[Aleksey Avdeev]

Mikhail Yakshin пишет:
> Aleksey Avdeev пишет:
> 
>> Mikhail Yakshin пишет:
>> ...
>>
>>>
>>> 2. Запаковать отдельно пакет libtunepimp (порождающий 3 вполне понятных
>>> пакета - libtunepimp, libtunepimp-devel и libtunepimp-utils) и оставить
>>> его таким. Запаковать тот же самый тарболл отдельно, после чего сделать
>>> ему нормальный спек нормального питонного пакета, соответствующий полиси
>>> и примеру спека, с единственной разницей в %setup вроде:
>>>
>>> %setup -q -n %name-%version-pre4/python
>>>
>>> вместо обычного %setup -q, скажем.
>>>
>>> Минусы: пакуем один не очень маленький (~850 кил) тарболл два раза, во
>>> втором случае из всего 850-килобайтного тарболла нам нужны десять
>>> килобайт одного маленького питонного враппера над этой самой либой;
>>>
>>> Плюсы: проще, больше соответствует policy.
>>>
>>> Посоветуйте, как быть?..
>>
>>
>>   Может имеет смысл запаковать исходники вообще отдельно, и 
>> использовать данный пакет при сборке данных двух? (Решение по типу 
>> kernel-source-*)
> 
> 
> Да вы что, там один файлик на десяток килобайт на этом несчастном питоне 
>  - и из-за такой ерунды будем городить инфраструктуру а ля ядерная 
> сборка? %))

   А зачем она сдесь в полном объёме? :-) Достаточно идеи от туда:

1. libtunepimp-source, кладущий тарболл куданибудь в район 
/usr/src/*. Возможно, его функции способен взять на себя 
libtunepimp-devel (будет нечто, похожее на php-devel)... Но сдесь 
надо смотреть как лучше/проще/удобнее.

2. Пакеты {libtunepimp,python-module-tunepimp}-*.src.rpm, 
использующие в качестве тарболла то, что положил libtunepimp-source...

   Заодно python-module-tunepimp можно будет собрать как noarch... ;-)

-- 

С уважением. Алексей.