On Tue, Feb 09, 2010 at 06:13:06PM +0700, Евгений Ростовцев wrote:
> 
> >> > Другими словами, AM_PATH_PYTHON на x86-64 не будет работать правильно.
> >>
> >> Тут я ничего не могу сказать...
> >
> > Плохо, что именно там, где не видно решения, никто не может сказать
> > ничего путного.
> 
> Для того, чтобы найти решение, нужно время. Для того, чтобы хотя бы
> примерно представлять, как работает AM_PATH_PYTHON (вообще с чем это
> едят), тоже нужно время. Вы можете не очень кратко изложить второе?

Макрос AM_PATH_PYTHON документирован (info -f automake Python),
исходный код доступен (/usr/share/aclocal-1.11/python.m4).
Вряд ли я смогу "не очень кратко изложить" то, что там написано и
реализовано, достаточно быстро.

> Может быть, удастся исходя из этой информации, хотя бы попытаться
> найти первое?

Боюсь что без изменения интерфейса AM_PATH_PYTHON не обойтись.

> > AM_PATH_PYTHON на x86-64 не будет у нас работать правильно, судя по
> > всему, никогда, потому такое разделение на arch/noarch, которое ломает
> > AM_PATH_PYTHON, есть только у нас.
> 
> За 25 лет тесного сожительства с компьютером я разучился верить, что
> существуют тупики.

Преимущественно тупики и существуют: сперва что-то делаешь, потом видишь,
что это тупик, возвращаешься и делаешь иначе, etc.

> > К тому же проверить наличие/отсутствие arch-specific в пакете, как уже
> > продемонстрировал at@, относительно несложно.
> 
> Ещё не видел.

Длинное ветвистое обсуждение:
http://lists.altlinux.org/pipermail/devel/2009-December/178420.html

> >> А меня недавно ругали, что я в /usr/lib/%name складываю файлы, а не в
> >> /usr/lib64/%name.
> >
> > Смотря какие файлы.
> 
> Пример: https://bugzilla.altlinux.org/show_bug.cgi?id=20779

Ничего удивительного, вы же там /usr/lib/%name сделали аналогом
/opt/%name, сложив туда разные файлы, для которых в FHS прописаны
соответствующие каталоги.


-- 
ldv