Re: [devel] I: Новый rpm.

Re: [devel] I: Новый rpm.

[Alex Myltsev]

On 9/21/07, Alexey Tourbin <at@altlinux.ru> wrote:
> On Fri, Sep 21, 2007 at 07:32:10PM +0400, Anton Farygin wrote:
> > > Зачем тебе новый rpm (в смысле 4.4).
> > А мне нужен biarch ;(
> Антон.  Когда появится новый rpm, то не факт, что biarch сразу
> заработает.

Скажу больше -- факт, что (сразу) он не заработает.

Во-первых, он толком не работает даже там, где под него всё заточено.
Пусть, например, два пакета разной битности имеют совпадающий файл.
rpm их радостно установит. Но если теперь один из этих пакетов
обновить или удалить, то с этим файлом будет беда. Типа вот:
http://tinyurl.com/279dn8

Во-вторых, сейчас в RPM-4.5 сделано так: "цветные" зависимости
(которые нужны для multilib) умеет порождать только встроенный в RPM,
написанный на C порождатель зависимостей. Наш (внешний) find-requires,
который at@ так громко пилит вот уж не первый месяц, использовать
можно, но multilib'а никакого не будет.

Re: [devel] I: Новый rpm.

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 04:58:12PM +0400, Alex Myltsev wrote:
> On 9/21/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > On Fri, Sep 21, 2007 at 07:32:10PM +0400, Anton Farygin wrote:
> > > > Зачем тебе новый rpm (в смысле 4.4).
> > > А мне нужен biarch ;(
> > Антон.  Когда появится новый rpm, то не факт, что biarch сразу
> > заработает.
> 
> Скажу больше -- факт, что (сразу) он не заработает.

Конечно, самый дешёвый работающий биарч -- это чрут.
Однако для некоторых это всё равно слишком дорого.

> Во-первых, он толком не работает даже там, где под него всё заточено.
> Пусть, например, два пакета разной битности имеют совпадающий файл.
> rpm их радостно установит. Но если теперь один из этих пакетов
> обновить или удалить, то с этим файлом будет беда. Типа вот:
> http://tinyurl.com/279dn8

rpm должен радостно позволить операцию с установкой/обновлением
совпадающего файла только в случае если файл действительно совпадает.

> Во-вторых, сейчас в RPM-4.5 сделано так: "цветные" зависимости
> (которые нужны для multilib) умеет порождать только встроенный в RPM,
> написанный на C порождатель зависимостей. Наш (внешний) find-requires,
> который at@ так громко пилит вот уж не первый месяц, использовать
> можно, но multilib'а никакого не будет.

Насколько сложно добавить "цветность" в наш порождатель зависимостей?


-- 
ldv

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

[devel] [JT] 32bit chroot + wine = ?

[Pavlov Konstantin]

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

On Sun, Sep 23, 2007 at 05:17:01PM +0400, Dmitry V. Levin wrote:
> On Sun, Sep 23, 2007 at 04:58:12PM +0400, Alex Myltsev wrote:
> > On 9/21/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > > On Fri, Sep 21, 2007 at 07:32:10PM +0400, Anton Farygin wrote:
> > > > > Зачем тебе новый rpm (в смысле 4.4).
> > > > А мне нужен biarch ;(
> > > Антон.  Когда появится новый rpm, то не факт, что biarch сразу
> > > заработает.
> > 
> > Скажу больше -- факт, что (сразу) он не заработает.
> 
> Конечно, самый дешёвый работающий биарч -- это чрут.
> Однако для некоторых это всё равно слишком дорого.

Но, что странно, нормально это отчего-то не работает.

Т.е. 32bit-чрут с wine и 3d-игрой, запущенной под wine показывал у меня
слайд-шоу.

Также там присутствует проблема со звуком -- работает только oss.

Впрочем, это скорее всего еще и из-за того, что я чего-то еще не знаю,
может, в community@ подскажут?

-- 
В mysql chroot'изация всегда была сделана из рук вон плохо, и реакция от
upstream на мои патчи была невразумительной.  Как следствие, у меня есть
основание полагать, что в этой области там не все сделано правильно, вне
зависимости от того, что написано в документации.
		-- ldv in devel@

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

Re: [devel] I: Новый rpm.

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 04:58:12PM +0400, Alex Myltsev wrote:
> On 9/21/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > On Fri, Sep 21, 2007 at 07:32:10PM +0400, Anton Farygin wrote:
> > > > Зачем тебе новый rpm (в смысле 4.4).
> > > А мне нужен biarch ;(
> > Антон.  Когда появится новый rpm, то не факт, что biarch сразу
> > заработает.
> 
> Скажу больше -- факт, что (сразу) он не заработает.
> 
> Во-первых, он толком не работает даже там, где под него всё заточено.
> Пусть, например, два пакета разной битности имеют совпадающий файл.
> rpm их радостно установит. Но если теперь один из этих пакетов
> обновить или удалить, то с этим файлом будет беда. Типа вот:
> http://tinyurl.com/279dn8
> 
> Во-вторых, сейчас в RPM-4.5 сделано так: "цветные" зависимости
> (которые нужны для multilib) умеет порождать только встроенный в RPM,
> написанный на C порождатель зависимостей. Наш (внешний) find-requires,
> который at@ так громко пилит вот уж не первый месяц, использовать
> можно, но multilib'а никакого не будет.

Я не прочь пилить потише, просто щепки летят.  Материал такой.
То есть баги всплывают в совершенно разных местах, и о них нужно
знать до того, как "это случится".

А где можно прочитать про "цветные" зависимости?
В принципе я бы почитал сразу код, если там есть комментарии.

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

Re: [devel] I: Новый rpm.

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 04:58:12PM +0400, Alex Myltsev wrote:
> On 9/21/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > On Fri, Sep 21, 2007 at 07:32:10PM +0400, Anton Farygin wrote:
> > > > Зачем тебе новый rpm (в смысле 4.4).
> > > А мне нужен biarch ;(
> > Антон.  Когда появится новый rpm, то не факт, что biarch сразу
> > заработает.
> 
> Скажу больше -- факт, что (сразу) он не заработает.
> 
> Во-первых, он толком не работает даже там, где под него всё заточено.
> Пусть, например, два пакета разной битности имеют совпадающий файл.
> rpm их радостно установит. Но если теперь один из этих пакетов
> обновить или удалить, то с этим файлом будет беда. Типа вот:
> http://tinyurl.com/279dn8

Хм.  Отпиливать libperl от perl-base я принципиально не хочу, хотя меня
об этом уже просили.  "При обнаружении некоторых синтаксических
конструкций интерпретатор умеет подгружать некоторые стандартные модули
из perl-base."  https://bugzilla.altlinux.org/show_bug.cgi?id=5283

Но в противном случае multilib по части libperl просто невозможен,
потому что будет пересечение по /usr/bin/perl.

Там предлагают сделать /bin64, что, как мне кажется, в обозримом
будущем совершенно нереально.  Бодяги с %_libdir уже всем хватило.

Так вот, что же получается?  По базовому пакету perl-base, который
входит в basesystem, с мультилибом облом.  Вероятно, таких пакетов
есть ещё много -- если с ними и не "вообще" облом, то "по смыслу"
облом.  То есть можно придуриться и отпилить пакет libperl, но
"по смыслу" облом никуда не денется.

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

Re: [devel] I: Новый rpm.

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 05:52:45PM +0400, Alexey Tourbin wrote:
> On Sun, Sep 23, 2007 at 04:58:12PM +0400, Alex Myltsev wrote:
> > On 9/21/07, Alexey Tourbin <at@altlinux.ru> wrote:
> > > On Fri, Sep 21, 2007 at 07:32:10PM +0400, Anton Farygin wrote:
> > > > > Зачем тебе новый rpm (в смысле 4.4).
> > > > А мне нужен biarch ;(
> > > Антон.  Когда появится новый rpm, то не факт, что biarch сразу
> > > заработает.
> > 
> > Скажу больше -- факт, что (сразу) он не заработает.
> > 
> > Во-первых, он толком не работает даже там, где под него всё заточено.
> > Пусть, например, два пакета разной битности имеют совпадающий файл.
> > rpm их радостно установит. Но если теперь один из этих пакетов
> > обновить или удалить, то с этим файлом будет беда. Типа вот:
> > http://tinyurl.com/279dn8
> 
> Хм.  Отпиливать libperl от perl-base я принципиально не хочу, хотя меня
> об этом уже просили.  "При обнаружении некоторых синтаксических
> конструкций интерпретатор умеет подгружать некоторые стандартные модули
> из perl-base."  https://bugzilla.altlinux.org/show_bug.cgi?id=5283

А если общую (noarch) часть поместить в libperl, польза будет?


-- 
ldv

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

Re: [devel] I: Новый rpm.

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 06:40:46PM +0400, Dmitry V. Levin wrote:
> > Хм.  Отпиливать libperl от perl-base я принципиально не хочу, хотя меня
> > об этом уже просили.  "При обнаружении некоторых синтаксических
> > конструкций интерпретатор умеет подгружать некоторые стандартные модули
> > из perl-base."  https://bugzilla.altlinux.org/show_bug.cgi?id=5283
> 
> А если общую (noarch) часть поместить в libperl, польза будет?

Не совсем.  Будет польза, если паковать /usr/bin/* отдельно
от %_libdir+/usr/lib*/perl5.  Тогда как бы сразу две перловые
подсистемы будут работоспособными, а /usr/bin/perl будет всего
один (front-end к одной из подсистем).

Но это глобальный перекорой пакетов под biarch.  Фактически
оказывается, что разницы в %_libdir оказывается недостаточно.
Или не знаю.

Нужно также убедиться, что алгоритм разрешения зависимостей
работает только в пределах данной архитектуры (+ noarch).
Либо опять добавлять к зависимостям ()(64bit).  Но в случае
с перлом это вряд ли возможно.

Уроды какие-то.

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

Re: [devel] I: Новый rpm.

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070923 18:05]:
> Но в противном случае multilib по части libperl просто невозможен,
> потому что будет пересечение по /usr/bin/perl.
А теперь представим ситуацию с зависимостью на libperl.32bit и
perl-Какой-То-Модуль с Какой/То/Модуль.so внутри.  Или python.

Не знаю, правда, насколько нужны стандартные модули нужны
программам, таскающим интертрепатор внутри себя...

-- 
Regards,
Sir Raorn.

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

Re: [devel] I: Новый rpm.

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 07:09:21PM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070923 18:05]:
> > Но в противном случае multilib по части libperl просто невозможен,
> > потому что будет пересечение по /usr/bin/perl.
> А теперь представим ситуацию с зависимостью на libperl.32bit и
> perl-Какой-То-Модуль с Какой/То/Модуль.so внутри.  Или python.

Это более частный случай использования libperl, чем стандартный случай
использования libperl, и этот случай называется /usr/bin/perl.

> Не знаю, правда, насколько нужны стандартные модули нужны
> программам, таскающим интертрепатор внутри себя...

Модули для встраемого перла нужны не больше и не меньше,
чем для /usr/bin/perl.  То есть, вообще говоря, нужны. :)

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

Re: [devel] I: Новый rpm.

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 07:08:27PM +0400, Alexey Tourbin wrote:
> On Sun, Sep 23, 2007 at 06:40:46PM +0400, Dmitry V. Levin wrote:
> > > Хм.  Отпиливать libperl от perl-base я принципиально не хочу, хотя меня
> > > об этом уже просили.  "При обнаружении некоторых синтаксических
> > > конструкций интерпретатор умеет подгружать некоторые стандартные модули
> > > из perl-base."  https://bugzilla.altlinux.org/show_bug.cgi?id=5283
> > 
> > А если общую (noarch) часть поместить в libperl, польза будет?
> 
> Не совсем.  Будет польза, если паковать /usr/bin/* отдельно
> от %_libdir+/usr/lib*/perl5.  Тогда как бы сразу две перловые
> подсистемы будут работоспособными, а /usr/bin/perl будет всего
> один (front-end к одной из подсистем).

То есть сейчас пакет perl-base имеет самостоятельный смысл,
и дробить его в свете этого -- нет смысла.  Пакеты perl-base i586
и perl-base x86_64 либо не пересекаются по файлам, либо пересекающиеся
файлы совпадают, за исключением "общего места" -- /usr/bin.  Но это
общее место для всех пакетов, так что я не вижу большого смысла
обсуждать perl-base отдельно.  Просто это как контр-пример из basesystem
для всей идеи biarch.

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

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 07:18:32PM +0400, Alexey Tourbin wrote:
> On Sun, Sep 23, 2007 at 07:08:27PM +0400, Alexey Tourbin wrote:
> > On Sun, Sep 23, 2007 at 06:40:46PM +0400, Dmitry V. Levin wrote:
[...]
> > > А если общую (noarch) часть поместить в libperl, польза будет?
> > 
> > Не совсем.  Будет польза, если паковать /usr/bin/* отдельно
> > от %_libdir+/usr/lib*/perl5.  Тогда как бы сразу две перловые
> > подсистемы будут работоспособными, а /usr/bin/perl будет всего
> > один (front-end к одной из подсистем).
> 
> То есть сейчас пакет perl-base имеет самостоятельный смысл,
> и дробить его в свете этого -- нет смысла.  Пакеты perl-base i586
> и perl-base x86_64 либо не пересекаются по файлам, либо пересекающиеся
> файлы совпадают, за исключением "общего места" -- /usr/bin.  Но это
> общее место для всех пакетов, так что я не вижу большого смысла
> обсуждать perl-base отдельно.  Просто это как контр-пример из basesystem
> для всей идеи biarch.

Переформулирую тот же вопрос на другой пакет из basesystem, который
называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
perl-base.

Вопрос: будем пилить все такие пакеты, или есть варианты получше?


-- 
ldv

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

Re: [devel] biarch

[Led]

2007/9/23, Dmitry V. Levin <ldv@altlinux.org>:
> On Sun, Sep 23, 2007 at 07:18:32PM +0400, Alexey Tourbin wrote:
> > On Sun, Sep 23, 2007 at 07:08:27PM +0400, Alexey Tourbin wrote:
> > > On Sun, Sep 23, 2007 at 06:40:46PM +0400, Dmitry V. Levin wrote:
> [...]
> > > > А если общую (noarch) часть поместить в libperl, польза будет?
> > >
> > > Не совсем.  Будет польза, если паковать /usr/bin/* отдельно
> > > от %_libdir+/usr/lib*/perl5.  Тогда как бы сразу две перловые
> > > подсистемы будут работоспособными, а /usr/bin/perl будет всего
> > > один (front-end к одной из подсистем).
> >
> > То есть сейчас пакет perl-base имеет самостоятельный смысл,
> > и дробить его в свете этого -- нет смысла.  Пакеты perl-base i586
> > и perl-base x86_64 либо не пересекаются по файлам, либо пересекающиеся
> > файлы совпадают, за исключением "общего места" -- /usr/bin.  Но это
> > общее место для всех пакетов, так что я не вижу большого смысла
> > обсуждать perl-base отдельно.  Просто это как контр-пример из basesystem
> > для всей идеи biarch.
>
> Переформулирую тот же вопрос на другой пакет из basesystem, который
> называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
> пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
> совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
> sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
> perl-base.
>
> Вопрос: будем пилить все такие пакеты, или есть варианты получше?

Прошу не судить строго. Я позволю себе высказать свои ламерские мысли:)
32-битные файлы для x86_64-системы это всё же неосновные, а "то, что
ещё дополнительно может поддерживаться". Поэтому, может быть, имеет
смысл располагать их в /usr/bin32, /usr/sbin32, /usr/lib32, или даже в
/usr/x86_32/bin, /usr/x86_32/lib. При этом они должны попадать туда
автоматически - rpm должен это определять автоматом по архитектуре
пакета и ложить файлы куда нужно. Пересечение же файлов в других
каталогах, наверное, придётся решать на уровне пакетов (?)

-- 
Led.

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 07:39:33PM +0400, Dmitry V. Levin wrote:
> Переформулирую тот же вопрос на другой пакет из basesystem, который
> называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
> пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
> совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
> sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
> perl-base.
> 
> Вопрос: будем пилить все такие пакеты, или есть варианты получше?

Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
пилить?

Пусть сначала будет представлен некий консистентный план, как должен
работать biarch.  А мы его посмотрим.  Желательно в более-менее
алгебарических терминах, типа что значит "зависимость удовлетворена",
каким образом могут быть удовлетворены зависимости между архитектурами
и т.п.  (Я могу подкинуть вопросов, но это не моя работа!)

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

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

Re: [devel] biarch

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [070923 19:45]:
[..skip..]
> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
Может чрут?  Что-то многовато бесполезной работы для двух-трёх
кривософтин, девелоперы которых ниасилили сборку под 64 бита...

-- 
Regards,
Sir Raorn.

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

Re: [devel] biarch

[Aleksey Novodvorsky]

On 9/23/07, Alexey I. Froloff <raorn@immo.ru> wrote:
> * Dmitry V. Levin <ldv@> [070923 19:45]:
> [..skip..]
> > Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> Может чрут?  Что-то многовато бесполезной работы для двух-трёх
> кривософтин, девелоперы которых ниасилили сборку под 64 бита...

+1

Rgrds, Алексей

Re: [devel] biarch

[Alexey I. Froloff]

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

* Led <led@> [070923 20:25]:
> Поэтому, может быть, имеет смысл располагать их в /usr/bin32,
> /usr/sbin32, /usr/lib32, или даже в /usr/x86_32/bin,
> /usr/x86_32/lib.
/usr/i586-alt-linux/ и сборка кросскомпилятором на x86_64 из
отдельных x86_64-only пакетов.

-- 
Regards,
Sir Raorn.

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

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 07:22:42PM +0300, Led wrote:
> Прошу не судить строго. Я позволю себе высказать свои ламерские мысли:)
> 32-битные файлы для x86_64-системы это всё же неосновные, а "то, что
> ещё дополнительно может поддерживаться". Поэтому, может быть, имеет
> смысл располагать их в /usr/bin32, /usr/sbin32, /usr/lib32, или даже в
> /usr/x86_32/bin, /usr/x86_32/lib. При этом они должны попадать туда
> автоматически - rpm должен это определять автоматом по архитектуре
> пакета и ложить файлы куда нужно. Пересечение же файлов в других
> каталогах, наверное, придётся решать на уровне пакетов (?)

То есть /usr/bin/i586-alt-linux-gcc нужно переложить
в /usr/bin32/i586-alt-linux-gcc?  Хе-хе.  Пути могут иметь
семантику зависимостей сами по себе!  Причем, выполняя часть
чужой работы, скажу, что семантика этих зависимостей может быть
как кросс-архитектурной (через exec), так и не допускать пересечение
архитектур (допустим, через dlopen, хотя есть другие похожие случаи).

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

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 08:23:31PM +0400, Alexey Tourbin wrote:
> On Sun, Sep 23, 2007 at 07:39:33PM +0400, Dmitry V. Levin wrote:
> > Переформулирую тот же вопрос на другой пакет из basesystem, который
> > называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
> > пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
> > совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
> > sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
> > perl-base.
> > 
> > Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> 
> Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
> пилить?

Понятное дело, чтобы можно было
1. gcc -m32 в системе x86_64
2. использовать результат (1) в системе x86_64
или что-то в этом духе.

> Пусть сначала будет представлен некий консистентный план, как должен
> работать biarch.  А мы его посмотрим.

У меня такое ощущение, что консистентный план ждут от нас. ;)
Те, которые ждут, сами не знают, как именно это будет реализовано.


