Здравствуйте!

On Thu, 8 Dec 2016, Alexey Tourbin wrote:

>>> Не всегда. Но это один из главных признаков. Ну и это же питновский
>>> модуль. Я его посмотрел, ничего архитектурно-зависимого там не
>>> заметил. Если вписать ему "BuildArch: noarch", то он соберется как
>>> noarch, с путями /usr/lib вместо /usr/lib64. Очень гуттаперчевая
>>
>> Не успел сразу ответить с релевантными ссылками.
>>
>> Про эти питоновские пакеты таким вопросом, бывало, уже задавались люди. Есть
>> подозрение, что это сделано из-за особенностей работы namespace packages в
>> питоне, когда модуль TOPLEVEL.X должен лежать в файловой системе как-то так:
>>
>> TOPLEVEL/__init__.py
>> TOPLEVEL/X.py
>
> Мужчина, вы выражаетесь слишком обходительно, то есть к сожалению
> нельзя поставить вам в вину и упрекнуть вас в том, что именно вы всю
> эту глупость придумали.

Из того, как оно раскладывается по пакетам, я мало что придумал.

А причины/предположения о том, при каком размещении оно работать не смогло 
бы, я во многом придумал сначала, подтвердил увиденными примерами, которые 
могли бы быть последствием этих ограничений, и потом чтением кусочков 
около-документации.

> Мне все-таки не понятно, как может отработать "make check" в сборочном
> каталоге, когда существование какого-то TOPLEVEL мыслится только
> гипотетически.

Теперь мне непонятно, что из моего описания (предполагаемых) ограничений 
на размещение файлов, было Вам не очень понятно. Иначе я бы уточнил.

Попробую так. Варианты мест появления TOPLEVEL (например, repoze), которые 
могли встречаться:

/usr/lib/python3/site-packages/TOPLEVEL/
/usr/lib64/python3/site-packages/TOPLEVEL/
/usr/lib/python3.3/site-packages/TOPLEVEL/
/usr/lib64/python3.3/site-packages/TOPLEVEL/

Но чтобы работало, все файлы питоновских подпакетов TOPLEVEL (например, 
repoze.who, repoze.what, etc.) не могут размазываться между разными 
местами. Только одна директория реально должна была использоваться.

Не вижу каких-то особых проблем для make check.

-- 
Best regards,
Ivan