[devel] x86_64, lib64 и все все все

[devel] x86_64, lib64 и все все все

[@ 2005-10-17 7:35 UTC (permalink / raw)]

[devel] Re: x86_64, lib64 и все все все

[@ 2005-10-17 10:15 UTC (permalink / raw)]

Re: [devel] Re: x86_64, lib64 и все все все

[@ 2005-10-17 11:33 UTC (permalink / raw)]

Re: [devel] x86_64, lib64 и все все все

[Anton D. Kachalov]

On Mon, Oct 17, 2005 at 10:35:07AM +0300, Kirill A. Shutemov wrote:
> Хотелось бы проянить вопрос с состоянием x86_64 в Сизифе.
> 
> По словам mouse@, как такового, biarch у нас не будет -- apt не умеет.
> Тогда мне совсем не понятна морока с переименованием lib->lib64. Я
> понимаю, что это позволит, если сильно захочешь, поставить руками 32-x
> битные либы. Но стоит ли игра свечь? Научить некоторые программы работать
> с lib64 не так уж и просто...
Если начинать с нуля -- непросто. Но есть уже большой опыт больших
компаний, которые прошлись по этим граблям. Тот кто игнорирует подобный
опыт "сам себе злобный Буратино" (с) legion@

> 
> Предлагаю пересобрать Сизиф не трогая директории и сосредоточится на 
> правке поделий, которые на самом деле имеют ошибки в коде не позволяющие
> им работать на x86_64. Для сторонних программ можно сделать симлинки
> lib64->lib.
> 
> Ну, а если уж очень хочется иметь и 32-х битное окружение можно и чрут
> завести... ;)

Вот привожу цитату из планов Debian, на который я ссылался, говоря о
чруте.
http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html
- multiarch support, to cure us of special-cased packages and source
  duplication for architectures like amd64 and ppc64

Думаю, этим всё сказано. Все уважающие себя дистры делают полноценный biarch.
Другим доводом в плюс переезда lib->lib64 -- это перелопачивание пакетов,
многие из которых имеют недопустимую кривизну. Более того, многие пакеты в
любом случае потребуют пересборки с прикладыванием специфических патчей
для x86_64. Т.ч. пробегаться по пакетам всё равно придётся.
К примеру, на мой взгляд, констуркция подобного вида просто недопустима:
%files
/lib/libfoo.*

Для lib есть макрос %_lib. Это очень распространённая ошибка. Не говоря
уже о неправильном использовании %_libdir вместо %_datadir.

--
mouse

[devel] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Wed, Oct 19, 2005 at 05:57:45PM +0400, Anton D. Kachalov wrote:
> Вот привожу цитату из планов Debian, на который я ссылался, говоря о
> чруте.
> http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html
> - multiarch support, to cure us of special-cased packages and source
>   duplication for architectures like amd64 and ppc64
> 
> Думаю, этим всё сказано. Все уважающие себя дистры делают полноценный biarch.

Я не понимаю, зачем нужен biarch.  То есть я не вижу необходимости
запускать i386 код на x86_64.  Можно просто пересобрать для x86_64.
Если же какая-то добрая фирма собирается осчастливить нас своими
проприетарными бинарями для i386, то пусть она засунет их себе в
какое-нибудь неприличное место.  Статически пусть их линкует и т.п.
От добра добра не ищут.

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

[devel] Re: x86_64, lib64 и все все все

[Anton Farygin]

On Thu, 20 Oct 2005 04:29:40 +0400, Alexey Tourbin wrote:

> On Wed, Oct 19, 2005 at 05:57:45PM +0400, Anton D. Kachalov wrote:
>> Вот привожу цитату из планов Debian, на
>> который я ссылался, говоря о чруте.
>> http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html -
>> multiarch support, to cure us of special-cased packages and source
>>   duplication for architectures like amd64 and ppc64
>> 
>> Думаю, этим всё сказано. Все уважающие
>> себя дистры делают полноценный biarch.
> 
> Я не понимаю, зачем нужен biarch.  То есть я
> не вижу необходимости запускать i386 код
> на x86_64.  Можно просто пересобрать для
> x86_64. Если же какая-то добрая фирма
> собирается осчастливить нас своими
> проприетарными бинарями для i386, то пусть
> она засунет их себе в какое-нибудь
> неприличное место.  Статически пусть их
> линкует и т.п. От добра добра не ищут.

Подход не верный.

Rgds,
Rider

[devel] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Thu, Oct 20, 2005 at 01:02:47PM +0400, Anton Farygin wrote:
> > Я не понимаю, зачем нужен biarch.  То есть я
> > не вижу необходимости запускать i386 код
> > на x86_64.  Можно просто пересобрать для
> > x86_64. Если же какая-то добрая фирма
> > собирается осчастливить нас своими
> > проприетарными бинарями для i386, то пусть
> > она засунет их себе в какое-нибудь
> > неприличное место.  Статически пусть их
> > линкует и т.п. От добра добра не ищут.
> 
> Подход не верный.

Так зачем нужен biarch?  "Популярно объясняю для невежд..."

То, что x86_64 процессор умеет выполнять i386 код ещё не значит, что ОС
для x86_64 должна быть заточена под i386.  Он ещё и 8086 код, наверное,
умеет исполнять.  Что теперь, tri-arch делать?

Я не не вижу необходимости запускать i386 код на x86_64.  Это может
потребоваться только для запуска проприетарного софта, но это проблема
проприетарных вендоров, а не проблема открытой платформы.

Какой подход верный?  Шарить /usr по сети одновременно для i386 и
x86_64?  Сомневаюсь.  FHS говорит, что только /usr/share можно шарить
по сети.

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

Re: [devel] Re: x86_64, lib64 и все все все

[Dmitry V. Levin]

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

On Thu, Oct 20, 2005 at 05:37:46PM +0400, Alexey Tourbin wrote:
> Я не не вижу необходимости запускать i386 код на x86_64.  Это может
> потребоваться только для запуска проприетарного софта, но это проблема
> проприетарных вендоров, а не проблема открытой платформы.

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


-- 
ldv

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

[devel] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Thu, Oct 20, 2005 at 06:48:55PM +0400, Dmitry V. Levin wrote:
> On Thu, Oct 20, 2005 at 05:37:46PM +0400, Alexey Tourbin wrote:
> > Я не не вижу необходимости запускать i386 код на x86_64.  Это может
> > потребоваться только для запуска проприетарного софта, но это проблема
> > проприетарных вендоров, а не проблема открытой платформы.
> 
> А вот с этого места, пожалуйста, поподробнее.
> Почему открытая платформа не должна поддерживать запуск несвободного
> софта?

Интересный вопрос.  Я не утверждаю, что не должна.  Я утверждаю, что
открытая x86_64 платформа не должна воссоздавать полную i386 среду,
потому что для самой открытой платформы это попросту не нужно.  Это
может быть нужно только для проприетарных бинарей; но пусть тогда
проприетарные вендоры озаботятся собрать бинари для x86_64, либо же
линковать i386 бинари статически, либо что угодно.

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

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

[devel] [JT] Re: x86_64, lib64 и все все все

[Michael Shigorin]

On Thu, Oct 20, 2005 at 07:56:34PM +0400, Alexey Tourbin wrote:
> Я утверждаю, что открытая x86_64 платформа не должна
> воссоздавать полную i386 среду, потому что для самой
> открытой платформы это попросту не нужно.

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

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

Так отож.

PS: smoke-room@?

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

Re: [devel] [JT] Re: x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 20:21 Thu 20 Oct, Michael Shigorin wrote:
> On Thu, Oct 20, 2005 at 07:56:34PM +0400, Alexey Tourbin wrote:
> > Я утверждаю, что открытая x86_64 платформа не должна
> > воссоздавать полную i386 среду, потому что для самой
> > открытой платформы это попросту не нужно.
> 
> Вопрос в том, что в итоге требуется -- платформа или работу
> сделать.  Как правило, работают разумные компромиссы, а не 
> экстремизм любой окраски.
По-моему я предложил вполне разумный компромис...

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

[...] он не следует нашей PAM Policy.  Насколько я понимаю, этим
правилам в Сизифе следуют только мои пакеты. :(
		-- ldv in devel@

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

[devel] Re: [JT] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Thu, Oct 20, 2005 at 09:07:35PM +0300, Kirill A. Shutemov wrote:
> > Вопрос в том, что в итоге требуется -- платформа или работу
> > сделать.  Как правило, работают разумные компромиссы, а не 
> > экстремизм любой окраски.
> По-моему я предложил вполне разумный компромис...

Вы предлагаете то же, что и я: делать x86_64 с /usr/lib, без поддержки
biarch на уровне rpm.  Только у Вас остается гипотетическая возможность
впоследствии реализовать поддержку biarch, а я предлагаю эту
гипотетическую возможность отбросить.  Замечу, что в уже работающей
x86_64 системе реализовать переход /usr/lib -> /usr/lib64
с освобождением места для biarch будет сложнее.

"Проблема" в том, что усилиями Антона К. поддержка /usr/lib64 уже во
многих пакетах реализована.  Не ясно, что с ней делать: выбрасывать
жалко, но без полноценного biarch она всё равно не нужна.

Ситуация за последний год заметно изменилась.  Сейчас EMT64 есть даже в
Celeron'ах.  Просто пока это воспринимается как ненужный довесок.  После
того, как МS выпустит win64, x86_64 отрекламируют, и можно будет делать
ставки, сколько ещё i386 как платформа будет актуальна.

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

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Epiphanov Sergei]