-- 
ldv

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

Re: [devel] biarch

[Anton Farygin]

Aleksey Novodvorsky пишет:
> On 9/23/07, Alexey I. Froloff <raorn@immo.ru> wrote:
>> * Dmitry V. Levin <ldv@> [070923 19:45]:
>> [..skip..]
>>> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
>> Может чрут?  Что-то многовато бесполезной работы для двух-трёх
>> кривософтин, девелоперы которых ниасилили сборку под 64 бита...
> 
> +1

Алексей, у нас возникла реальная необходимость в biarch на одном из 
проектов.. чрут там не поможет - задача куче пользователей (их может 
быть 100, а может быть несколько десятков тысяч) запускать ПО из 
домашнего каталога.

И не факт что данное ПО будет свободное, и тем более - для x86_64.

С предложением городить чрут или LD_LIBRARY_PATH каждому пользователю 
... в общем не буду дословно пересказывать всё, что я слышал, там не всё 
цензурно.

Re: [devel] biarch

[Anton Farygin]

Dmitry V. Levin пишет:
> On Sun, Sep 23, 2007 at 08:23:31PM +0400, Alexey Tourbin wrote:
>> On Sun, Sep 23, 2007 at 07:39:33PM +0400, Dmitry V. Levin wrote:
>>> Переформулирую тот же вопрос на другой пакет из basesystem, который
>>> называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
>>> пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
>>> совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
>>> sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
>>> perl-base.
>>>
>>> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
>> Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
>> пилить?
> 
> Понятное дело, чтобы можно было
> 1. gcc -m32 в системе x86_64
> 2. использовать результат (1) в системе x86_64
> или что-то в этом духе.
> 
>> Пусть сначала будет представлен некий консистентный план, как должен
>> работать biarch.  А мы его посмотрим.
> 
> У меня такое ощущение, что консистентный план ждут от нас. ;)
> Те, которые ждут, сами не знают, как именно это будет реализовано.

Если под теми, кто ждёт - подразумеваюсь и я в том числе, то 
действительно жду от вас. И естественно не знаю как это будет реализовано.

Re: [devel] biarch

[Aleksey Novodvorsky]

On 9/23/07, Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Sun, Sep 23, 2007 at 08:23:31PM +0400, Alexey Tourbin wrote:
> > On Sun, Sep 23, 2007 at 07:39:33PM +0400, Dmitry V. Levin wrote:
> > > Переформулирую тот же вопрос на другой пакет из basesystem, который
> > > называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
> > > пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
> > > совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
> > > sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
> > > perl-base.
> > >
> > > Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> >
> > Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
> > пилить?
>
> Понятное дело, чтобы можно было
> 1. gcc -m32 в системе x86_64
> 2. использовать результат (1) в системе x86_64
> или что-то в этом духе.
>
> > Пусть сначала будет представлен некий консистентный план, как должен
> > работать biarch.  А мы его посмотрим.
>
> У меня такое ощущение, что консистентный план ждут от нас. ;)

