Re: [devel] /usr/lib64/python2.6

Re: [devel] /usr/lib64/python2.6

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Другими словами, AM_PATH_PYTHON на x86-64 не будет работать правильно.

Кто бы мне рассказал, почему у нас %python_libdir на x86-64 определён в
/usr/lib64/python2.6, а не в /usr/lib/python2.6?

Смысл /usr/lib64 в том, чтобы в /usr/lib можно было установить 32-битные
библиотеки.  А какой смысл в 32-битных python-модулях на x86-64?  Какая
сущность сможет загрузить их на x86-64?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] /usr/lib64/python2.6

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 262 bytes --]

On Monday 08 February 2010, Dmitry V. Levin wrote:

[...]
> Какая сущность сможет загрузить их на x86-64?
/usr/lib/libpython2.6.so ?

-- 
Regards, Sergey, ALT Linux, http://www.altlinux.ru/
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] /usr/lib64/python2.6

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

On Mon, Feb 08, 2010 at 07:10:28PM +0300, Sergey V Turchin wrote:
> On Monday 08 February 2010, Dmitry V. Levin wrote:
> 
> [...]
> > Какая сущность сможет загрузить их на x86-64?
> /usr/lib/libpython2.6.so ?

Т.е. python binding в 32-битном приложении на x86-64 системе?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] /usr/lib64/python2.6

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 391 bytes --]

On Monday 08 February 2010, Dmitry V. Levin wrote:

[...]
> > > Какая сущность сможет загрузить их на x86-64?
> > /usr/lib/libpython2.6.so ?
> Т.е. python binding в 32-битном приложении на x86-64 системе?
Да. Не встречал, есть ли смысл в таком реально, но ведь возможно?

-- 
Regards, Sergey, ALT Linux, http://www.altlinux.ru/
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] /usr/lib64/python2.6

[Евгений Ростовцев]

> Другими словами, AM_PATH_PYTHON на x86-64 не будет работать правильно.

Тут я ничего не могу сказать...

> Кто бы мне рассказал, почему у нас %python_libdir на x86-64 определён в
> /usr/lib64/python2.6, а не в /usr/lib/python2.6?

Я бы тоже послушал. А ещё бы послушал, какие это порождает проблемы.
Какие проблемы породит, если %python_libdir на x86_64 сделать
/usr/lib/python2.6, могу я прямо сейчас: у нас не будет больше
разделения на arch/noarch пакеты, потому что %_python_sitelibdir будет
в ЛЮБОМ случае отдавать /usr/lib/python2.6/site-packages. Последствия
очевидны. Неочевиден тот гигантский объём работы, которую нужно будет
проделать, что вылечить репозитория после такой замены. Я с таким
питоном работать не буду (да и с ALT, пожалуй, тоже).

> Смысл /usr/lib64 в том, чтобы в /usr/lib можно было установить 32-битные
> библиотеки.  А какой смысл в 32-битных python-модулях на x86-64?  Какая
> сущность сможет загрузить их на x86-64?

А меня недавно ругали, что я в /usr/lib/%name складываю файлы, а не в
/usr/lib64/%name. Вы уж там в core team придите хотя бы к общему
мнению, а потом уже и нам скажите, что получилось ;)

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] /usr/lib64/python2.6

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

On Tue, Feb 09, 2010 at 03:07:50PM +0700, Евгений Ростовцев wrote:
> > Другими словами, AM_PATH_PYTHON на x86-64 не будет работать правильно.
> 
> Тут я ничего не могу сказать...

Плохо, что именно там, где не видно решения, никто не может сказать
ничего путного.

> > Кто бы мне рассказал, почему у нас %python_libdir на x86-64 определён в
> > /usr/lib64/python2.6, а не в /usr/lib/python2.6?
> 
> Я бы тоже послушал. А ещё бы послушал, какие это порождает проблемы.

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

> Какие проблемы породит, если %python_libdir на x86_64 сделать
> /usr/lib/python2.6, могу я прямо сейчас: у нас не будет больше
> разделения на arch/noarch пакеты, потому что %_python_sitelibdir будет
> в ЛЮБОМ случае отдавать /usr/lib/python2.6/site-packages. Последствия
> очевидны.

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

> > Смысл /usr/lib64 в том, чтобы в /usr/lib можно было установить 32-битные
> > библиотеки.  А какой смысл в 32-битных python-модулях на x86-64?  Какая
> > сущность сможет загрузить их на x86-64?
> 
> А меня недавно ругали, что я в /usr/lib/%name складываю файлы, а не в
> /usr/lib64/%name.

Смотря какие файлы.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] /usr/lib64/python2.6

[Евгений Ростовцев]

Привет!

>> > Другими словами, AM_PATH_PYTHON на x86-64 не будет работать правильно.
>>
>> Тут я ничего не могу сказать...
>
> Плохо, что именно там, где не видно решения, никто не может сказать
> ничего путного.

Для того, чтобы найти решение, нужно время. Для того, чтобы хотя бы
примерно представлять, как работает AM_PATH_PYTHON (вообще с чем это
едят), тоже нужно время. Вы можете не очень кратко изложить второе?
Может быть, удастся исходя из этой информации, хотя бы попытаться
найти первое?

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

За 25 лет тесного сожительства с компьютером я разучился верить, что
существуют тупики.

>> Какие проблемы породит, если %python_libdir на x86_64 сделать
>> /usr/lib/python2.6, могу я прямо сейчас: у нас не будет больше
>> разделения на arch/noarch пакеты, потому что %_python_sitelibdir будет
>> в ЛЮБОМ случае отдавать /usr/lib/python2.6/site-packages. Последствия
>> очевидны.
>
> Мне не очевидны.

Переделывать очень много придётся, и сколько на это времени уйдёт, я
не знаю, но питон 2.6 по сравнению с этим мы собрали довольно быстро
(всего какие-то пол-года).

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

Ещё не видел.

>> А меня недавно ругали, что я в /usr/lib/%name складываю файлы, а не в
>> /usr/lib64/%name.
>
> Смотря какие файлы.

Пример: https://bugzilla.altlinux.org/show_bug.cgi?id=20779

-- 
REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] /usr/lib64/python2.6

[Sergey Y. Afonin]

On Tuesday 09 February 2010, Евгений Ростовцев wrote:

> Я бы тоже послушал. А ещё бы послушал, какие это порождает проблемы.
> Какие проблемы породит, если %python_libdir на x86_64 сделать
> /usr/lib/python2.6, могу я прямо сейчас: у нас не будет больше
> разделения на arch/noarch пакеты,

Кстати, а как делить вот такое ?


%files -n python-module-mailutils
%dir %python_sitelibdir/mailutils
%python_sitelibdir/mailutils/c_api.so
%python_sitelibdir/mailutils/*.py*

c_api.so выносить в ещё один пакет ? Или она, вообще, лишняя.

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] /usr/lib64/python2.6

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]