В сообщении от Friday 21 October 2005 03:17 Alexey Tourbin написал(a):
> Вы предлагаете то же, что и я: делать x86_64 с /usr/lib, без поддержки
> biarch на уровне rpm.  Только у Вас остается гипотетическая возможность
> впоследствии реализовать поддержку biarch, а я предлагаю эту
> гипотетическую возможность отбросить.  Замечу, что в уже работающей
> x86_64 системе реализовать переход /usr/lib -> /usr/lib64
> с освобождением места для biarch будет сложнее.
>
> "Проблема" в том, что усилиями Антона К. поддержка /usr/lib64 уже во
> многих пакетах реализована.  Не ясно, что с ней делать: выбрасывать
> жалко, но без полноценного biarch она всё равно не нужна.
>
> Ситуация за последний год заметно изменилась.  Сейчас EMT64 есть даже в
> Celeron'ах.  Просто пока это воспринимается как ненужный довесок.  После
> того, как МS выпустит win64, x86_64 отрекламируют, и можно будет делать
> ставки, сколько ещё i386 как платформа будет актуальна.

У меня процессор НЕ x86_64. Так что ж, послать меня нафиг? А если хочу 
потестировать программы под НЕ x86_64 на машине с x86_64? Не все ещё 
перебрались туда. Вспомните, что доооолгое время, когда уже вовсю бегали 
Pentium'ы (и до сих пор) собирают ещё и под i386.

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

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Denis Smirnov]

On Fri, Oct 21, 2005 at 03:17:30AM +0400, Алексей Турбин wrote:

AT> Ситуация за последний год заметно изменилась.  Сейчас EMT64 есть даже в
AT> Celeron'ах.  Просто пока это воспринимается как ненужный довесок.  После
AT> того, как МS выпустит win64, x86_64 отрекламируют, и можно будет делать
AT> ставки, сколько ещё i386 как платформа будет актуальна.

До сих пор используются клиент-банки под DOS. Делаем выводы об
актуальности :(

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

http://freesource.info
----------------------------------------------------------------------------
а может ну её вообще, эту jfs ?
неславная она какая-то.
		-- sbolshakov in #7039

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Aleksey Avdeev]

Denis Smirnov пишет:
> On Fri, Oct 21, 2005 at 03:17:30AM +0400, Алексей Турбин wrote:
> 
> AT> Ситуация за последний год заметно изменилась.  Сейчас EMT64 есть даже в
> AT> Celeron'ах.  Просто пока это воспринимается как ненужный довесок.  После
> AT> того, как МS выпустит win64, x86_64 отрекламируют, и можно будет делать
> AT> ставки, сколько ещё i386 как платформа будет актуальна.
> 
> До сих пор используются клиент-банки под DOS. Делаем выводы об
> актуальности :(
> 

   Тоже самое -- почтовые АРМ... :-(

-- 

С уважением. Алексей.

[devel] Re: [JT] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Thu, Oct 20, 2005 at 08:21:19PM +0300, Michael Shigorin wrote:
> > Кто под кого делает?  Вендоры делают для платформы или
> > платформу делают под вендоров?  Впрочем, неприятный аспект
> > идеологизированных решений -- в том, что страдают от них
> > простые пользователи, у которых зачастую нет выбора.
> 
> Так отож.
> PS: smoke-room@?

Нет-нет.  Каким будет x86_64 -- это всех касается.  Через пару лет i386
как платформа иссякнет, и что тогда будет, об этом нужно думать уже
сейчас.  Антон К. пишет, что полноценный biarch у нас появится не скоро.
У меня есть гипотеза, что он появится как раз тогда, когда станет никому
не нужен.  So what?  So ...

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

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Thu, Oct 20, 2005 at 10:23:58PM +0400, Alexey Tourbin wrote:
> Нет-нет.  Каким будет x86_64 -- это всех касается.  Через пару лет i386
> как платформа иссякнет, и что тогда будет, об этом нужно думать уже
> сейчас.  Антон К. пишет, что полноценный biarch у нас появится не скоро.
> У меня есть гипотеза, что он появится как раз тогда, когда станет никому
> не нужен.  So what?  So ...
Думаю, не стоит приплетать личное мнение к реальном положению дел. Да,
реально em64t/amd64 потеснит всех. Сам i?86 как был, так и останется.
Причём, ещё много лет. Ведь до сих пор в некоторых конторах живы первые
пни. А сколько уже прошло лет? Лет 13, наверное. А живы!
Инерционность очень большая.
До полноценного biarch нам не хватает одной вещи - переход на smart.
Mandriva уже там. А, значит, первопроходец уже есть. Переход же
влечёт за собой либо переезд на новый rpm со всеми вытекающими, либо некий
процесс сводимости smart >>> | <<< rpm, влекущий изменения как в rpm
(преимущественно в rpm-python), так и в smart.
Опять же, кто и когда будет этим заниматься?

--
mouse

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Igor Zubkov]

В сообщении от Пятница, 21-Окт-2005 10:29 Anton D. Kachalov написал(a):
> До полноценного biarch нам не хватает одной вещи - переход на smart.
> Mandriva уже там. А, значит, первопроходец уже есть. Переход же
> влечёт за собой либо переезд на новый rpm со всеми вытекающими, либо некий
> процесс сводимости smart >>> | <<< rpm, влекущий изменения как в rpm
> (преимущественно в rpm-python), так и в smart.
> Опять же, кто и когда будет этим заниматься?

smart проще переписать заново, чем патчить наш rpm (в раойне rpm-python) или 
патчить smart что бы он работал с нашим rpm'ом.

Может посмотрим на yum? У меня yum 1.0.3 заработал на Сизифе. Спек могу 
прицепить или положить в Дедал. Более свежие версии yum у нас уже не 
заработают без переделывания rpm-python.

-- 
Now playing: Evanescence [] [] The end

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 12:18:33PM +0300, Igor Zubkov wrote:
> smart проще переписать заново, чем патчить наш rpm (в раойне rpm-python) или 
> патчить smart что бы он работал с нашим rpm'ом.
Не, не проще. Тем более, я предлагал патчить и то, и другое, чтобы найти
некую золотую середину.

> Может посмотрим на yum? У меня yum 1.0.3 заработал на Сизифе. Спек могу 
> прицепить или положить в Дедал. Более свежие версии yum у нас уже не 
> заработают без переделывания rpm-python.
Спасибо, канешн, но я его уже пробовал собирать. Не понравился.
yum хуже, чем smart. Smart пишет тот же человек, который занимался apt'ом.
Да и сам smart приятнее и фичастее нежели yum. И
тянет yum за собой кучу всего. А главное, зачем нам старый yum?

--
mouse

yum and smart (was: Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все)

[Igor Zubkov]

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

В сообщении от Пятница, 21-Окт-2005 13:51 Anton D. Kachalov написал(a):
> > smart проще переписать заново, чем патчить наш rpm (в раойне rpm-python)
> > или патчить smart что бы он работал с нашим rpm'ом.
>
> Не, не проще. Тем более, я предлагал патчить и то, и другое, чтобы найти
> некую золотую середину.

Это тоже вариант...

> > Может посмотрим на yum? У меня yum 1.0.3 заработал на Сизифе. Спек могу
> > прицепить или положить в Дедал. Более свежие версии yum у нас уже не
> > заработают без переделывания rpm-python.
>
> Спасибо, канешн, но я его уже пробовал собирать. Не понравился.

А у меня с локальным репозиторием yum заработал быстрее чем apt. Обидно.

> yum хуже, чем smart. Smart пишет тот же человек, который занимался apt'ом. 

Я помню кто пишет -- Gustavo Niemeyer.

> Да и сам smart приятнее и фичастее нежели yum.

Выдержка из README smart 0.39:
--------------
Project Status
--------------

The development of Smart Package Manager started on May 4th, 2004, and
the project is currently under beta testing, since all core features
are implemented.

С учётом того что оно сейчас в "beta testing", у нас всех ещё есть время 
решиться.

> И тянет yum за собой кучу всего. 

Это много?
[icesik@localhost i686]$ rpm -q -p --requires yum-1.0.3-alt1.i686.rpm 
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
/etc/cron.daily  
/etc/init.d(failure)  
/etc/init.d(success)  
/etc/logrotate.d  
coreutils  
python-strict  
service  
sh  
[icesik@localhost i686]$ 

> А главное, зачем нам старый yum? 

Спек для yum 1.0.3 прилагается.

-- 
Now playing: Oomph!

[-- Attachment #2: yum.spec --]
[-- Type: text/plain, Size: 2676 bytes --]

Name: yum
Version: 1.0.3
Release: alt1

Summary: RPM installer/updater
License: GPL
Group: System Environment/Base
Source0: %name-%version.tar.gz
URL: http://www.dulug.duke.edu/yum/

Packager: Igor Zubkov <icesik@altlinux.ru>

#BuildRequires: python
#Requires: python librpm404 rpm404-python
#Prereq: /sbin/chkconfig, /sbin/service

# Automatically added by buildreq on Thu Sep 15 2005
BuildRequires: python-base python-modules-compiler python-modules-encodings

%description
Yum is a utility that can check for and automatically download and
install updated RPM packages. Dependencies are obtained and downloaded 
automatically prompting the user as necessary.

%prep
%setup -q

%build
%configure 
%make_build

%install
%make_install DESTDIR=%buildroot install

#post
#/sbin/chkconfig --add yum
#/sbin/chkconfig yum on
#/sbin/service yum condrestart >> /dev/null
#exit 0

#preun
#if [ $1 = 0 ]; then
# /sbin/chkconfig --del yum
# /sbin/service yum stop >> /dev/null
#fi
#exit 0

%files 
%doc README AUTHORS COPYING TODO INSTALL
%config(noreplace) %{_sysconfdir}/yum.conf
%config %{_sysconfdir}/cron.daily/yum.cron
%config %{_sysconfdir}/init.d/%{name}
%config %{_sysconfdir}/logrotate.d/%{name}
%{_datadir}/yum/*
%{_bindir}/yum
%{_bindir}/yum-arch
/var/cache/yum
%{_mandir}/man*/*

%changelog
* Thu Sep 15 2005 Igor Zubkov <icesik@altlinux.ru> 1.0.3-alt1
- Initial build for Sisyphus

* Mon Sep  8 2003 Seth Vidal <skvidal@phy.duke.edu>
- brown paper-bag 1.0.3

* Mon Sep  8 2003 Seth Vidal <skvidal@phy.duke.edu>
- ver to 1.0.2

* Mon May 19 2003 Seth Vidal <skvidal@phy.duke.edu>
- ver to 1.0.1

* Mon Apr 28 2003 Seth Vidal <skvidal@phy.duke.edu>
- fix up for changes to layout and fhs compliance

* Tue Mar 11 2003 Seth Vidal <skvidal@phy.duke.edu>
- default spec for rhl 8.0
- ver to 1.0

* Sun Dec 22 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped ver to 0.9.4
- new spec file for rhl 8.0

* Sun Oct 20 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped ver to 0.9.3

* Mon Aug 26 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped ver to 0.9.2

* Thu Jul 11 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped ver to 0.9.1

* Thu Jul 11 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped ver  to 0.9.0

* Thu Jul 11 2002 Seth Vidal <skvidal@phy.duke.edu>
- added rpm require

* Sun Jun 30 2002 Seth Vidal <skvidal@phy.duke.edu>
- 0.8.9

* Fri Jun 14 2002 Seth Vidal <skvidal@phy.duke.edu>
- 0.8.7

* Thu Jun 13 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped to 0.8.5

* Thu Jun 13 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped to 0.8.4

* Sun Jun  9 2002 Seth Vidal <skvidal@phy.duke.edu>
- bumped to 0.8.2
* Thu Jun  6 2002 Seth Vidal <skvidal@phy.duke.edu>
- First packaging

Re: yum and smart (was: Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все)

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 02:27:04PM +0300, Igor Zubkov wrote:
> А у меня с локальным репозиторием yum заработал быстрее чем apt. Обидно.
Я ничего не упоминал про apt. Я говорил только про smart и yum :) А smart
ещё шустрее.

> Я помню кто пишет -- Gustavo Niemeyer.
Он самый.

> С учётом того что оно сейчас в "beta testing", у нас всех ещё есть время 
> решиться.
Если ещё учесть, что mandriva на него перешла, то процесс перехода будет
ещё быстрее.

> Это много?
> [icesik@localhost i686]$ rpm -q -p --requires yum-1.0.3-alt1.i686.rpm 
Я собирал 2.3.3... оно хотело немного больше...

--
mouse

[devel] Re: [JT] Re: x86_64, lib64 и все все все

[Michael Shigorin]

On Fri, Oct 21, 2005 at 12:18:33PM +0300, Igor Zubkov wrote:
> Может посмотрим на yum?

Зачем нужна эта кака?

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

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 02:39:33PM +0300, Michael Shigorin wrote:
> On Fri, Oct 21, 2005 at 12:18:33PM +0300, Igor Zubkov wrote:
> > Может посмотрим на yum?
> 
> Зачем нужна эта кака?
Вот я всё хотел упомянуть это слово, но как-то не решался :)