Именно.

Rgrds, Алексей

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 10:19:47PM +0400, Aleksey Novodvorsky wrote:
> On 9/23/07, Dmitry V. Levin wrote:
> > On Sun, Sep 23, 2007 at 08:23:31PM +0400, Alexey Tourbin wrote:
> > > On Sun, Sep 23, 2007 at 07:39:33PM +0400, Dmitry V. Levin wrote:
> > > > Переформулирую тот же вопрос на другой пакет из basesystem, который
> > > > называется glibc-core.  Пакеты glibc-core.i586 и glibc-core.x86_64
> > > > пересекаются по файлам в /etc/ и /sbin/.  При этом файлы в /etc/
> > > > совпадают, а файлы в /sbin/ отличаются.  При этом в biarch-системе нужны
> > > > sbin-файлы из glibc-core.x86_64.  Другими словами, картинка аналогична
> > > > perl-base.
> > > >
> > > > Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> > >
> > > Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
> > > пилить?
> >
> > Понятное дело, чтобы можно было
> > 1. gcc -m32 в системе x86_64
> > 2. использовать результат (1) в системе x86_64
> > или что-то в этом духе.
> >
> > > Пусть сначала будет представлен некий консистентный план, как должен
> > > работать biarch.  А мы его посмотрим.
> >
> > У меня такое ощущение, что консистентный план ждут от нас. ;)
> 
> Именно.

Интересно, те кто ждут, действительно не знают что именно им нужно?


-- 
ldv

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

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 09:57:04PM +0400, Dmitry V. Levin wrote:
> > Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
> > пилить?
> 
> Понятное дело, чтобы можно было
> 1. gcc -m32 в системе x86_64
> 2. использовать результат (1) в системе x86_64
> или что-то в этом духе.

Ох.  Можно сделать полностью родной чрут, или даже контейнер.
Ведь если речь идет о запуске какого-то условно-серьезного
проприетарного софта, то контейтер вовсе даже не помешает.

А если речь идет о запуске чего-то такого, для чего я время от времени
делаю "killall /usr/bin/nspluginviewer", потому что оно начинает уводить
систему в своп, то...

> > Пусть сначала будет представлен некий консистентный план, как должен
> > работать biarch.  А мы его посмотрим.
> 
> У меня такое ощущение, что консистентный план ждут от нас. ;)
> Те, которые ждут, сами не знают, как именно это будет реализовано.

Понимаешь какое дело.  Хорошего плана просто нет.  В противно случае,
с учетом того, что Антон маячит со своим проектом, это было бы дело
наживное -- даёшь мне энную часть денег и через месяц будет biarch
в таком-то объеме (basesystem + rpm-build).

Но это просто никак нельзя сделать, не извернувшись как Mandriva.

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

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 10:09:09PM +0400, Anton Farygin wrote:
> Aleksey Novodvorsky пишет:
> > On 9/23/07, Alexey I. Froloff wrote:
> >> * Dmitry V. Levin <ldv@> [070923 19:45]:
> >> [..skip..]
> >>> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> >> Может чрут?  Что-то многовато бесполезной работы для двух-трёх
> >> кривософтин, девелоперы которых ниасилили сборку под 64 бита...
> > 
> > +1
> 
> Алексей, у нас возникла реальная необходимость в biarch на одном из 
> проектов.. чрут там не поможет - задача куче пользователей (их может 
> быть 100, а может быть несколько десятков тысяч) запускать ПО из 
> домашнего каталога.
> 
> И не факт что данное ПО будет свободное, и тем более - для x86_64.
> 
> С предложением городить чрут или LD_LIBRARY_PATH каждому пользователю 
> ... в общем не буду дословно пересказывать всё, что я слышал, там не всё 
> цензурно.

И чего им нужно?  Чтобы "просто всё работало как ни в чём не бывало,
словно это одна архитектура"?  Думаю что в такой постановке задачи достичь
желаемого результата нереально.  Антон, если ты рассчитываешь на
коллективное обсуждение, надо рассказать несколько больше.


-- 
ldv

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

Re: [devel] biarch

[Alexey I. Froloff]

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

* Anton Farygin <rider@> [070923 22:17]:
> С предложением городить чрут или LD_LIBRARY_PATH каждому пользователю 
> ... в общем не буду дословно пересказывать всё, что я слышал, там не всё 
> цензурно.
Проблемы LD_LIBRARY_PATH решаются одним скриптом в
/etc/profile.d/.  Если у тебя есть какой-то абстрактный проект,
за который _тебе_ платят деньги, зачем все остальные должны
переделывать _работающие_ пакеты, чтобы бесплатно решить проблемы
чужого кривософта?  Получилось слегка грубо, но правда.

Вернёмся в биарчу.  100% работающего решения, которое решало бы
ВСЕ проблемы не существует.  Значит надо разбираться с
конкретными случаями.

P.S.  Кстати у нас и без биарча есть некоторая неконсистентность.
См. напр. https://bugzilla.altlinux.org/show_bug.cgi?id=12886

-- 
Regards,
Sir Raorn.

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

Re: [devel] biarch

[Anton Farygin]

Dmitry V. Levin пишет:
> On Sun, Sep 23, 2007 at 10:09:09PM +0400, Anton Farygin wrote:
>> Aleksey Novodvorsky пишет:
>>> On 9/23/07, Alexey I. Froloff wrote:
>>>> * Dmitry V. Levin <ldv@> [070923 19:45]:
>>>> [..skip..]
>>>>> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
>>>> Может чрут?  Что-то многовато бесполезной работы для двух-трёх
>>>> кривософтин, девелоперы которых ниасилили сборку под 64 бита...
>>> +1
>> Алексей, у нас возникла реальная необходимость в biarch на одном из 
>> проектов.. чрут там не поможет - задача куче пользователей (их может 
>> быть 100, а может быть несколько десятков тысяч) запускать ПО из 
>> домашнего каталога.
>>
>> И не факт что данное ПО будет свободное, и тем более - для x86_64.
>>
>> С предложением городить чрут или LD_LIBRARY_PATH каждому пользователю 
>> ... в общем не буду дословно пересказывать всё, что я слышал, там не всё 
>> цензурно.
> 
> И чего им нужно?  Чтобы "просто всё работало как ни в чём не бывало,
> словно это одна архитектура"?  Думаю что в такой постановке задачи достичь
> желаемого результата нереально.  Антон, если ты рассчитываешь на
> коллективное обсуждение, надо рассказать несколько больше.

Уже говорилось, но повторю:
первое что нужно клиентам - это запуск всякой проприетарщины, 
отсутствующей не x86_64. Как правило эта проприетарщина ничего 
серьёзного не тянет, но glibc ей нужен в любом случае.

второе, что нужно нам - это gcc -m32 и grub на x86_64. Это нужно для 
Xen, который опять же хотят некоторые клиенты (именно xen, к сожалению).

Т.е. - весь софт как правило серверный. С десктопом с одной стороны 
проще - там задача плагины всякие грузить, для этого -m32 вполне хватит, 
ставить проприетарщину (glibc, SDL для игр, ну и по мелочи,  и wine 
запускать с win32 программами). Хотя десктоп не даёт реально тех 
преимуществ x86_64, которые проявляются на серверных приложениях. Т.е. 
реальной необходимости в десктопе x86_64 я не вижу ни для кого, кроме 
сисадминов и программистов. Запросов на десктопный biarch нам ни от 
кого, кроме коллег из Team и Sisyphus пока-что не поступало.

на мой взгляд, можно посмотреть как сделан biarch в SuSE - судя по всему 
это всех устраивает.

Rgds,
Anton

Re: [devel] incompatibility

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 10:30:29PM +0400, Alexey I. Froloff wrote:
[...]
> P.S.  Кстати у нас и без биарча есть некоторая неконсистентность.
> См. напр. https://bugzilla.altlinux.org/show_bug.cgi?id=12886

Это называется другим словом: несовместимость.
В процитированном случае это объективно, я ввёл symbol versioning раньше
чем это сделал upstream, имена интерфейсов не совпали... Так бывает.


-- 
ldv

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

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 10:35:49PM +0400, Anton Farygin wrote:
> на мой взгляд, можно посмотреть как сделан biarch в SuSE - судя по всему 
> это всех устраивает.

Куда посмотреть, как сделано в SuSE?

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

Re: [devel] biarch

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 09:57:04PM +0400, Dmitry V. Levin wrote:
>>> Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
>>> пилить?
>> Понятное дело, чтобы можно было
>> 1. gcc -m32 в системе x86_64
>> 2. использовать результат (1) в системе x86_64
>> или что-то в этом духе.
> 
> Ох.  Можно сделать полностью родной чрут, или даже контейнер.
> Ведь если речь идет о запуске какого-то условно-серьезного
> проприетарного софта, то контейтер вовсе даже не помешает.

Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере 
из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в 
этом, а в том, что видимо таких кластеров может быть больше одного.

И пользователей, запускающих софт на этом кластере тоже будет ой как 
много... а запускать они будут в том числе и 32-х битные приложения (я 
сам не ожидал, что такие есть для счётных задач, но оказывается это правда)


> 
> А если речь идет о запуске чего-то такого, для чего я время от времени
> делаю "killall /usr/bin/nspluginviewer", потому что оно начинает уводить
> систему в своп, то...
> 
>>> Пусть сначала будет представлен некий консистентный план, как должен
>>> работать biarch.  А мы его посмотрим.
>> У меня такое ощущение, что консистентный план ждут от нас. ;)
>> Те, которые ждут, сами не знают, как именно это будет реализовано.
> 
> Понимаешь какое дело.  Хорошего плана просто нет.  В противно случае,
> с учетом того, что Антон маячит со своим проектом, это было бы дело
> наживное -- даёшь мне энную часть денег и через месяц будет biarch
> в таком-то объеме (basesystem + rpm-build).
> 
> Но это просто никак нельзя сделать, не извернувшись как Mandriva.

Алексей, а ты не смотрел как извернулась SuSE ? И как сделано в Fedora ? 
Почему-то в подобных решениях я им доверяю чуть больше чем Mandriva, 
вспоминая libGLwrapper (хотя он и работал).

Re: [devel] biarch

[Led]

