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

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

[@ 2007-09-23 12:58 UTC (permalink / raw)]

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

[@ 2007-09-23 13:17 UTC (permalink / raw)]

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

[@ 2007-09-23 13:26 UTC (permalink / raw)]

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 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 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

[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

[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]

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

[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

[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

[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

[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

[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 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

[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

[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

[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

[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

[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

[Anton Farygin]

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

Можно.

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

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

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

[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] 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

[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

[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

[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

[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).


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

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

[Anton Farygin]

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

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

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

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

[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

[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

[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

[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

[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

[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

[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

[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] 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 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

[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] 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

[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

[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 --]

[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: 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: 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

[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

[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

[Motsyo Gennadi aka Drool]

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

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

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

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

[-- 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.

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

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

Вот и я о том же

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

[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/

[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

[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

[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] 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] [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

[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

[Epiphanov Sergei]

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

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

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

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.

[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/