--
mouse

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Andrey Rahmatullin]

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

On Fri, Oct 21, 2005 at 02:39:33PM +0300, Michael Shigorin wrote:
> Зачем нужна эта кака?
А что с ней?

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Сизиф нестабилен не потому, что его кто-то таким специально делает,
а потому, что там работа идёт непрерывная.
		-- voins in devel@

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

[devel] Re: [JT] Re: x86_64, lib64 и все все все

[Michael Shigorin]

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

On Sat, Oct 22, 2005 at 03:09:43PM +0600, Andrey Rahmatullin wrote:
> > Зачем нужна эта кака?
> А что с ней?

python, headers, пенсия.

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

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

Re: [devel] Re: [JT] Re: x86_64, lib64 и все все все

[Igor Zubkov]

В сообщении от Суббота, 22-Окт-2005 14:40 Michael Shigorin написал(a):
> > > Зачем нужна эта кака?
> >
> > А что с ней?
>
> python

smart тоже на питоне писан.

> headers, пенсия. 

?

-- 
icesik

[devel] yum, smart, apt (и кто бы sucks less)

[Michael Shigorin]

On Sat, Oct 22, 2005 at 03:25:16PM +0300, Igor Zubkov wrote:
> > > > Зачем нужна эта кака?
> > > А что с ней?
> > python
> smart тоже на питоне писан.

Знаю, к нему это тоже претензия.

> > headers, пенсия. 
> ?

Хедеры при рассмотрении пару лет назад показались сильно большим
уродством, чем base/; плюс эта штука тоже древняя и подозреваю,
что с тех пор много что придумали как решать лучше. (конкретно
вопрос по biarch для меня сейчас открыт)

Общее же мнение сложилось при рассмотрении, когда пытался
прикрутить yum из ASP7.3 к серверу на RH7.3, пока не понял,
что перетащить по-горячему на ALM2.2 будет быстрее и лучше.

PS: reply-to:

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

Re: [devel] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Thu, Oct 20, 2005 at 07:56:34PM +0400, Alexey Tourbin wrote:
> Интересный вопрос.  Я не утверждаю, что не должна.  Я утверждаю, что
> открытая x86_64 платформа не должна воссоздавать полную i386 среду,
А кто говорит, что _полную_ i386-среду? Речь идёт _только_ о библиотеках.
Не более.

> потому что для самой открытой платформы это попросту не нужно.  Это
> может быть нужно только для проприетарных бинарей; но пусть тогда
Г-м-м... А про Wine/Xine(win32-dll) мы забыли? Ах, да. 0fft0pic. Извиняюсь.
Или приложения, написанные на чистом i386-асме. Они не имеют право на
жизнь? Из твоих утверждений, не имеют.

> проприетарные вендоры озаботятся собрать бинари для x86_64, либо же
> линковать i386 бинари статически, либо что угодно.
А что делать, если у меня некая pci-ная карточка n-цати летней давности,
стоящая в те времена дофига баблоса и аналогов которой либо из доступной ценовой категории просто нет, либо вообще нет. А софт/дрова для неё написан ещё задолго до появления x86_64?
Предлагаешь выбросить пару килобаксов в помойку? Спасибо. Я понимаю, что
описанный вариант - крайность и частность, но всё же.

> Кто под кого делает?  Вендоры делают для платформы или платформу делают
> под вендоров?  Впрочем, неприятный аспект идеологизированных решений --
Вендоры делают под offtopic :)

--
mouse

[devel] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Fri, Oct 21, 2005 at 12:33:43AM +0400, Anton D. Kachalov wrote:
> On Thu, Oct 20, 2005 at 07:56:34PM +0400, Alexey Tourbin wrote:
> > Интересный вопрос.  Я не утверждаю, что не должна.  Я утверждаю, что
> > открытая x86_64 платформа не должна воссоздавать полную i386 среду,
> А кто говорит, что _полную_ i386-среду? Речь идёт _только_ о библиотеках.
> Не более.

Я тебе могу объяснить, почему, например, библиотеку libperl.so нельзя
вписать в biarch.  Потому что она умеет загружать перловые *.so модули и
активно этим пользуется.  То есть в biarch-систему нужно ставить весь
perl-base и далее по зависимостям.  Думаю, что libperl -- не
единственная такая библиотека.  Ограничиться библиотеками будет крайне
трудно, придется какой-нибудь bin64 делать, но он не предусмотрен.
В этом вся фигня: слишком много переделывать надо, и всё чего ради.

> > потому что для самой открытой платформы это попросту не нужно.  Это
> > может быть нужно только для проприетарных бинарей; но пусть тогда
> Г-м-м... А про Wine/Xine(win32-dll) мы забыли? Ах, да. 0fft0pic. Извиняюсь.
> Или приложения, написанные на чистом i386-асме. Они не имеют право на
> жизнь? Из твоих утверждений, не имеют.

Имеют.  Только не надо портить концепт системы.  Ведь придется менять
базовые каталоги, формат зависимостей, алгоритмы apt/rpm и т.п., только
для того, чтобы поставить в x86_64 несколько "родных" i586 пакетов.