2007/9/23, Anton Farygin <rider@altlinux.com>:
> Dmitry V. Levin пишет:
> > On Sun, Sep 23, 2007 at 10:09:09PM +0400, Anton Farygin wrote:
> >> Aleksey Novodvorsky пишет:
> >>> On 9/23/07, Alexey I. Froloff wrote:
> >>>> * Dmitry V. Levin <ldv@> [070923 19:45]:
> >>>> [..skip..]
> >>>>> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> >>>> Может чрут?  Что-то многовато бесполезной работы для двух-трёх
> >>>> кривософтин, девелоперы которых ниасилили сборку под 64 бита...
> >>> +1
> >> Алексей, у нас возникла реальная необходимость в biarch на одном из
> >> проектов.. чрут там не поможет - задача куче пользователей (их может
> >> быть 100, а может быть несколько десятков тысяч) запускать ПО из
> >> домашнего каталога.
> >>
> >> И не факт что данное ПО будет свободное, и тем более - для x86_64.
> >>
> >> С предложением городить чрут или LD_LIBRARY_PATH каждому пользователю
> >> ... в общем не буду дословно пересказывать всё, что я слышал, там не всё
> >> цензурно.
> >
> > И чего им нужно?  Чтобы "просто всё работало как ни в чём не бывало,
> > словно это одна архитектура"?  Думаю что в такой постановке задачи достичь
> > желаемого результата нереально.  Антон, если ты рассчитываешь на
> > коллективное обсуждение, надо рассказать несколько больше.
>
> Уже говорилось, но повторю:
> первое что нужно клиентам - это запуск всякой проприетарщины,
> отсутствующей не x86_64. Как правило эта проприетарщина ничего
> серьёзного не тянет, но glibc ей нужен в любом случае.
>
> второе, что нужно нам - это gcc -m32 и grub на x86_64. Это нужно для
> Xen, который опять же хотят некоторые клиенты (именно xen, к сожалению).
>
> Т.е. - весь софт как правило серверный. С десктопом с одной стороны
> проще - там задача плагины всякие грузить, для этого -m32 вполне хватит,
> ставить проприетарщину (glibc, SDL для игр, ну и по мелочи,  и wine
> запускать с win32 программами). Хотя десктоп не даёт реально тех
> преимуществ x86_64, которые проявляются на серверных приложениях. Т.е.
> реальной необходимости в десктопе x86_64 я не вижу ни для кого, кроме
> сисадминов и программистов. Запросов на десктопный biarch нам ни от
> кого, кроме коллег из Team и Sisyphus пока-что не поступало.

Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
мог бы его разработать. Лично мне их аргументы кажутся вполне
корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
возможно) разрулить пересечения по файлам в glibc-core. До этого каких
либо конструктивных предложений вряд ли следует ждать, потому как даже
попробовать/проверить сложно.
Кстати, возможно я чего-то не понимаю, но мне очень часто не хватает
возможности указать архитектуру (обычно noarch) для конкретных
субпакетов, а не для всех субпакетов глобально.

-- 
Led.

Re: [devel] [JT] incompatibility

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [070923 22:47]:
> В процитированном случае это объективно, я ввёл symbol versioning раньше
> чем это сделал upstream, имена интерфейсов не совпали... Так бывает.
%
Поддержка vlan'ов у нас появилась в середине 2002-го года, в RH -
только в начале 2003-го, в MDK - из RH.

Можете спросить в RH, почему они сделали несовместимый с ALT Linux
интерфейс.
                -- ldv in sisyphus@
%

;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 10:47:42PM +0400, Anton Farygin wrote:
> > Ох.  Можно сделать полностью родной чрут, или даже контейнер.
> > Ведь если речь идет о запуске какого-то условно-серьезного
> > проприетарного софта, то контейтер вовсе даже не помешает.
> 
> Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере 
> из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в 
> этом, а в том, что видимо таких кластеров может быть больше одного.
> 
> И пользователей, запускающих софт на этом кластере тоже будет ой как 
> много... а запускать они будут в том числе и 32-х битные приложения (я 
> сам не ожидал, что такие есть для счётных задач, но оказывается это правда)

Кластер это программно-аппаратное решение.  Нельзя делать программную
часть в условиях высокой неопределённости относительно того, какой софт
клиенты хотят запускать.

Щиталки всякие проще всего слинковать статически (в родной i586 среде,
а запускать уже на x86_64).

То есть не недо отделываться простым соображением "клиенту надо незнамо
чево, но очень надо".  В ряде случаев возможно существенно более простое
решение, чем biarch (или chroot).

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

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 10:47:42PM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
> > On Sun, Sep 23, 2007 at 09:57:04PM +0400, Dmitry V. Levin wrote:
> >>> Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
> >>> пилить?
> >> Понятное дело, чтобы можно было
> >> 1. gcc -m32 в системе x86_64
> >> 2. использовать результат (1) в системе x86_64
> >> или что-то в этом духе.
> > 
> > Ох.  Можно сделать полностью родной чрут, или даже контейнер.
> > Ведь если речь идет о запуске какого-то условно-серьезного
> > проприетарного софта, то контейтер вовсе даже не помешает.
> 
> Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере 
> из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в 
> этом, а в том, что видимо таких кластеров может быть больше одного.

Для счётнога кластера (где на каждом считающем узле у каждого пользователя
есть аккаунт) мне кажется проще сделать для пользователей отдельно
32-битные и 64-битные аккаунты.


-- 
ldv

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

Re: [devel] biarch

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 10:35:49PM +0400, Anton Farygin wrote:
>> на мой взгляд, можно посмотреть как сделан biarch в SuSE - судя по всему 
>> это всех устраивает.
> 
> Куда посмотреть, как сделано в SuSE?

Хорошего описания я не нашёл, к сожалению ;(

вот всё что есть на сайте:

  4.1. Biarch Systems


The directories like /usr/lib64 and /usr/X11R6/lib64 are used next to 
the usual /usr/lib and /usr/X11R6/lib directories on biarch systems. 
This is because two variants of the same libraries must coexist on such 
systems to allow running both 32-bit and 64-bit applications in 
parallel. The 64-bit libraries are installed in lib64 directories and 
32-bit libraries in the lib directories. The macros 
[[SUSE_Package_Conventions/RPM_Macros#spc_rm_lib %_lib] and 
[spc_rpm_macros.html#spc_rm_libdir %_libdir] do this.

Special packages are created for the biarch systems that include only 
the 32-bit libraries. Any other files are not needed because these 
libraries can use architecture independent files from the 64-bit 
packages. They are even able to execute 64-bit helper binaries. 
Therefore, these are shared as well and are installed into lib on all 
architectures instead (and not %_lib). See the part about --libexecdir 
in the following section.

Видимо всё остальное надо смотреть в пакетах:
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/x86_64/

В частности там лежит пачка пакетов содержащих в имени 32bit.

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
> Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
> мог бы его разработать. Лично мне их аргументы кажутся вполне
> корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
> случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
> возможно) разрулить пересечения по файлам в glibc-core. До этого каких

Вы хотите немало и, кажется, близоруки.  Чтобы заработал gcc -m32,
нужно решить проблему не только с glibc-core, но и с glibc-devel.
Точнее, по сути нужно решить проблему с диспетчеризацией /usr/include.

То есть нужно делать /usr/include64.

Либо требовать, чтобы как минимум в некотором замкнутом подмножестве
базовых *-devel пакетов /usr/include/*.h файлы между архиткетурами не
отличались.  Не знаю пока, насколько это сильное требование.

...

Я знаю: можно сделать suid-хелпер для gcc, который при каждом вызове gcc
делает flock() на дескрипторе каталога /usr и дальше переставляет
/usr/include куда надо. :)

> либо конструктивных предложений вряд ли следует ждать, потому как даже
> попробовать/проверить сложно.
> Кстати, возможно я чего-то не понимаю, но мне очень часто не хватает
> возможности указать архитектуру (обычно noarch) для конкретных
> субпакетов, а не для всех субпакетов глобально.

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

Re: [devel] biarch

[Led]

2007/9/23, Dmitry V. Levin <ldv@altlinux.org>:
> On Sun, Sep 23, 2007 at 10:47:42PM +0400, Anton Farygin wrote:
> > Alexey Tourbin пишет:
> > > On Sun, Sep 23, 2007 at 09:57:04PM +0400, Dmitry V. Levin wrote:
> > >>> Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
> > >>> пилить?
> > >> Понятное дело, чтобы можно было
> > >> 1. gcc -m32 в системе x86_64
> > >> 2. использовать результат (1) в системе x86_64
> > >> или что-то в этом духе.
> > >
> > > Ох.  Можно сделать полностью родной чрут, или даже контейнер.
> > > Ведь если речь идет о запуске какого-то условно-серьезного
> > > проприетарного софта, то контейтер вовсе даже не помешает.
> >
> > Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере
> > из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в
> > этом, а в том, что видимо таких кластеров может быть больше одного.
>
> Для счётнога кластера (где на каждом считающем узле у каждого пользователя
> есть аккаунт) мне кажется проще сделать для пользователей отдельно
> 32-битные и 64-битные аккаунты.

Можно. Но уж точно не "проще".


-- 
Led.

Re: [devel] biarch

[Led]

2007/9/23, Alexey Tourbin <at@altlinux.ru>:
> On Sun, Sep 23, 2007 at 10:47:42PM +0400, Anton Farygin wrote:
> > > Ох.  Можно сделать полностью родной чрут, или даже контейнер.
> > > Ведь если речь идет о запуске какого-то условно-серьезного
> > > проприетарного софта, то контейтер вовсе даже не помешает.
> >
> > Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере
> > из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в
> > этом, а в том, что видимо таких кластеров может быть больше одного.
> >
> > И пользователей, запускающих софт на этом кластере тоже будет ой как
> > много... а запускать они будут в том числе и 32-х битные приложения (я
> > сам не ожидал, что такие есть для счётных задач, но оказывается это правда)
>
> Кластер это программно-аппаратное решение.  Нельзя делать программную
> часть в условиях высокой неопределённости относительно того, какой софт
> клиенты хотят запускать.
>
> Щиталки всякие проще всего слинковать статически (в родной i586 среде,
> а запускать уже на x86_64).

"Считалки" могут стоить сотни тысяч $ и "уже слинкованыдо нас" и
"перелинковать" не получится. запускать же их в чистом x86_32 - в
большинстве случаев очень невыгодно.

> То есть не недо отделываться простым соображением "клиенту надо незнамо
> чево, но очень надо".  В ряде случаев возможно существенно более простое
> решение, чем biarch (или chroot).

Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
-m32 и возможность параллельной установки 32-битной glibc

-- 
Led.

Re: [devel] biarch

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
>> Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
>> мог бы его разработать. Лично мне их аргументы кажутся вполне
>> корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
>> случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
>> возможно) разрулить пересечения по файлам в glibc-core. До этого каких
> 
> Вы хотите немало и, кажется, близоруки.  Чтобы заработал gcc -m32,
> нужно решить проблему не только с glibc-core, но и с glibc-devel.
> Точнее, по сути нужно решить проблему с диспетчеризацией /usr/include.
> 
> То есть нужно делать /usr/include64.
> 
> Либо требовать, чтобы как минимум в некотором замкнутом подмножестве
> базовых *-devel пакетов /usr/include/*.h файлы между архиткетурами не
> отличались.  Не знаю пока, насколько это сильное требование.

Алексей, не пугай людей - хедеры ложаться на biarch, без всяких 
include32/include64. По крайней мере хедеры чдра, подозреваю что и glibc 
тоже.

> 
> ...
> 
> Я знаю: можно сделать suid-хелпер для gcc, который при каждом вызове gcc
> делает flock() на дескрипторе каталога /usr и дальше переставляет
> /usr/include куда надо. :)

;)

> 
>> либо конструктивных предложений вряд ли следует ждать, потому как даже
>> попробовать/проверить сложно.
>> Кстати, возможно я чего-то не понимаю, но мне очень часто не хватает
>> возможности указать архитектуру (обычно noarch) для конкретных
>> субпакетов, а не для всех субпакетов глобально.

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 10:06:55PM +0300, Led wrote:
> > То есть не недо отделываться простым соображением "клиенту надо незнамо
> > чево, но очень надо".  В ряде случаев возможно существенно более простое
> > решение, чем biarch (или chroot).
> 
> Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
> -m32 и возможность параллельной установки 32-битной glibc

Статически слинковать можно в родной среде.  Это если речь идет
о поддержке этого кластера как программно-аппаратного комплекса.
А клиентам выдать уже готовый статический бинарь.

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

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 11:01:36PM +0400, Alexey Tourbin wrote:
> On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
> > Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
> > мог бы его разработать. Лично мне их аргументы кажутся вполне
> > корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
> > случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
> > возможно) разрулить пересечения по файлам в glibc-core. До этого каких
> 
> Вы хотите немало и, кажется, близоруки.  Чтобы заработал gcc -m32,
> нужно решить проблему не только с glibc-core, но и с glibc-devel.

С glibc-devel задача решаема ifdef'ами на уровне самого glibc-devel.
Так делает upstream, насколько я помню.
С /usr/include/{linux,asm} задача решается аналогично.

> Точнее, по сути нужно решить проблему с диспетчеризацией /usr/include.
> 
> То есть нужно делать /usr/include64.

В этом нет необходимости, достаточно отделять архитектурно-зависимые части
от остальных и добавлять ifdef'ы по мере необходимости.
Поскольку всеобщий biarch никому всерьёз не нужен, добавлять ifdef'ы можно
постепенно.  Насколько я понимаю, готовые патчи уже есть в FC.


-- 
ldv

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

Re: [devel] biarch

[Anton Farygin]

Dmitry V. Levin пишет:
> On Sun, Sep 23, 2007 at 10:47:42PM +0400, Anton Farygin wrote:
>> Alexey Tourbin пишет:
>>> On Sun, Sep 23, 2007 at 09:57:04PM +0400, Dmitry V. Levin wrote:
>>>>> Я ничего пилить не буду.  Собственно, с какой стати мы собираемся что-то
>>>>> пилить?
>>>> Понятное дело, чтобы можно было
>>>> 1. gcc -m32 в системе x86_64
>>>> 2. использовать результат (1) в системе x86_64
>>>> или что-то в этом духе.
>>> Ох.  Можно сделать полностью родной чрут, или даже контейнер.
>>> Ведь если речь идет о запуске какого-то условно-серьезного
>>> проприетарного софта, то контейтер вовсе даже не помешает.
>> Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере 
>> из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в 
>> этом, а в том, что видимо таких кластеров может быть больше одного.
> 
> Для счётнога кластера (где на каждом считающем узле у каждого пользователя
> есть аккаунт) мне кажется проще сделать для пользователей отдельно
> 32-битные и 64-битные аккаунты.

Нет, архитектура там несколько иная - есть диспетчер задач, который 
стартует расчёты с одной машины.

И всё становится намного хуже, когда начинается GRID.

Re: [devel] biarch

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 10:47:42PM +0400, Anton Farygin wrote:
>>> Ох.  Можно сделать полностью родной чрут, или даже контейнер.
>>> Ведь если речь идет о запуске какого-то условно-серьезного
>>> проприетарного софта, то контейтер вовсе даже не помешает.
>> Понимаешь в чём проблема.. в общем биарч понадобился на счётном кластере 
>> из ~2000 машин. и в этом основная проблема. Точнее даже проблема не в 
>> этом, а в том, что видимо таких кластеров может быть больше одного.
>>
>> И пользователей, запускающих софт на этом кластере тоже будет ой как 
>> много... а запускать они будут в том числе и 32-х битные приложения (я 
>> сам не ожидал, что такие есть для счётных задач, но оказывается это правда)
> 
> Кластер это программно-аппаратное решение.  Нельзя делать программную
> часть в условиях высокой неопределённости относительно того, какой софт
> клиенты хотят запускать.

Интересно, а чем мы тут в Devel занимаемся, делая дистрибутив 
опреационной системы ?


> 
> Щиталки всякие проще всего слинковать статически (в родной i586 среде,
> а запускать уже на x86_64).

А есть возможность долинковать уже скомпилированный бинарник ?

> 
> То есть не недо отделываться простым соображением "клиенту надо незнамо
> чево, но очень надо".  В ряде случаев возможно существенно более простое
> решение, чем biarch (или chroot).


Если была бы статика - никаких проблем.

[devel] biarch: runtime vs devel

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 11:15:36PM +0400, Dmitry V. Levin wrote:
> On Sun, Sep 23, 2007 at 11:01:36PM +0400, Alexey Tourbin wrote:
> > On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
> > > Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
> > > мог бы его разработать. Лично мне их аргументы кажутся вполне
> > > корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
> > > случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
> > > возможно) разрулить пересечения по файлам в glibc-core. До этого каких
> > 
> > Вы хотите немало и, кажется, близоруки.  Чтобы заработал gcc -m32,
> > нужно решить проблему не только с glibc-core, но и с glibc-devel.
> 
> С glibc-devel задача решаема ifdef'ами на уровне самого glibc-devel.
> Так делает upstream, насколько я помню.
> С /usr/include/{linux,asm} задача решается аналогично.

Хорошо.  Но ВСЁ-ТАКИ базовая РАНТАЙМ-поддержка и базовая СБОРОЧНАЯ
поддержка -- это два разных взгляда на biarch.

Базовую рантайм-поддержку можно легко обеспечить, просто скопировав
несколько файлов в /lib/.  И всё.  А если хочется ещё и полноценно
компилировать... в общем, губа не дура.

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

Re: [devel] biarch

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 10:06:55PM +0300, Led wrote:
>>> То есть не недо отделываться простым соображением "клиенту надо незнамо
>>> чево, но очень надо".  В ряде случаев возможно существенно более простое
>>> решение, чем biarch (или chroot).
>> Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
>> -m32 и возможность параллельной установки 32-битной glibc
> 
> Статически слинковать можно в родной среде.  Это если речь идет
> о поддержке этого кластера как программно-аппаратного комплекса.
> А клиентам выдать уже готовый статический бинарь.

Алексей, разве существует возможность долинковать динамически 
слинкованный бинарь статическими библиотеками ?

Re: [devel] biarch

[Alexey I. Froloff]

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

* Anton Farygin <rider@> [070923 23:19]:
> > Кластер это программно-аппаратное решение.  Нельзя делать программную
> > часть в условиях высокой неопределённости относительно того, какой софт
> > клиенты хотят запускать.
> Интересно, а чем мы тут в Devel занимаемся, делая дистрибутив 
> опреационной системы ?
Делаем дистрибутив операционной системы для запуска собранного
для этого дистрибутива ПО.  То что там работает ещё что-то - есть
большое Чудо.

-- 
Regards,
Sir Raorn.

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

Re: [devel] biarch: runtime vs devel

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 11:15:36PM +0400, Dmitry V. Levin wrote:
>> On Sun, Sep 23, 2007 at 11:01:36PM +0400, Alexey Tourbin wrote:
>>> On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
>>>> Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
>>>> мог бы его разработать. Лично мне их аргументы кажутся вполне
>>>> корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
>>>> случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
>>>> возможно) разрулить пересечения по файлам в glibc-core. До этого каких
>>> Вы хотите немало и, кажется, близоруки.  Чтобы заработал gcc -m32,
>>> нужно решить проблему не только с glibc-core, но и с glibc-devel.
>> С glibc-devel задача решаема ifdef'ами на уровне самого glibc-devel.
>> Так делает upstream, насколько я помню.
>> С /usr/include/{linux,asm} задача решается аналогично.
> 
> Хорошо.  Но ВСЁ-ТАКИ базовая РАНТАЙМ-поддержка и базовая СБОРОЧНАЯ
> поддержка -- это два разных взгляда на biarch.

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

> 
> Базовую рантайм-поддержку можно легко обеспечить, просто скопировав
> несколько файлов в /lib/.  И всё.  А если хочется ещё и полноценно
> компилировать... в общем, губа не дура.

Компилировать надо, если есть необходимость собирать 32bit на x86_64. 
Часть приложений, к сожалению, даже свободные - невозможно собрать на 
x86_64 без -m32.

Спасибо авторам lilo, за то, что их загрузчик без проблем собирается на 
x86_64 без -m32, что нельзя сказать о grub ;(

Или wine, умеющем запускать 32-битные программы.

Re: [devel] biarch

[Anton Farygin]

Alexey I. Froloff пишет:
> * Anton Farygin <rider@> [070923 23:19]:
>>> Кластер это программно-аппаратное решение.  Нельзя делать программную
>>> часть в условиях высокой неопределённости относительно того, какой софт
>>> клиенты хотят запускать.
>> Интересно, а чем мы тут в Devel занимаемся, делая дистрибутив 
>> опреационной системы ?
> Делаем дистрибутив операционной системы для запуска собранного
> для этого дистрибутива ПО.  То что там работает ещё что-то - есть
> большое Чудо.

Хорошо что это Чудо случилось, а то так и сидеть бы большинству наших 
пользователей (и мантейнеров) без 3D на своих nVidia/AMDTI видюхах...

приятно творить Чудеса ;)

Re: [devel] biarch

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1295 bytes --]

On Sun, Sep 23, 2007 at 11:21:06PM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
> > On Sun, Sep 23, 2007 at 10:06:55PM +0300, Led wrote:
> >>> То есть не недо отделываться простым соображением "клиенту надо незнамо
> >>> чево, но очень надо".  В ряде случаев возможно существенно более простое
> >>> решение, чем biarch (или chroot).
> >> Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
> >> -m32 и возможность параллельной установки 32-битной glibc
> > 
> > Статически слинковать можно в родной среде.  Это если речь идет
> > о поддержке этого кластера как программно-аппаратного комплекса.
> > А клиентам выдать уже готовый статический бинарь.
> 
> Алексей, разве существует возможность долинковать динамически 
> слинкованный бинарь статическими библиотеками ?

Хорошо. Надежного способа сделать этого нет.

Но чтобы обеспечить базовую рантайм-поддержку x86 софта, достаточно
ВСЕГО ЛИШЬ скопировать несколько файлов в /lib/.  Можно даже для этого
псевдо-собрать rpm-пакет.  Для этого не нужно переделывать весь
репозитарий.

Вот образец spec-файла.

Если же клиенты хотят ещё и КОМПИЛИРОВАТЬ софт под x86, потому что он
у них не работает под x86_64, то это совсем другая постановка задачи,
из-за которой смета проекта может возрасти. :)

[-- Attachment #1.2: rider-biarch.spec --]
[-- Type: text/plain, Size: 286 bytes --]

Name: rider-biarch
Version: 0.1
Release: alt1

Summary: biarch support for rider projects
License: GPL
Group: System/Libraries

%description
%summary.

%install
copy() { install -pD $1 %buildroot$1; }
copy /lib/ld-linux.so.2
copy /lib/libc.so.6
copy /lib/libpthread.so.0

%files
/lib/*

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

Re: [devel] biarch

[Led]

2007/9/23, Alexey Tourbin <at@altlinux.ru>:
> On Sun, Sep 23, 2007 at 10:06:55PM +0300, Led wrote:
> > > То есть не недо отделываться простым соображением "клиенту надо незнамо
> > > чево, но очень надо".  В ряде случаев возможно существенно более простое
> > > решение, чем biarch (или chroot).
> >
> > Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
> > -m32 и возможность параллельной установки 32-битной glibc
>
> Статически слинковать можно в родной среде.  Это если речь идет
> о поддержке этого кластера как программно-аппаратного комплекса.
> А клиентам выдать уже готовый статический бинарь.

Ещё раз: "считалка" стоит несколько сотен тысяч $, исходников нет. Как
"Статически слинковать можно в родной среде"? при том, что для
"точечных" 32-битных пакетов в x86_64-среде, при возможности
слинковать статически, это ИМХО лучший вариант. Но даже в этом случае
не хотелось бы ликовать статически ещё с libc.

-- 
Led.

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 11:27:50PM +0400, Alexey Tourbin wrote:
> On Sun, Sep 23, 2007 at 11:21:06PM +0400, Anton Farygin wrote:
> > Alexey Tourbin пишет:
> > > On Sun, Sep 23, 2007 at 10:06:55PM +0300, Led wrote:
> > >>> То есть не недо отделываться простым соображением "клиенту надо незнамо
> > >>> чево, но очень надо".  В ряде случаев возможно существенно более простое
> > >>> решение, чем biarch (или chroot).
> > >> Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
> > >> -m32 и возможность параллельной установки 32-битной glibc
> > > 
> > > Статически слинковать можно в родной среде.  Это если речь идет
> > > о поддержке этого кластера как программно-аппаратного комплекса.
> > > А клиентам выдать уже готовый статический бинарь.
> > 
> > Алексей, разве существует возможность долинковать динамически 
> > слинкованный бинарь статическими библиотеками ?
> 
> Хорошо. Надежного способа сделать этого нет.
> 
> Но чтобы обеспечить базовую рантайм-поддержку x86 софта, достаточно
> ВСЕГО ЛИШЬ скопировать несколько файлов в /lib/.  Можно даже для этого
> псевдо-собрать rpm-пакет.  Для этого не нужно переделывать весь
> репозитарий.
> Вот образец spec-файла.

Таким путём тоже кто-то идёт.  Нпример, в Debian так раньше делали.

> Если же клиенты хотят ещё и КОМПИЛИРОВАТЬ софт под x86, потому что он
> у них не работает под x86_64, то это совсем другая постановка задачи,
> из-за которой смета проекта может возрасти. :)

Причём размер сметы зависит от количества разных -lFOO.


-- 
ldv

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

Re: [devel] biarch

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Sep 23, 2007 at 11:21:06PM +0400, Anton Farygin wrote:
>> Alexey Tourbin пишет:
>>> On Sun, Sep 23, 2007 at 10:06:55PM +0300, Led wrote:
>>>>> То есть не недо отделываться простым соображением "клиенту надо незнамо
>>>>> чево, но очень надо".  В ряде случаев возможно существенно более простое
>>>>> решение, чем biarch (или chroot).
>>>> Чтоб это "более простое решение" появилось, нужно, как минимум, gcc
>>>> -m32 и возможность параллельной установки 32-битной glibc
>>> Статически слинковать можно в родной среде.  Это если речь идет
>>> о поддержке этого кластера как программно-аппаратного комплекса.
>>> А клиентам выдать уже готовый статический бинарь.
>> Алексей, разве существует возможность долинковать динамически 
>> слинкованный бинарь статическими библиотеками ?
> 
> Хорошо. Надежного способа сделать этого нет.
> 
> Но чтобы обеспечить базовую рантайм-поддержку x86 софта, достаточно
> ВСЕГО ЛИШЬ скопировать несколько файлов в /lib/.  Можно даже для этого
> псевдо-собрать rpm-пакет.  Для этого не нужно переделывать весь
> репозитарий.
> 
> Вот образец spec-файла.
> 
> Если же клиенты хотят ещё и КОМПИЛИРОВАТЬ софт под x86, потому что он
> у них не работает под x86_64, то это совсем другая постановка задачи,
> из-за которой смета проекта может возрасти. :)

с жтим я целиком согласен, в SuSE примерно так и делают, только у них 
biarch ещё и компилировать умеет.

А вот что будет с rpm'ом и apt'ом при таком пакете ?

Re: [devel] biarch: runtime vs devel

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 11:25:14PM +0400, Anton Farygin wrote:
> > Хорошо.  Но ВСЁ-ТАКИ базовая РАНТАЙМ-поддержка и базовая СБОРОЧНАЯ
> > поддержка -- это два разных взгляда на biarch.
> 
> Безусловно, но для того, что бы корректно получить рантайм поддержку - 
> необходимо как минимум собрать этот набор нужных библиотек в пакеты.

Корректно это зависит от задачи.  Для запуска проприетарного софта я не
вижу ничего дурного в том, чтобы просто скопировать несколько файлов
из /lib/ на i586 системе в /lib/ на x86_64 системе.

Не нужно переделывать репозитарий там, где его можно не переделывать.

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

Re: [devel] biarch

[Alexey Tourbin]

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

On Sun, Sep 23, 2007 at 11:34:13PM +0400, Anton Farygin wrote:
> > Если же клиенты хотят ещё и КОМПИЛИРОВАТЬ софт под x86, потому что он
> > у них не работает под x86_64, то это совсем другая постановка задачи,
> > из-за которой смета проекта может возрасти. :)
> 
> с жтим я целиком согласен, в SuSE примерно так и делают, только у них 
> biarch ещё и компилировать умеет.
> 
> А вот что будет с rpm'ом и apt'ом при таком пакете ?

А ничего не будет.

--- rider-biarch.spec-	2007-09-23 19:39:44 +0000
+++ rider-biarch.spec	2007-09-23 19:38:49 +0000
@@ -6,6 +6,11 @@ Summary: biarch support for rider projec
 License: GPL
 Group: System/Libraries
 
+BuildArch: noarch
+ExclusiveArch: %ix86
+AutoProv: yes, nolib
+%set_verify_elf_method arch=relaxed
+
 %description
 %summary.
 

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

Re: [devel] biarch

[Dmitry V. Levin]

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

On Sun, Sep 23, 2007 at 11:34:13PM +0400, Anton Farygin wrote:
> Alexey Tourbin пишет:
> > On Sun, Sep 23, 2007 at 11:21:06PM +0400, Anton Farygin wrote:
[...]
> > Если же клиенты хотят ещё и КОМПИЛИРОВАТЬ софт под x86, потому что он
> > у них не работает под x86_64, то это совсем другая постановка задачи,
> > из-за которой смета проекта может возрасти. :)
> 
> с жтим я целиком согласен, в SuSE примерно так и делают, только у них 
> biarch ещё и компилировать умеет.
> 
> А вот что будет с rpm'ом и apt'ом при таком пакете ?

Если по методу SuSE (битность включается в имя бинарного пакета) или по
методу Debian (специальный бинарный псевдопакет), то apt/rpm трогать не
придётся.  Если нужно сделать что-то одноразовое, то этот вариант
предпочтительнее.


-- 
ldv

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

Re: [devel] biarch

[Alexey I. Froloff]

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

* Led <led@> [070923 23:39]:
> Ещё раз: "считалка" стоит несколько сотен тысяч $, исходников нет.
Значит это проблема конкретной "считалки за несколько сотен тысяч
$".  Дешевле и быстрее придумать решение для неё, чем пытаться
вывести сферического коня в жидком вакууме.  Нет?

-- 
Regards,
Sir Raorn.

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

Re: [devel] biarch

[Led]

2007/9/23, Alexey I. Froloff <raorn@immo.ru>:
> * Led <led@> [070923 23:39]:
> > Ещё раз: "считалка" стоит несколько сотен тысяч $, исходников нет.
> Значит это проблема конкретной "считалки за несколько сотен тысяч
> $".  Дешевле и быстрее придумать решение для неё, чем пытаться
> вывести сферического коня в жидком вакууме.  Нет?

Ну, если -m32 и возможность безболезненного наличия 32-битной libc в
x86_64-системе - это "сферический конь в жидком вакууме", тогда
действительно эта тема была поднята зря и мне действтительно "Дешевле
и быстрее придумать решение для неё":)

-- 
Led.

Re: [devel] I: Новый rpm.

[Michael Shigorin]

On Sun, Sep 23, 2007 at 05:52:45PM +0400, Alexey Tourbin wrote:
> Там предлагают сделать /bin64, что, как мне кажется, в обозримом
> будущем совершенно нереально.  Бодяги с %_libdir уже всем хватило.

Это раз, и два -- место сзади трамвая закрашивается таки для
_негров_, бишь bin32, раз на то пошло.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Anton Farygin]

Dmitry V. Levin пишет:
> On Sun, Sep 23, 2007 at 11:34:13PM +0400, Anton Farygin wrote:
>> Alexey Tourbin пишет:
>>> On Sun, Sep 23, 2007 at 11:21:06PM +0400, Anton Farygin wrote:
> [...]
>>> Если же клиенты хотят ещё и КОМПИЛИРОВАТЬ софт под x86, потому что он
>>> у них не работает под x86_64, то это совсем другая постановка задачи,
>>> из-за которой смета проекта может возрасти. :)
>> с жтим я целиком согласен, в SuSE примерно так и делают, только у них 
>> biarch ещё и компилировать умеет.
>>
>> А вот что будет с rpm'ом и apt'ом при таком пакете ?
> 
> Если по методу SuSE (битность включается в имя бинарного пакета) или по
> методу Debian (специальный бинарный псевдопакет), то apt/rpm трогать не
> придётся.  Если нужно сделать что-то одноразовое, то этот вариант
> предпочтительнее.

apt/rpm видимо трогать всё-таки придётся, иначе может где-то разползтись 
с provides/requires ? или текущего поведения apt'а будет достаточно ?

Re: [devel] biarch

[Alexander Bokovoy]

Alexey I. Froloff wrote:
> * Led <led@> [070923 23:39]:
>> Ещё раз: "считалка" стоит несколько сотен тысяч $, исходников нет.
> Значит это проблема конкретной "считалки за несколько сотен тысяч
> $".  Дешевле и быстрее придумать решение для неё, чем пытаться
> вывести сферического коня в жидком вакууме.  Нет?
Два комментария (не тебе напрямую, но раз уж ты поднял тему "проблемы"...):
1. Проблемы с закрытым софтом в считальных кластерах не существует, 
существует лишь недопонимание возможностей систем реализаторами таких 
кластеров. В частности, менеджеры ресурсов в кластерных расчетах сегодня 
достаточно гибки, чтобы запускать то, что надо и ставить соответствующие 
переменные окружения.

2. Правильное поведение при запуске исполняемых файлов в любой системе 
еще никто не отменял: сделать старт эмуляции elf-i386 на x86_64 не 
сложнее, чем старт эмуляции elf-i386 на ppc64б binfmt_misc еще никто не 
отменял.

Поэтому конкретная задача с гипотетическими кластерами решается и 
решается значительно проще, чем создание полноценного biarch. Если кому 
хочется подробностей -- предлагаю воспоследовать за предложением 
Турбина, но уже ко мне. :-)

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] biarch

[Serge Ryabchun]

23.09.07, Alexander Bokovoy<ab@altlinux.org> написал(а):
> 1. Проблемы с закрытым софтом в считальных кластерах не существует,
> существует лишь недопонимание возможностей систем реализаторами таких
> кластеров. В частности, менеджеры ресурсов в кластерных расчетах сегодня
> достаточно гибки, чтобы запускать то, что надо и ставить соответствующие
> переменные окружения.

Попробуйте поставить на 64-битном Альте
http://registrationcenter-download.intel.com/irc_nas/786/l_cc_c_10.0.026_intel64.tar.gz

# file data/chklic.em64t
data/chklic.em64t: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5,
stripped

и внутри у него тоже
# file iccbin
iccbin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not
stripped

Конечно, проблемы с закрытым софтом не существует. Просто на
числодробилках стоят RH, CentOS, SUSE, но не стоит ALT.

Re: [devel] biarch

[Konstantin A. Lepikhov]

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

Hi Led!

Sunday 23, at 09:50:16 PM you wrote:

...
> Судя по всему, разработка "плана biarch" вызывает неприятие у тех, кто
> мог бы его разработать. Лично мне их аргументы кажутся вполне
> корретными и обоснованными, но, к сожалению, неприемлимыми. В таком
> случае, хотелось  бы получить хотя-бы -m32 в gcc и, при (если
> возможно) разрулить пересечения по файлам в glibc-core. До этого каких
> либо конструктивных предложений вряд ли следует ждать, потому как даже
> попробовать/проверить сложно.
у ядерщиков -m32 работает уже давно ;)))

-- 
WBR et al.

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

Re: [devel] biarch

[Alexander Bokovoy]

Serge Ryabchun wrote:
> 23.09.07, Alexander Bokovoy<ab@altlinux.org> написал(а):
>> 1. Проблемы с закрытым софтом в считальных кластерах не существует,
>>  существует лишь недопонимание возможностей систем реализаторами
>> таких кластеров. В частности, менеджеры ресурсов в кластерных
>> расчетах сегодня достаточно гибки, чтобы запускать то, что надо и
>> ставить соответствующие переменные окружения.
> 
> Попробуйте поставить на 64-битном Альте 
> http://registrationcenter-download.intel.com/irc_nas/786/l_cc_c_10.0.026_intel64.tar.gz
> 
> 
> # file data/chklic.em64t data/chklic.em64t: ELF 32-bit LSB
> executable, Intel 80386, version 1 (SYSV), dynamically linked (uses
> shared libs), for GNU/Linux 2.2.5, stripped
> 
> и внутри у него тоже # file iccbin iccbin: ELF 32-bit LSB executable,
> Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs),
> for GNU/Linux 2.2.5, not stripped
> 
> Конечно, проблемы с закрытым софтом не существует. Просто на 
> числодробилках стоят RH, CentOS, SUSE, но не стоит ALT.
Отлично, и что Вы этим мне хотите доказать? Я утверждаю, что
инфраструктуру для работы вот с такими можно сделать, а не то, что она
уже есть. Причем сделать можно, не перелопачивая все остальные пакеты.
Перечитайте внимательно то, что я писал.

Софта вроде этого я встречал много. Чего стоят, например, ландмарковские 
считалки, собранные почти целиком в 64-бит, за исключением 32-битного 
PVM. Или там же инсталятора на tcl/tk, 32-битного, который на 
стандартный официально поддерживаемый RHEL x86_64 не устанавливается.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [devel] biarch

[Kirill A. Shutemov]

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

On [Sun, 23.09.2007 22:35], Anton Farygin wrote:
> Dmitry V. Levin пишет:
> > On Sun, Sep 23, 2007 at 10:09:09PM +0400, Anton Farygin wrote:
> >> Aleksey Novodvorsky пишет:
> >>> On 9/23/07, Alexey I. Froloff wrote:
> >>>> * Dmitry V. Levin <ldv@> [070923 19:45]:
> >>>> [..skip..]
> >>>>> Вопрос: будем пилить все такие пакеты, или есть варианты получше?
> >>>> Может чрут?  Что-то многовато бесполезной работы для двух-трёх
> >>>> кривософтин, девелоперы которых ниасилили сборку под 64 бита...
> >>> +1
> >> Алексей, у нас возникла реальная необходимость в biarch на одном из 
> >> проектов.. чрут там не поможет - задача куче пользователей (их может 
> >> быть 100, а может быть несколько десятков тысяч) запускать ПО из 
> >> домашнего каталога.
> >>
> >> И не факт что данное ПО будет свободное, и тем более - для x86_64.
> >>
> >> С предложением городить чрут или LD_LIBRARY_PATH каждому пользователю 
> >> ... в общем не буду дословно пересказывать всё, что я слышал, там не всё 
> >> цензурно.
> > 
> > И чего им нужно?  Чтобы "просто всё работало как ни в чём не бывало,
> > словно это одна архитектура"?  Думаю что в такой постановке задачи достичь
> > желаемого результата нереально.  Антон, если ты рассчитываешь на
> > коллективное обсуждение, надо рассказать несколько больше.
> 
> Уже говорилось, но повторю:
> первое что нужно клиентам - это запуск всякой проприетарщины, 
> отсутствующей не x86_64. Как правило эта проприетарщина ничего 
> серьёзного не тянет, но glibc ей нужен в любом случае.

binfmt_misc + LD_LIBRARY_PATH не покатит?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + Velesys LLC, http://www.velesys.com/
 + ALT Linux Team, http://www.altlinux.com/

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

Re: [devel] biarch

[Michael Shigorin]

On Sun, Sep 23, 2007 at 10:09:09PM +0400, Anton Farygin wrote:
> И не факт что данное ПО будет свободное, и тем более - для x86_64.

При этом нужно x86_64?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Michael Shigorin]

On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
> Кстати, возможно я чего-то не понимаю, но мне очень часто не
> хватает возможности указать архитектуру (обычно noarch) для
> конкретных субпакетов, а не для всех субпакетов глобально.

Это конструктивное ограничение в RPM (4?).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070923 23:30]:
> Но чтобы обеспечить базовую рантайм-поддержку x86 софта, достаточно
> ВСЕГО ЛИШЬ скопировать несколько файлов в /lib/.  Можно даже для этого
> псевдо-собрать rpm-пакет.  Для этого не нужно переделывать весь
> репозитарий.
Интересно, а grub так можно собрать?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] biarch

[Michael Shigorin]

On Sun, Sep 23, 2007 at 10:53:16PM +0400, Alexey Tourbin wrote:
> Щиталки всякие проще всего слинковать статически (в родной i586
> среде, а запускать уже на x86_64).

Кстати, недавно очередная автолинковалка пробегала на манер
того же http://statifier.sourceforge.net.  Только для кластеров
это не сильно похоже не выход.

> То есть не недо отделываться простым соображением "клиенту надо
> незнамо чево, но очень надо".  В ряде случаев возможно
> существенно более простое решение, чем biarch (или chroot).

...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Michael Shigorin]

On Sun, Sep 23, 2007 at 11:14:05PM +0400, Alexey Tourbin wrote:
> Статически слинковать можно в родной среде.  Это если речь идет
> о поддержке этого кластера как программно-аппаратного комплекса.
> А клиентам выдать уже готовый статический бинарь.

Сервис вполне может быстро оказаться дороже RHEL
(тем более CentOS с парой RHEL заради возможности дёргать).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Michael Shigorin]

On Sun, Sep 23, 2007 at 11:42:00PM +0400, Dmitry V. Levin wrote:
> > А вот что будет с rpm'ом и apt'ом при таком пакете ?
> Если по методу SuSE (битность включается в имя бинарного
> пакета) или по методу Debian (специальный бинарный
> псевдопакет), то apt/rpm трогать не придётся.

Вот это и похоже на разумный (главное -- реализуемый в разумные
сроки, с учётом перспективы) вариант.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Serge Ryabchun]

24.09.07, Alexander Bokovoy<ab@altlinux.org> написал(а):
> Serge Ryabchun wrote:
> > 23.09.07, Alexander Bokovoy<ab@altlinux.org> написал(а):
> >> 1. Проблемы с закрытым софтом в считальных кластерах не существует,
> >>  существует лишь недопонимание возможностей систем реализаторами
> >> таких кластеров. В частности, менеджеры ресурсов в кластерных
> >> расчетах сегодня достаточно гибки, чтобы запускать то, что надо и
> >> ставить соответствующие переменные окружения.
> >
> > Попробуйте поставить на 64-битном Альте
> > http://registrationcenter-download.intel.com/irc_nas/786/l_cc_c_10.0.026_intel64.tar.gz
> >
> >
> > # file data/chklic.em64t data/chklic.em64t: ELF 32-bit LSB
> > executable, Intel 80386, version 1 (SYSV), dynamically linked (uses
> > shared libs), for GNU/Linux 2.2.5, stripped
> >
> > и внутри у него тоже # file iccbin iccbin: ELF 32-bit LSB executable,
> > Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs),
> > for GNU/Linux 2.2.5, not stripped
> >
> > Конечно, проблемы с закрытым софтом не существует. Просто на
> > числодробилках стоят RH, CentOS, SUSE, но не стоит ALT.
> Отлично, и что Вы этим мне хотите доказать? Я утверждаю, что
> инфраструктуру для работы вот с такими можно сделать, а не то, что она
> уже есть. Причем сделать можно, не перелопачивая все остальные пакеты.
> Перечитайте внимательно то, что я писал.

Всего навсего то, что сбрасывать на администратора решение возможных
проблем неправильно. То, что на коленке можно много чего привинтить к
манагеру ресурсов, совсем не означает что на каждый чих требуется сооружать
свой чрут, впс или еще чего-нибудь. После решения второй проблемы такая
система будет послана в лес партизанить и вместо нее будет поставлено что-то
вменяемое с биарчем.
Я еще дома могу мириться, что в ящике с инструментами у меня все ключи на M64
и с тем, что M32 приходится пасатижами закручивать, а шурупы загонять молотком.
А там, где мне деньги плотють я возьму другой ящик с инструментами.

Re: [devel] biarch

[Motsyo Gennadi aka Drool]

Michael Shigorin пишет:
> On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
>> Кстати, возможно я чего-то не понимаю, но мне очень часто не
>> хватает возможности указать архитектуру (обычно noarch) для
>> конкретных субпакетов, а не для всех субпакетов глобально.
> 
> Это конструктивное ограничение в RPM (4?).

	А можна наивный вопрос? Биарч настолько нужен? Это ведь загромождение 
системы библиотеками под две архитектуры, и как следствие раздутие 
системы. Я не прав?

Re: [devel] biarch

[Anton Farygin]

Alexey I. Froloff пишет:
> * Alexey Tourbin <at@> [070923 23:30]:
>> Но чтобы обеспечить базовую рантайм-поддержку x86 софта, достаточно
>> ВСЕГО ЛИШЬ скопировать несколько файлов в /lib/.  Можно даже для этого
>> псевдо-собрать rpm-пакет.  Для этого не нужно переделывать весь
>> репозитарий.
> Интересно, а grub так можно собрать?

Можно.

Запаковать glibc-32bit и grub-32bit для x86_64.

т.е. - собрать не получится, получится запаковать.

Re: [devel] biarch

[Aleksey Novodvorsky]

On 9/24/07, Motsyo Gennadi aka Drool <motsyo@gmail.com> wrote:
> Michael Shigorin пишет:
> > On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
> >> Кстати, возможно я чего-то не понимаю, но мне очень часто не
> >> хватает возможности указать архитектуру (обычно noarch) для
> >> конкретных субпакетов, а не для всех субпакетов глобально.
> >
> > Это конструктивное ограничение в RPM (4?).
>
>         А можна наивный вопрос? Биарч настолько нужен? Это ведь загромождение
> системы библиотеками под две архитектуры, и как следствие раздутие
> системы. Я не прав?

Правы. Но для некоторых проектов нужен критически.

Rgrds, Алексей

Re: [devel] biarch

[Alexey Morsov]

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

On Mon, Sep 24, 2007 at 01:48:32PM +0400, Aleksey Novodvorsky wrote:
> 
> Правы. Но для некоторых проектов нужен критически.
Причем проектов которым нужно gcc -m32.
Потому как тут правильно уже высказались - для запуска очереднйо
проприертарной поделки в 100 раз проще кинуть 32битну glibc в /lib (или
даже в /opt/lib) чем курочить систему.

-- 

С уважением,
Алексей Морсов
программист ЗАО "ИК "Риком-Траст"

Jabber: samurai@www.fondmarket.ru
www.ricom.ru
www.fondmarket.ru

NP: Dreams of Sanity - The empress - Through the looking glass (a dream)


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

Re: [devel] biarch

[Serge Ryabchun]

24.09.07, Alexey Morsov<samurai@ricom.ru> написал(а):
> On Mon, Sep 24, 2007 at 01:48:32PM +0400, Aleksey Novodvorsky wrote:
> >
> > Правы. Но для некоторых проектов нужен критически.
> Причем проектов которым нужно gcc -m32.
> Потому как тут правильно уже высказались - для запуска очереднйо
> проприертарной поделки в 100 раз проще кинуть 32битну glibc в /lib (или
> даже в /opt/lib) чем курочить систему.

Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
снести Альт

Re: [devel] biarch

[Alexey Morsov]

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

On Mon, Sep 24, 2007 at 01:40:10PM +0300, Serge Ryabchun wrote:
> 
> Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
> снести Альт
Ну у меня вот на ALS4 asa9 крутится, еще и через альтератор
запускается\останаливается. 
А "клевые" RH-сотоварищи ничего кроме жедлания плеваться не вызывают.

<flame>
биарч не нужен
</flame>

-- 

С уважением,
Алексей Морсов
программист ЗАО "ИК "Риком-Траст"

Jabber: samurai@www.fondmarket.ru
www.ricom.ru
www.fondmarket.ru

NP: Dreams of Sanity - The creature that you came to see... (reprise)


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

Re: [devel] biarch

[Led]

В сообщении от Monday 24 September 2007 13:59:12 Alexey Morsov написал(а):
> On Mon, Sep 24, 2007 at 01:40:10PM +0300, Serge Ryabchun wrote:
> > Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
> > снести Альт
>
> Ну у меня вот на ALS4 asa9 крутится, еще и через альтератор
> запускается\останаливается.
> А "клевые" RH-сотоварищи ничего кроме жедлания плеваться не вызывают.
>
> <flame>
> биарч не нужен
> </flame>

В слаквари много чего не нужно...

-- 
Led

Re: [devel] biarch

[Victor Forsyuk]

On Mon, Sep 24, 2007 at 12:01:03PM +0300, Michael Shigorin <mike@osdn.org.ua> wrote:
> On Sun, Sep 23, 2007 at 09:50:16PM +0300, Led wrote:
> > Кстати, возможно я чего-то не понимаю, но мне очень часто не
> > хватает возможности указать архитектуру (обычно noarch) для
> > конкретных субпакетов, а не для всех субпакетов глобально.
> 
> Это конструктивное ограничение в RPM (4?).

Что ты имеешь в виду под _конструктивным_ ограничением?

На самом деле оно так не потому что "нельзя сделать". Патч, который добавлял
эту фичу, занимает буквально лишь пару страниц:

http://lists.altlinux.ru/pipermail/devel/2003-October/016024.html

Увы, редхатовцы клеили дикие отмазки. Так как ссылка на обсуждение с
http://lists.altlinux.ru/pipermail/devel/2003-October/015903.html
как оказалось протухла, кому интересно могут почитать ее по этой ссылке:

http://groups.google.com/groups?q=How+to+make+some+sub-packages+noarch+and+others+i386

Re: [devel] biarch

[Michael Shigorin]

On Mon, Sep 24, 2007 at 03:34:33PM +0300, Victor Forsyuk wrote:
> > > Кстати, возможно я чего-то не понимаю, но мне очень часто не
> > > хватает возможности указать архитектуру (обычно noarch) для
> > > конкретных субпакетов, а не для всех субпакетов глобально.
> > Это конструктивное ограничение в RPM (4?).
> Что ты имеешь в виду под _конструктивным_ ограничением?

Виноват -- design decision.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] biarch

[Хихин Руслан]

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

Здравствуйте Alexey Morsov
  В сообщении от Понедельник 24 сентября 2007 Alexey Morsov написал(a):
 > Причем проектов которым нужно gcc -m32.
 > Потому как тут правильно уже высказались - для запуска очереднйо
 > проприертарной поделки в 100 раз проще кинуть 32битну glibc в /lib
 > (или
 > даже в /opt/lib) чем курочить систему.
Imho нужен :
1 для нормального grub с прицелом на xen.
2 всякие plugin для браузеров, не собирающиеся в x86_64
3 wine 
4 others :)
И не надо мне про chroot :) - 
Да хоть как - лишь-бы из кооробки :)

-- 
С  уважением Хихин Руслан

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

Re: [devel] biarch

[Epiphanov Sergei]

В сообщении от Sunday 23 September 2007 21:57:04 Dmitry V. Levin написал(а):
> Понятное дело, чтобы можно было
> 1. gcc -m32 в системе x86_64
> 2. использовать результат (1) в системе x86_64
> или что-то в этом духе.

Вот это мне нужно для нормальной сборки VirtualBox под x86_64. (Дома x86_64 и 
ничего нет из i586, нахлебался с мешаниной пакетов от i586).

-- 
С уважением, Епифанов Сергей

Re: [devel] biarch

[Epiphanov Sergei]

В сообщении от Monday 24 September 2007 12:58:56 Michael Shigorin написал(а):
> > И не факт что данное ПО будет свободное, и тем более - для x86_64.
>
> При этом нужно x86_64?

По моим личным наблюдениям переход с 32-битной на 64-битную систему ускорил 
работу приложений и системы в целом где-то на 20%. А это никогда не бывает 
лишним.

-- 
С уважением, Епифанов Сергей

Re: [devel] biarch

[Денис Смирнов]

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

On Mon, Sep 24, 2007 at 01:40:10PM +0300, Serge Ryabchun wrote:

SR> Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
SR> снести Альт

Кроме проприетарных поделок ещё есть wine. Который нужен.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Дык эта... на то и мэйнтейнер у пакета, чтобы апстрим не дремал! =)
		-- mutabor in #6317

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

Re: [devel] biarch

[Damir Shayhutdinov]

> SR> Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
> SR> снести Альт
>
> Кроме проприетарных поделок ещё есть wine. Который нужен.

А ему соответственно нужны куча всяких либ (libcups, libssl, иксы,
libasound, libldap, libxml2/libxslt) не считая glibc.

[devel] битая ссылка (was: biarch)

[Grigory Batalov]

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

On Mon, 24 Sep 2007 15:34:33 +0300, Victor Forsyuk wrote:

> > Это конструктивное ограничение в RPM (4?).
> 
> Что ты имеешь в виду под _конструктивным_ ограничением?
> 
> На самом деле оно так не потому что "нельзя сделать". Патч, который добавлял
> эту фичу, занимает буквально лишь пару страниц:
> 
> http://lists.altlinux.ru/pipermail/devel/2003-October/016024.html
> 
> Увы, редхатовцы клеили дикие отмазки. Так как ссылка на обсуждение с
> http://lists.altlinux.ru/pipermail/devel/2003-October/015903.html
> как оказалось протухла,

  По этой ссылке вижу Ваше письмо за 21 октября 2003 года. А что должно быть?

> кому интересно могут почитать ее по этой ссылке:
> 
> http://groups.google.com/groups?q=How+to+make+some+sub-packages+noarch+and+others+i386

-- 
 Grigory Batalov,
 ALT Linux Team

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

Re: [devel] битая ссылка (was: biarch)

[Victor Forsyuk]

On Wed, Sep 26, 2007 at 08:37:28PM +0400, Grigory Batalov <bga@altlinux.org> wrote:
> > 
> > На самом деле оно так не потому что "нельзя сделать". Патч, который добавлял
> > эту фичу, занимает буквально лишь пару страниц:
> > 
> > http://lists.altlinux.ru/pipermail/devel/2003-October/016024.html
> > 
> > Увы, редхатовцы клеили дикие отмазки. Так как ссылка на обсуждение с
> > http://lists.altlinux.ru/pipermail/devel/2003-October/015903.html
> > как оказалось протухла,
> 
>   По этой ссылке вижу Ваше письмо за 21 октября 2003 года. А что должно быть?

Оно и должно быть. :) Протухла ссылка, которая была в моем письме - на архив
рассылки на geocrawler.com. Чтобы было легче найти куда я тогда ссылался я и
дал новую ссылку, которая ниже:
 
> > кому интересно могут почитать ее по этой ссылке:
> > 
> > http://groups.google.com/groups?q=How+to+make+some+sub-packages+noarch+and+others+i386

Re: [devel] biarch

[Денис Смирнов]

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

On Wed, Sep 26, 2007 at 07:18:08PM +0400, Damir Shayhutdinov wrote:

> SR>> Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
> SR>> снести Альт
>> Кроме проприетарных поделок ещё есть wine. Который нужен.
DS> А ему соответственно нужны куча всяких либ (libcups, libssl, иксы,
DS> libasound, libldap, libxml2/libxslt) не считая glibc.

Вот-вот. А без wine линукс на x86_64 идет нафиг еще ближайшие несколько
лет.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Лучше конференций могут быть только конференции,
на которых ещё не бывал.
		-- at in devel@

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

Re: [devel] biarch

[Damir Shayhutdinov]

> > SR>> Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
> > SR>> снести Альт
> >> Кроме проприетарных поделок ещё есть wine. Который нужен.
> DS> А ему соответственно нужны куча всяких либ (libcups, libssl, иксы,
> DS> libasound, libldap, libxml2/libxslt) не считая glibc.
>
> Вот-вот. А без wine линукс на x86_64 идет нафиг еще ближайшие несколько
> лет.

Хмм.. Не, он идет путем заворачивания в чрут (hasher) и прокидывания
внутрь /dev через mount -o bind. Это не совсем "нафиг", но примерно в
ту же сторону.

Re: [devel] biarch

[Serge Ryabchun]

2007/9/27, Damir Shayhutdinov <damir@altlinux.org>:
> > > SR>> Еще раз, для запуска очередной проприетарной поделки в 100 раз проще
> > > SR>> снести Альт
> > >> Кроме проприетарных поделок ещё есть wine. Который нужен.
> > DS> А ему соответственно нужны куча всяких либ (libcups, libssl, иксы,
> > DS> libasound, libldap, libxml2/libxslt) не считая glibc.
> >
> > Вот-вот. А без wine линукс на x86_64 идет нафиг еще ближайшие несколько
> > лет.
>
> Хмм.. Не, он идет путем заворачивания в чрут (hasher) и прокидывания
> внутрь /dev через mount -o bind.

Угу, прокинуть туда еще /home, /media

> Это не совсем "нафиг", но примерно в > ту же сторону.

Вот и я о том же