Эти несколько базовых i586 библиотек на самом деле проще будет стыдливо
положить в какой-нибудь каталог или вообще развернуть базовую i586
систему в чруте.  С чем hasher прекрасно справляется.  В конце концов,
никто не заставляет запускать x86_64 систему на x86_64, можно спокойно
грузиться в i586.

Про wine я не подумал.  А что, wine, собранный для x86_64, не сможет
запускать бинари для win32?

> > проприетарные вендоры озаботятся собрать бинари для x86_64, либо же
> > линковать i386 бинари статически, либо что угодно.
> А что делать, если у меня некая pci-ная карточка n-цати летней давности,
> стоящая в те времена дофига баблоса и аналогов которой либо из доступной ценовой категории просто нет, либо вообще нет. А софт/дрова для неё написан ещё задолго до появления x86_64?
> Предлагаешь выбросить пару килобаксов в помойку? Спасибо. Я понимаю, что
> описанный вариант - крайность и частность, но всё же.

А в чем проблема с PCI карточкой?  Мы вроде про userland говорим.
У меня тоже есть ISA модем, который я 7 лет назад купил за приличные
деньги.  Теперь вот беспокоюсь, будет ли он работать на x86_64.  Или
же потребуется USB переходник. :)

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

Re: [devel] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 01:58:51AM +0400, Alexey Tourbin wrote:
> Я тебе могу объяснить, почему, например, библиотеку libperl.so нельзя
> вписать в biarch.  Потому что она умеет загружать перловые *.so модули и
> активно этим пользуется.  То есть в biarch-систему нужно ставить весь
> perl-base и далее по зависимостям.  Думаю, что libperl -- не
> единственная такая библиотека.  Ограничиться библиотеками будет крайне
> трудно, придется какой-нибудь bin64 делать, но он не предусмотрен.
> В этом вся фигня: слишком много переделывать надо, и всё чего ради.
Ты явно не понимаешь, что именно за biarch предполагается. Для примера,
предлагаю прогуляться на ftp SuSE и посмотреть на список пакетов, которые
они держат для biarch (в том же репозитарии x86_64, но в директории i?86).
Ещё раз _ПОДЧЕРКНУ_, что biarch - это НЕ ДВЕ архитектуры на одной машине,
а ОДНА + БИБЛИОТЕКИ (преимущественно) для
работы второй архитектуры (для обратной совместимости). В случае с perl всё просто. Во-первых, он и так живёт в /usr/lib/perl5, а деление начинается на уровень ниже. Думаю тебе это объяснять не нужно :) Во-вторых, perl - это интерпретатор и для него уж точно не имеет смысла ставить i?86 пакеты. Только noarch. Но это должен быть РЕАЛЬНЫЙ noarch. Я пару месяцев назад закидывал в devel@ письмо про noarch и Сизиф, но реального фидбека не последовало. Если уж на то пошло, в системе не должно быть ДВУХ PAM'ов. Разъяснять почему?

> Имеют.  Только не надо портить концепт системы.  Ведь придется менять
> базовые каталоги, формат зависимостей, алгоритмы apt/rpm и т.п., только
> для того, чтобы поставить в x86_64 несколько "родных" i586 пакетов.
Видимо меня плохо воспринимают, либо я писать не умею. Я уже писал, что
переезд lib -> lib64 УЖЕ ДАВНО ПРОЙДЕННЫЙ ЭТАП. Не нами, но ПРОЙДЕННЫЙ.
Да, сейчас есть проблема с apt, но rpm умел multilib ещё ДО версии 4.0.
Смотрим changelog в самом rpm.
Я не думаю, что целесообразно ЗАБИТЬ и собрать всё с lib только из-за
того, что кривулька по имени apt не умеет multilib. Дело в том, что если
не сделать переезд lib -> lib64 сейчас, то этого не произойдёт никогда.

> Эти несколько базовых i586 библиотек на самом деле проще будет стыдливо
> положить в какой-нибудь каталог или вообще развернуть базовую i586
> систему в чруте.  С чем hasher прекрасно справляется.  В конце концов,
> никто не заставляет запускать x86_64 систему на x86_64, можно спокойно
> грузиться в i586.
Нет уж! Тогда лучше под столом держать старый пентюх с i386-системой.
Зачем ещё какой-то dualboot? :)

> Про wine я не подумал.  А что, wine, собранный для x86_64, не сможет
> запускать бинари для win32?
Если только эти бинари не win64 и то, это у виноделов только в планах
забадяжить.
Я думаю, что не надо рассказывать о том, как работает Wine :)

> А в чем проблема с PCI карточкой?  Мы вроде про userland говорим.
> У меня тоже есть ISA модем, который я 7 лет назад купил за приличные
> деньги.  Теперь вот беспокоюсь, будет ли он работать на x86_64.  Или
> же потребуется USB переходник. :)
Я и говорю, что у PCI-ой карточки есть как дрова, так и userland.
Допустим, дрова в сырсах есть, а дальше?

--
mouse

[devel] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Fri, Oct 21, 2005 at 11:03:27AM +0400, Anton D. Kachalov wrote:
> Ты явно не понимаешь, что именно за biarch предполагается. Для примера,
> предлагаю прогуляться на ftp SuSE и посмотреть на список пакетов, которые
> они держат для biarch (в том же репозитарии x86_64, но в директории i?86).
> Ещё раз _ПОДЧЕРКНУ_, что biarch - это НЕ ДВЕ архитектуры на одной машине,
> а ОДНА + БИБЛИОТЕКИ (преимущественно) для работы второй архитектуры
> (для обратной совместимости).

Ограничиться библиотеками будет трудно.

Windows XP 64-bit Edition includes both 32- and 64-bit versions of
Internet Explorer, in order to allow for the possibility that some
third-party browser plugins or ActiveX controls may not yet be available
in 64-bit versions.
http://en.wikipedia.org/wiki/Windows_XP_Professional_x64_Edition

Собственно это подтверждает два моих тезиса:

1) biarch придумали масоны, чтобы сохранить возможность запускать свои
левые бинари.  Для свободного софта biarch не нужен.

2) полноценный biarch невозможен, т.к. рано или поздно всё сводится к
тому, что нужно ставить двойной комплект софта.

> > Имеют.  Только не надо портить концепт системы.  Ведь придется менять
> > базовые каталоги, формат зависимостей, алгоритмы apt/rpm и т.п., только
> > для того, чтобы поставить в x86_64 несколько "родных" i586 пакетов.
> Видимо меня плохо воспринимают, либо я писать не умею. Я уже писал, что
> переезд lib -> lib64 УЖЕ ДАВНО ПРОЙДЕННЫЙ ЭТАП. Не нами, но ПРОЙДЕННЫЙ.
> Да, сейчас есть проблема с apt, но rpm умел multilib ещё ДО версии 4.0.
> Смотрим changelog в самом rpm.
> Я не думаю, что целесообразно ЗАБИТЬ и собрать всё с lib только из-за
> того, что кривулька по имени apt не умеет multilib. Дело в том, что если
> не сделать переезд lib -> lib64 сейчас, то этого не произойдёт никогда.

Okay, пусть будет lib64, если сделать lib64 будет не сложнее, чем
оставить lib (в чем я сомневаюсь).  Но мне всё равно не нравтися формат
зависимостей libperl.so.5.8()(x86_64) вместо libperl.so.5.8.  Это
какой-то изврат.  Можно просто оставить libperl.so.5.8, но изменить
алгоритм "удовлетворения" зависимостей: зависмость удовлетворена тогда и
только тогда, когда её предоставляет пакет совместимой архитектуры.

> Нет уж! Тогда лучше под столом держать старый пентюх с i386-системой.
> Зачем ещё какой-то dualboot? :)

Да.  Можно деражть старый пентюх! :)

> Я думаю, что не надо рассказывать о том, как работает Wine :)

Увы, я не знаю, как работает wine.

> Я и говорю, что у PCI-ой карточки есть как дрова, так и userland.
> Допустим, дрова в сырсах есть, а дальше?

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

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

[devel] Re: x86_64, lib64 и все все все

[Anton Farygin]

On Thu, 20 Oct 2005 19:56:34 +0400, Alexey Tourbin wrote:

> On Thu, Oct 20, 2005 at 06:48:55PM +0400, Dmitry V. Levin wrote:
>> On Thu, Oct 20, 2005 at 05:37:46PM +0400, Alexey Tourbin wrote:
>> > Я не не вижу необходимости запускать
>> > i386 код на x86_64.  Это может потребоваться
>> > только для запуска проприетарного
>> > софта, но это проблема проприетарных
>> > вендоров, а не проблема открытой
>> > платформы.
>> 
>> А вот с этого места, пожалуйста,
>> поподробнее. Почему открытая платформа
>> не должна поддерживать запуск
>> несвободного софта?
> 
> Интересный вопрос.  Я не утверждаю, что
> не должна.  Я утверждаю, что открытая x86_64
> платформа не должна воссоздавать полную
> i386 среду, потому что для самой открытой
> платформы это попросту не нужно.  Это
> может быть нужно только для
> проприетарных бинарей; но пусть тогда
> проприетарные вендоры озаботятся
> собрать бинари для x86_64, либо же
> линковать i386 бинари статически, либо что
> угодно.
> 
> Кто под кого делает?  Вендоры делают для
> платформы или платформу делают под
> вендоров?  Впрочем, неприятный аспект
> идеологизированных решений -- в том, что
> страдают от них простые пользователи, у
> которых зачастую нет выбора.

В данном конкретном случае - платформа для вендоров.

И от этого не уйти в ближайшем будущем. 

Кстати, я уверен что все вендоры со
временем спортируются на x86_64. Вот только
_у всех_ будет всё слинковано с lib64/*.

Я думаю что здесь нам надо не
выпендриваться и делать так, как это
делают в RedHat и SuSE.

Rgds,
Rider

Re: [devel] Re: x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 09:32 Fri 21 Oct, Anton Farygin wrote:
> В данном конкретном случае - платформа для вендоров.
> 
> И от этого не уйти в ближайшем будущем. 
> 
> Кстати, я уверен что все вендоры со
> временем спортируются на x86_64. Вот только
> _у всех_ будет всё слинковано с lib64/*.
Так сделать _пока_ симлинк lib64->lib. И быстро получить, что-нить похожее
на рабочий репозиторий. Потом планомерно развешивать баги про lib64 и
_когда_Сизиф_будет_готов_ убрать симлинк и занятся biarch, если он будет
актуален к тому веремени. Нужно что-то рабочее чтобы это тестировали, а
модные фичи, если это будет нужно, можно докуртить потом.

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

>Подскажи те что может быть с firefox'ом
>после одного из обновления (dist-upgrade) firefox перестал запускаться,
>точнее отображать окно
Можно еще точнее описать проблему?
		-- legion in sisyphus@

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

Re: [devel] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 10:00:11AM +0300, Kirill A. Shutemov wrote:
> Так сделать _пока_ симлинк lib64->lib. И быстро получить, что-нить похожее
> на рабочий репозиторий. Потом планомерно развешивать баги про lib64 и
> _когда_Сизиф_будет_готов_ убрать симлинк и занятся biarch, если он будет
> актуален к тому веремени. Нужно что-то рабочее чтобы это тестировали, а
> модные фичи, если это будет нужно, можно докуртить потом.
Ты сам в свои слова веришь? :) Я вот думаю, что расклад будет такой.
Соберём всё как есть, даже не заморачиваясь на патчи для x86_64 с
реальными фиксами багов (фиксить начнём, когда всё разваливаться будет). А
на biarch все махнут рукой со словами, что i?86 дохлая архитектура, на кой
она нам (уже кричат)? Многие пакеты требуют ручной работы для сборки. Так зачем
проделывать одну и ту же работу по десять раз? Где логика и здравый смысл?

--
mouse

Re: [devel] Re: x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 11:09 Fri 21 Oct, Anton D. Kachalov wrote:
> Ты сам в свои слова веришь? :) Я вот думаю, что расклад будет такой.
> Соберём всё как есть, даже не заморачиваясь на патчи для x86_64 с
> реальными фиксами багов (фиксить начнём, когда всё разваливаться будет). А
> на biarch все махнут рукой со словами, что i?86 дохлая архитектура, на кой
> она нам (уже кричат)? Многие пакеты требуют ручной работы для сборки. Так зачем
> проделывать одну и ту же работу по десять раз? Где логика и здравый смысл?

Сначала собрать с симлинком. Потом, например раз в месяц, пресобирать 
Сизиф с реальным(не симлинком) lib64, развешивать баги на этот счёт. 
Когда количество пактов с неработающих с lib64 станет меньше некой
критической массы обрубить симлинк навсегда. Иначе мы рискуем вообще
не получить x86_64 никогда.

P.S. Возможно я переоцениваю сборочные мощности...
-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

> А Вы сможете перехватить трафик на свитчах?
Легко. И не только перехватить, но и перенаправить.
У нас в Сизифе есть инструментарий для этого. Больше не скажу.
		-- ldv in sisyphus@

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

Re: [devel] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 11:03:47AM +0300, Kirill A. Shutemov wrote:
> Сначала собрать с симлинком. Потом, например раз в месяц, пресобирать 
> Сизиф с реальным(не симлинком) lib64, развешивать баги на этот счёт. 
Весь сизиф? А как же зависимости? Если у меня пакет А уедет в lib64,
пакет B не обучен догонять пакет A именно в lib64, а пакет C хочет B, то у
нас ломается сборка. На что развешивать баги? Это ручная работа. Боюсь,
что переоценка не сборочных мощностей, а кол-ва свободных рук и голов.

> Когда количество пактов с неработающих с lib64 станет меньше некой
> критической массы обрубить симлинк навсегда. Иначе мы рискуем вообще
> не получить x86_64 никогда.
Вот за эту рабочую неделю усилиями всего трёх человек можно было бы
собрать несколько десятков(!!!) зафикшенных пакетов. А вместо этого мы тут
разводим ля-ля. Да, действительно мы рискуем не получить x86_64 никогда. Я
уже собрал достаточную базу для того, чтобы желающие могли поставить себе
систему и заняться общественно полезным делом -- _фиксить_ и собирать.
Несговорчивость мантейнеров преодолеваема в административном порядке -
выкладывание NMU. Если же за работу примется хотя бы с пяток человек, то
можно сделать NMU более централизованным, чтобы эти изменения всё те же
мантейнеры не теряли. Каждый пересобранный пакет ставить на учёт, а при
появлении новой версии, с помощью скриптов выявлять были ли потеряны
изменения или нет. Думаю, сравнить старый и новый changelog не
представляет труда. В Сизифе уже бегает туча at@'ых роботов.

> P.S. Возможно я переоцениваю сборочные мощности...
Угу... ещё как :(

--
mouse

[devel] Re: x86_64, lib64 и все все все

[Sergey Bolshakov]

>>>>> "Anton" == Anton D Kachalov <mouse@altlinux.org> writes:
[skipped]

 > Несговорчивость мантейнеров преодолеваема в административном порядке -
 > выкладывание NMU.

Боюсь, в таком случае некто mouse@ останется майнтейнером половины
сизифа.

-- 

Re: [devel] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 01:03:09PM +0400, Sergey Bolshakov wrote:
> Боюсь, в таком случае некто mouse@ останется майнтейнером половины
> сизифа.
А с чего ты взял, что NMU будет делать некто mouse@? Я чё-то не понял. На
это существуют роботы.

--
mouse

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Igor Zubkov]

В сообщении от Пятница, 21-Окт-2005 11:03 Kirill A. Shutemov написал(a):
> Когда количество пактов с неработающих с lib64 станет меньше некой
> критической массы обрубить симлинк навсегда. Иначе мы рискуем вообще
> не получить x86_64 никогда.

Критическая масса пакетов уже есть.

-- 
Now playing: Evanescence [] [] Forgive me

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 12:22 Fri 21 Oct, Igor Zubkov wrote:
> В сообщении от Пятница, 21-Окт-2005 11:03 Kirill A. Shutemov написал(a):
> > Когда количество пактов с неработающих с lib64 станет меньше некой
> > критической массы обрубить симлинк навсегда. Иначе мы рискуем вообще
> > не получить x86_64 никогда.
> 
> Критическая масса пакетов уже есть.
у нас разные понятия о критической массе

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

automake -- конечно, сакс ещё тот; вместо того, чтобы облегчать жизнь
передовым/рядовым обывателям, он её усложняет... у-уууу... сакс...
		-- at in devel@

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

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 03:16:54PM +0300, Kirill A. Shutemov wrote:
> > Критическая масса пакетов уже есть.
> у нас разные понятия о критической массе
Можно список пожеланий :)

--
mouse

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 16:28 Fri 21 Oct, Anton D. Kachalov wrote:
> On Fri, Oct 21, 2005 at 03:16:54PM +0300, Kirill A. Shutemov wrote:
> > > Критическая масса пакетов уже есть.
> > у нас разные понятия о критической массе
> Можно список пожеланий :)
> 
По крайней мере 1/2 пакетной базы

-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

Freeze -- понятие сложное и многогранное...
		-- mike in community@

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

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Vital Khilko]

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

On Пят, 2005-10-21 at 16:11 +0300, Kirill A. Shutemov wrote:
> On 16:28 Fri 21 Oct, Anton D. Kachalov wrote:
> > On Fri, Oct 21, 2005 at 03:16:54PM +0300, Kirill A. Shutemov wrote:
> > > > Критическая масса пакетов уже есть.
> > > у нас разные понятия о критической массе
> > Можно список пожеланий :)
> > 
> По крайней мере 1/2 пакетной базы
или таки мир во всём мире? =)

-- 
И, вы знаете, я вам скажу откровенно, если б у меня журналист или
политик п одобным образом начал кричать, я б ему вырвал язык изо рта. 
                       -- А. Лукашенко

[-- Attachment #2: Гэтая частка паведамленьня падпісана электронным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 04:11:02PM +0300, Kirill A. Shutemov wrote:
> По крайней мере 1/2 пакетной базы
Не многова-то ли? :)
Половина пакетов - это gnome/kde + то, что уже есть + сервисы всякие. Это
даже больше половины.

--
mouse

Re: [devel][JT] Re: x86_64, lib64 и все все все

[Igor Vlasenko]

> > у нас разные понятия о критической массе
> Можно список пожеланий :)

emacs. 
Прошу прощения, я недавно начал собирать emacs
и не ориентируюсь, какие у него проблемы с x86_64.
Ваш патч приложен. 
Или проблема в emacs-base?
Где искать/кого допрашивать?

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

[devel] emacs-base (Was: x86_64, lib64 и все все все)

[Eugene Vlasov]

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

Приветствую, Igor Vlasenko.
В письме от Fri, Oct 21, 2005 at 04:23:14PM +0300 вы пишете:

> Прошу прощения, я недавно начал собирать emacs
> и не ориентируюсь, какие у него проблемы с x86_64.
> Ваш патч приложен. 
> Или проблема в emacs-base?

С emacs-base действительно есть проблемы. Этот пакет - noarch, но он
имеет файлы в %_libdir. Более того, эти файлы (точнее файл) -
shell-script с описанием нескольких используемых при сборке функций,
то есть место ему скорее всего в %_datadir.

У меня есть несколько предложений по поводу будущего emacs-base:
1. Разделить его на две части
   - стартовые скрипты emacs и все, что нужно emacs в работе оставить
     в emacs-base (или придумать более удачное название пакета).
   - то, что используется при сборке emacs и расширений вынести в
     отдельный пакет, скажем rpm-build-emacs или emacs-devel
2. Разумеется, убрать архитектурно-независимые части из %_libdir
3. Добавить в rpm-build-emacs макросы для /etc/emacs/site-start.d/ и
/usr/share/emacs/etc/ (куда предполагается складывать
архитектурно-независимые файлы расширений не содержащие код elisp),
возможно - макросы упрощающие байт-компиляцию отдельного файла и целого
каталога.

Хотелось бы услышать по поводу этих планов мнение заинтересованных
людей.


-- 
WBR, Eugene Vlasov        mailto:eugvv at altlinux.ru
                          JID: eugvv@jabber.ru

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

Re: [devel] emacs-base (Was: x86_64, lib64 и все все все)

[Igor Vlasenko]

On Fri, 21 Oct 2005, Eugene Vlasov wrote:

> С emacs-base действительно есть проблемы. Этот пакет - noarch, но он
> имеет файлы в %_libdir. Более того, эти файлы (точнее файл) -
> shell-script с описанием нескольких используемых при сборке функций,
> то есть место ему скорее всего в %_datadir.

Это я уже только что сделал :)
в инкоминге 0.0.5-alt1

> У меня есть несколько предложений по поводу будущего emacs-base:
> 1. Разделить его на две части
>    - стартовые скрипты emacs и все, что нужно emacs в работе оставить
>      в emacs-base (или придумать более удачное название пакета).
>    - то, что используется при сборке emacs и расширений вынести в
>      отдельный пакет, скажем rpm-build-emacs или emacs-devel

там на самом деле ничего не используется.
я написал на emacs@packages письмо по этому поводу,
emacs-lisp-pkgutils можно безболезненно отпилить.

> 2. Разумеется, убрать архитектурно-независимые части из %_libdir

done

> 3. Добавить в rpm-build-emacs макросы для /etc/emacs/site-start.d/ и
> /usr/share/emacs/etc/ (куда предполагается складывать
> архитектурно-независимые файлы расширений не содержащие код elisp),
> возможно - макросы упрощающие байт-компиляцию отдельного файла и целого
> каталога.

Я думаю, что это вопрос к Вам и к уважаемому И. Федорову,
поскольку Вы сейчас пересобираете emacs-*
и Вам по ходу виднее, что там реально нужно.
 
-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

Re: [devel] emacs-base (Was: x86_64, lib64 и все все все)

[Igor Vlasenko]

> > У меня есть несколько предложений по поводу будущего emacs-base:
> > 1. Разделить его на две части
> >    - стартовые скрипты emacs и все, что нужно emacs в работе оставить
> >      в emacs-base (или придумать более удачное название пакета).
> >    - то, что используется при сборке emacs и расширений вынести в
> >      отдельный пакет, скажем rpm-build-emacs или emacs-devel
> 
> там на самом деле ничего не используется.
> я написал на emacs@packages письмо по этому поводу,
> emacs-lisp-pkgutils можно безболезненно отпилить.

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

-- 

Dr. Igor Vlasenko
--------------------
Topology Departament
Institute of Math
Kiev, Ukraine

Re: [devel] emacs-base (Was: x86_64, lib64 и все все все)

[Eugene Vlasov]

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

Приветствую, Igor Vlasenko.
В письме от Fri, Oct 21, 2005 at 06:35:34PM +0300 вы пишете:

> Это я уже только что сделал :)
> в инкоминге 0.0.5-alt1

Посмотрим.

>>    - то, что используется при сборке emacs и расширений вынести в
>>      отдельный пакет, скажем rpm-build-emacs или emacs-devel

> там на самом деле ничего не используется.

Таки используется.

>> 3. Добавить в rpm-build-emacs макросы 

> Я думаю, что это вопрос к Вам и к уважаемому И. Федорову,

Разумеется, я беру на себя начальную реализацию rpm-build-emacs или
emacs-devel (никак не могу выбрать между этими названиями) и,
возможно, первоначальный вариант emacs packaging policy.


-- 
WBR, Eugene Vlasov        mailto:eugvv at altlinux.ru
                          JID: eugvv@jabber.ru

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

[devel] платформа для вендоров

[Vital Khilko]

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

On Пят, 2005-10-21 at 09:32 +0400, Anton Farygin wrote:

> В данном конкретном случае - платформа для вендоров.

Вот тут ты вроде прав. Но лично у меня сложилось ощущение что скорее для
местячковых ОЕМщиков. И всё это не на пустом месте - подкреплено
некоторыми неприятностями. Как известно мы в Sam Solutions допиливаем
пакеты из сизифа для ARM и далее  создаём собственные продукты для
забугорных заказчиков, это там, где GPL таки _реально_ работает и где
юристы требуют _строгого_ соблюдения лицензии, и где заказчик хочет быть
уверен что он ничего не нарушает и соблюдает каждую буковку закона. И
вот юрист заказчика задаёт элементарный казалось бы вопрос" а как у нас
с Copyright statement and distributed license per each binary package? а
сырцы? а патчи?" И тут  вдруг оказывается что всё плачевно... только 29
пакетов из порядка 300 что входят в наши дистрибутивы имеют хоть какую
либо информацию об авторском праве и лисензии на пакет, остальные лишь
ограничиваются тэгом в рпм, причём некоторое количество таких тэгов
содержат неверную информацию. И вот теперь в овральном порядке мы
вынуждены собирать всю необходимую информацию по каждому пакету и
пересобирать... а сборка на ARM занимает ой как много времени.  А между
тем тот же дебиан давно обошёл эти грабли и имеет строгое полиси на этот
счёт:

12.5 Copyright information

Every package must be accompanied by a verbatim copy of its copyright
and distribution license in the file /usr/share/doc/package/copyright.
This file must neither be compressed nor be a symbolic link.

In addition, the copyright file must say where the upstream sources (if
any) were obtained. It should name the original authors of the package
and the Debian maintainer(s) who were involved with its creation.

A copy of the file which will be installed in
/usr/share/doc/package/copyright should be in debian/copyright in the
source package.

/usr/share/doc/package may be a symbolic link to another directory in
/usr/share/doc only if the two packages both come from the same source
and the first package Depends on the second. These rules are important
because copyrights must be extractable by mechanical means.

Packages distributed under the UCB BSD license, the Artistic license,
the GNU GPL, and the GNU LGPL should refer to the files
/usr/share/common-licenses/BSD, /usr/share/common-licenses/Artistic,
/usr/share/common-licenses/GPL, and /usr/share/common-licenses/LGPL
respectively, rather than quoting them in the copyright file.

You should not use the copyright file as a general README file. If your
package has such a file it should be installed in
/usr/share/doc/package/README or README.Debian or some other appropriate
place.

-----------------------------------------------------------------------

http://lists.debian.org/debian-legal/2003/12/msg00194.html

>From a slightly different perspective, here's what you *should* do to
write a copyright file:

1) Find the license declaration in the upstream source. That should
look like this for GPLed works:

---
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
---

And similar. You are not looking for something that starts like this:

---
                    GNU GENERAL PUBLIC LICENSE
                       Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc.
     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
---

Or this:

---
                         The "Artistic License"

                                Preamble
---

You need to find the bit which says "This program is distributable
under (license X|the following license:)". It is absolutely *NOT*
implicit that if a copy of the GPL (or some other license) is included
in the source tree, the work is licensed under the GPL. If no such
statement is present, no copyright license has been granted; go and
get the upstream author to add one, or we can't distribute it at all.

Copy that statement _verbatim_ into the copyright file. There should
be (but does not have to be) a list of copyright owners and dates
accompanying it. If there is, copy that too. If there isn't, do your
best to make a list, and ask upstream to include it in the upstream
source tree and keep it up to date.

If you have sought and received mail from the copyright holder
clarifying the copyright or license, include that verbatim.

2) Include your own name, email address, and copyright dates,
identified as the package maintainer. Copyright subsists in Debian
packaging itself; it's easily complicated enough for that, so you have
partial copyright interest in anything you package. Never remove names
or dates from this list unless you are repackaging from scratch.

3) Include a description of how you obtained the upstream source
tarball. This should be sufficient for anybody to duplicate the
process immediately, but don't worry too much if it isn't (eg, the
server is not public or no longer accessible).

4) If the license itself is present in /usr/share/common-licenses/,
include a reference to that file. Otherwise, include the full text of
the license itself.

Думаю что и нам следует принять аналогичное полиси, и настроить
sisyphus_check
на его проверку. І тогда думаю ситуации подобной нашей или той что была
с драйверами nVidia, о которой рассказывал Сергей Большаков ,уже не
повториться нікогда. 
-- 
Бизнесмены - пиявки сосущие кровь -- А. Лукашенко. The Wall Street
Journal, 30 ноября 1996 г.

[-- Attachment #2: Гэтая частка паведамленьня падпісана электронным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] платформа для вендоров

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 11:56:17AM +0300, Vital Khilko wrote:
> On Пят, 2005-10-21 at 09:32 +0400, Anton Farygin wrote:
> 
> 12.5 Copyright information
> 
> Every package must be accompanied by a verbatim copy of its copyright
> and distribution license in the file /usr/share/doc/package/copyright.
> This file must neither be compressed nor be a symbolic link.
Насколько я знаю, у нас специально в каждый пакет не кладут файл с
лицензией. Для этого существует пакет common-licenses. А тэги кривые можно
и с каждым /usr/share/doc/package/copyright проставлять.

--
mouse

Re: [devel] платформа для вендоров

[Vital Khilko]

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

On Пят, 2005-10-21 at 14:34 +0400, Anton D. Kachalov wrote:
> On Fri, Oct 21, 2005 at 11:56:17AM +0300, Vital Khilko wrote:
> > On Пят, 2005-10-21 at 09:32 +0400, Anton Farygin wrote:
> > 
> > 12.5 Copyright information
> > 
> > Every package must be accompanied by a verbatim copy of its copyright
> > and distribution license in the file /usr/share/doc/package/copyright.
> > This file must neither be compressed nor be a symbolic link.
> Насколько я знаю, у нас специально в каждый пакет не кладут файл с
> лицензией. Для этого существует пакет common-licenses. А тэги кривые можно
> и с каждым /usr/share/doc/package/copyright проставлять.
Да но сколько из них имеют, как минимум, ссылку в пакете на
соответствующую лицензию из набора в пакете common-licenses?
А как насчёт verbatim copy of its copyright? 

-- 
Я знаю телодвижение каждого нашего спортсмена! Меня до сих пор трясет,
когда нашего парня сняли за 2 км до финиша в марафонской ходьбе! Это
сделал российский судья. Это предмет особого разговора в том числе и с
руководством России.                    -- А. Лукашенко

[-- Attachment #2: Гэтая частка паведамленьня падпісана электронным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] платформа для вендоров

[Igor Zubkov]

В сообщении от Пятница, 21-Окт-2005 13:56 Vital Khilko написал(a):
> Да но сколько из них имеют, как минимум, ссылку в пакете на
> соответствующую лицензию из набора в пакете common-licenses?

Т.е. что надо сделать что бы пакет был полностью правильным с вашей стороны? 
Неплохо было бы озвучить и оставить для потомков в wiki.

-- 
Now playing: Oomph! [Unrein] [] Willst Du Mein Leben Entern -

[devel] license test symlinks?

[Michael Shigorin]

On Fri, Oct 21, 2005 at 02:24:30PM +0300, Igor Zubkov wrote:
> > Да но сколько из них имеют, как минимум, ссылку в пакете на
> > соответствующую лицензию из набора в пакете common-licenses?
> Т.е. что надо сделать что бы пакет был полностью правильным с
> вашей стороны?  Неплохо было бы озвучить и оставить для
> потомков в wiki.

Я такие ссылки (какие и делал) погрохал, ибо License:.
Это не принципиальная позиция "вот нет и всё", просто
здравый смысл у нас и у них явно разный.

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

Re: [devel] license test symlinks?

[Vital Khilko]

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

On Пят, 2005-10-21 at 14:38 +0300, Michael Shigorin wrote:
> Я такие ссылки (какие и делал) погрохал, ибо License:.
> Это не принципиальная позиция "вот нет и всё", просто
> здравый смысл у нас и у них явно разный.
И отсутствие его сейчас у нас явно заужает область распространения
дистрибутивов ALT и производных от них. 

-- 
Руководителю правительства Китая Ли Пэну -- Лукашенко: "Хотя Вы человек
с Востока, но высочайшего европейского уровня руководитель". --
Цитируется по "Общая газета" Москва. 10-16 августа 1995 г.

[-- Attachment #2: Гэтая частка паведамленьня падпісана электронным подпісам --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] license test symlinks?

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 03:43:29PM +0300, Vital Khilko wrote:
> И отсутствие его сейчас у нас явно заужает область распространения
> дистрибутивов ALT и производных от них. 
Так давайте это обсудим. Тем более, если у вас есть соответствующие патчи,
то почему-бы вам ими с Team не поделиться?

--
mouse

[devel] [JT] Re: license test symlinks?

[Michael Shigorin]

On Fri, Oct 21, 2005 at 03:43:29PM +0300, Vital Khilko wrote:
> > Я такие ссылки (какие и делал) погрохал, ибо License:.
> > Это не принципиальная позиция "вот нет и всё", просто
> > здравый смысл у нас и у них явно разный.
> И отсутствие его сейчас у нас

Вы от них заразились?!

> явно заужает область распространения дистрибутивов ALT

Да ладно.  В community-en@ тихо.

> и производных от них. 

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

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

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

[devel] Re: платформа для вендури

[Michael Shigorin]

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

On Fri, Oct 21, 2005 at 02:34:18PM +0400, Anton D. Kachalov wrote:
> > Every package must be accompanied by a verbatim copy of its
> > copyright and distribution license
> Насколько я знаю, у нас специально в каждый пакет не кладут
> файл с лицензией. Для этого существует пакет common-licenses.

Не, там спич не о тексте лицензии, а о словах, которые говорят
"эта программа распространяется под такой-то лицензией".

Вообще говоря, это логично, но IMHO бессмысленно при условии
предоставления исходных текстов (содержащих эту отсылку или,
действительно, формально не покрытых той же GPL), наличия
аккуратных тегов License: и уведомления касательно конечного
продукта, которое упоминает требующие того лицензии
(составляющие) и гарантирует доступ к имеющим отношение
исходникам.

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

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

Понятно, что всякие MS и поднятием напряжённости на этом фронте
пытаются сузить зазор по стоимости разработки, но непонятно, при
чём тут team.

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

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

[devel] Re: платформа для вендури

[Michael Shigorin]

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

On Fri, Oct 21, 2005 at 11:56:17AM +0300, Vital Khilko wrote:
> и где юристы требуют _строгого_ соблюдения лицензии, и где
> заказчик хочет быть уверен что он ничего не нарушает и
> соблюдает каждую буковку закона. И вот юрист заказчика задаёт
> элементарный казалось бы вопрос" а как у нас с Copyright
> statement and distributed license per each binary package?

Ну так проспонсируйте проверку этих самых License: и добавление
copyright notice.  Потому как и люди вроде стараются их держать
в порядке, и подсказывают порой (мне at@ подсказывал раз или
два), но некоторый разнобой как минимум, припоминая последний
анализ, там есть.

> а сырцы? а патчи?" И тут  вдруг оказывается что всё плачевно...

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

А "по совести" -- так License: как на меня так эквивалент 
"да, да; нет, нет".  Поскольку вопросы предельной лицензионной
защищённости (это в смысле от гигантских дятлов) не стоят.

> И вот теперь в авральном порядке мы вынуждены собирать всю
> необходимую информацию по каждому пакету и пересобирать...
> а сборка на ARM занимает ой как много времени.  А между тем тот
> же дебиан давно обошёл эти грабли и имеет строгое полиси на
> этот счёт:

Я бы даже сказал "параноидальное".

Что может послужить поводом у них оные statements и повыдёргивать 
в случае, когда это не почта и не содержит слова "Debian".

> Думаю что и нам следует принять аналогичное полиси, и настроить
> sisyphus_check на его проверку.

Эта... если мы собираемся плясать под дудку америкосских лоеров,
то в Sisyphus есть ещё пачка всего, что по законам того или иного
штата некошерно.  Заканчивая эппловским хинтингом.

Кому надо работать с теми же америкосами (вам, нам, им) -- тот
пусть и занимается этой дурью.

Ну или действительно при данном раскладе дебиан может обойтись
дешевле в качестве платформы, как данность.

> І тогда думаю ситуации подобной нашей или той что была с
> драйверами nVidia, о которой рассказывал Сергей Большаков

?

PS: пошли в legal@?

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

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

Re: [devel] Re: x86_64, lib64 и все все все

[Denis Smirnov]

On Thu, Oct 20, 2005 at 07:56:34PM +0400, Алексей Турбин wrote:

AT> Кто под кого делает?  Вендоры делают для платформы или платформу делают
AT> под вендоров?  Впрочем, неприятный аспект идеологизированных решений --
AT> в том, что страдают от них простые пользователи, у которых зачастую нет
AT> выбора.

Конкретный пользователь выбирает ОС под приложения, а не наоборот.
Обратным образом поступают только маркетоиды, "идейные" и ламеры.

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

http://freesource.info

Re: [devel] x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 17:57 Wed 19 Oct, Anton D. Kachalov wrote:
> Вот привожу цитату из планов Debian, на который я ссылался, говоря о
> чруте.
> http://lists.debian.org/debian-devel-announce/2005/10/msg00004.html
> - multiarch support, to cure us of special-cased packages and source
>   duplication for architectures like amd64 and ppc64
> 
> Думаю, этим всё сказано. Все уважающие себя дистры делают полноценный biarch.
Ты не понял, я совершенно не против biarch. Это очень красивое светлое
будущее. Я посто предлгаю разбить задачу на два этапа:
1. Заставить пересобиратся Сизиф без lib->lib64 и пофиксить баги не
относящиеся к biarch(их, я думаю, тоже будет достаточно) т.о. в максимально 
сжатые сроки получить работоспособный x86_64 репозиторий
2. Приближать светлое будущее с lib64, патченьем apt, rpm и чё там ещё
нужно

Конструктивные возражения?
-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

У меня возникло непреодолимое желание обновить libpng3 во всех
поддерживаемых дистрибутивах до версии 1.2.7.

Если у кого-то есть противопоказания к этому обновлению, прошу не
откладывая сообщить об этом в нашу bugzillу.
		-- ldv in devel@

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

Re: [devel] x86_64, lib64 и все все все

[Anton D. Kachalov]

On Thu, Oct 20, 2005 at 10:15:14AM +0300, Kirill A. Shutemov wrote:
> Ты не понял, я совершенно не против biarch. Это очень красивое светлое
> будущее. Я посто предлгаю разбить задачу на два этапа:
> 1. Заставить пересобиратся Сизиф без lib->lib64 и пофиксить баги не
> относящиеся к biarch(их, я думаю, тоже будет достаточно) т.о. в максимально 
> сжатые сроки получить работоспособный x86_64 репозиторий
> 2. Приближать светлое будущее с lib64, патченьем apt, rpm и чё там ещё
> нужно

Берём п.1. И идём прямо по словам. "Заставить" - это уже некоторая работа,
подразумевающая патченье печеньем пакетов. И "пофиксить баги не
относящиеся к biarch (...)". Т.е. мы УЖЕ совершим два действия. Не говоря
уже о том, что из беготни ничего путного не выйдет.
Двигаемся в сторону п.2. "Приближать светлое будущее ...патченьем apt,rpm
и чё там ещё нужно". Мне кажется, что один проход по пакетам, а надо
заметить, что это каждый второй, уже был. Тем более, никто не берёт во
внимание, что "за время пути собака успела немного подрасти". Т.е.пакетная
база в Сизифе обновляется очень быстро. Мы тут потратили пару месяцев,
чтобы втащить большую часть моих изменений в Сизиф. Замечу, что суть этих
изменений, с точки зрения конечного пакета, неважна - будь это изменения,
касающиеся просто сборки в lib или же с дополнительными патчами в lib64.
Просто вы ещё не видете главной проблемы. Проблема не в СБОРКЕ и ПАТЧАХ
для x86_64/lib64, а в ВЛИВАНИИ в Сизиф! Думаю, это станет очевидным для
многих только после того, как они это испытают на собственной шкуре.
И проблема эта отнюдь не технического хараткера. Некоторые баги висят
неделями или месяцами вместе с dup'ами в Сизифе. Мы пробовали делать NMU.
Как и ожидалось, некоторые "добросоветсные" мантейнеры не только не
удосужились посмотреть в багзиллу или хотя бы взять новый пакет из Сизифа,
а просто собрали новый пакет с потерей всех изменений. Каково КПД
проделанной работы? Мне кажется, что нуль. Время и силы были убиты
впустую.
А вы предлагаете сделать это в два этапа.
> 
> Конструктивные возражения?
Х-м-м, без комментариев. :)

--
mouse

RE: [devel] x86_64, lib64 и все все все

[Sviataslau Svirydau]

Anton D. Kachalov wrote:

>... Мы пробовали делать NMU.
>Как и ожидалось, некоторые "добросоветсные" мантейнеры не только не
>удосужились посмотреть в багзиллу или хотя бы взять новый пакет из Сизифа,
>а просто собрали новый пакет с потерей всех изменений.
>
А как насчет того, чтобы организовать дополнительную проверку для 
обновленных пакетов на предмет непотерянности записей в changelog? :)
Стопроцентной гарантии это, конечно же не даст, но по кр. мере сможет 
выдавать варнинги при подозрениях на потерянные NMU...

-- 
Best regards,
Sviatoslav Sviridov

Re: [devel] x86_64, lib64 и все все все

[Anton D. Kachalov]

On Fri, Oct 21, 2005 at 11:57:26AM +0400, Sviataslau Svirydau wrote:
> А как насчет того, чтобы организовать дополнительную проверку для 
> обновленных пакетов на предмет непотерянности записей в changelog? :)
> Стопроцентной гарантии это, конечно же не даст, но по кр. мере сможет 
> выдавать варнинги при подозрениях на потерянные NMU...
Я про это в одном из соседних писем написал.

--
mouse

[devel] Re: x86_64, lib64 и все все все

[Alexey Tourbin]

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

On Fri, Oct 21, 2005 at 11:57:26AM +0400, Sviataslau Svirydau wrote:
> А как насчет того, чтобы организовать дополнительную проверку для 
> обновленных пакетов на предмет непотерянности записей в changelog? :)
> Стопроцентной гарантии это, конечно же не даст, но по кр. мере сможет 
> выдавать варнинги при подозрениях на потерянные NMU...

Это уже реализовано.  Робот packages выдаёт варнинги прямо в рассылку.

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

Re: [devel] Re: x86_64, lib64 и все все все

[Andrey Rahmatullin]

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

On Fri, Oct 21, 2005 at 05:53:56PM +0400, Alexey Tourbin wrote:
> Это уже реализовано.  Робот packages выдаёт варнинги прямо в рассылку.
А надо "прямо майнтейнеру".
Причем _до_ отправки пакета в сизиф.
В идеале.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<Nikon> raorn: у меня сегодня в трамвае спрашивали, как сквид поднять :)
        На футболке надпись прочитали.

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

Re: [devel] x86_64, lib64 и все все все

[Kirill A. Shutemov]

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

On 11:21 Fri 21 Oct, Anton D. Kachalov wrote:
> Берём п.1. И идём прямо по словам. "Заставить" - это уже некоторая работа,
> подразумевающая патченье печеньем пакетов. И "пофиксить баги не
> относящиеся к biarch (...)". Т.е. мы УЖЕ совершим два действия. Не говоря
> уже о том, что из беготни ничего путного не выйдет.
Баги про lib64 _нужно_ вешать и фиксить. Я просто считаю, что это minor
баги и фиксить их можно в background. Мухи отдельно, котлеты отдельно.
Мультилиб это круто, но ИМХО не приоретет. Мне нужна x86_64 система.

> Двигаемся в сторону п.2. "Приближать светлое будущее ...патченьем apt,rpm
> и чё там ещё нужно". Мне кажется, что один проход по пакетам, а надо
> заметить, что это каждый второй, уже был. Тем более, никто не берёт во
> внимание, что "за время пути собака успела немного подрасти". Т.е.пакетная
> база в Сизифе обновляется очень быстро. Мы тут потратили пару месяцев,
> чтобы втащить большую часть моих изменений в Сизиф. Замечу, что суть этих
> изменений, с точки зрения конечного пакета, неважна - будь это изменения,
> касающиеся просто сборки в lib или же с дополнительными патчами в lib64.
> Просто вы ещё не видете главной проблемы. Проблема не в СБОРКЕ и ПАТЧАХ
> для x86_64/lib64, а в ВЛИВАНИИ в Сизиф! Думаю, это станет очевидным для
> многих только после того, как они это испытают на собственной шкуре.
> И проблема эта отнюдь не технического хараткера. Некоторые баги висят
> неделями или месяцами вместе с dup'ами в Сизифе. Мы пробовали делать NMU.
> Как и ожидалось, некоторые "добросоветсные" мантейнеры не только не
> удосужились посмотреть в багзиллу или хотя бы взять новый пакет из Сизифа,
> а просто собрали новый пакет с потерей всех изменений. Каково КПД
> проделанной работы? Мне кажется, что нуль. Время и силы были убиты
> впустую.
> А вы предлагаете сделать это в два этапа.
Есть пакетА который не работает в x86_64 по двум причинам: авторы
подумали, что sizeof(int) == sizeof(int*) и забыли про lib64. Причём,
к примеру, первое решается довольно тривиально, а второе требует серьёзно
переломать всю архитектуру проекта. Ты предлагаешь ждать n-месяцев
пока upstream или maintainer придумает заковыристый патч решающий обе
проблеммы? По мне, так сперва нужно закрыть проблемму по которой прогамма
сигфолтится, а уже затем маятся с lib64.

Если изменения для lib64 тривиальны, они должны быть пофикшены наравне с
sizeof(int) == sizeof(int*)
-- 
Kirill A. Shutemov				Belarus, Minsk
E-mail:	k.shutemov (AT) sam-solutions.net
JID: kas (AT) altlinux.org
ICQ: 152302675

> Откуда берётся /lib/liblber.so.2 ?
Я бы спросил иначе: почему lib{lber,ldap}.so.2 опять в /usr/lib/?
Вечный бардак с этими openldapами...
		-- ldv in devel@

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