Re: [sisyphus] Re: [sisyphus] Давайте спорить

[Alexey Morozov <morozov@novosoft.ru>]

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

Dmitry V. Levin wrote:

>но при этом поддержка прежнего
>API сохранена практически всеми производителями софта, поэтому проблем у
>пользователей нашего дистрибутива не будет, даже если они захотят собрать
>программу, не входящую в дистрибутив, как не было этой проблемы и раньше.
>
В общем, Бог с ним, с bzip'ом, я для себя собрал правильный, а уж дальше 
- хоть трава не расти :-)

>>Несомненно, что-то лучше пересобрать, 100% совместимости в бинарниках не
>>будет, наверное (особенно, если при сборке выпендриваться и всякие 
>>"кульные фичи" включать). Но в целом механизм ld.so работает очень 
>>удовлетворительно, не надо его принудительно ломать.
>>
>Если Вы имеете ввиду тот факт, что soname нашей bzlib и redhat'овской
>bzlib совпали, то это скорее всего не наша вина, ибо мы собрали
>bzip2-1.0.0 гораздо раньше redhat'а. Хотя, конечно, стоило бы предугадать
>и сменить soname сразу...
>
Я имею ввиду тот факт, что при смене одной библиотеки, как правило, 
необязательно менять скопом всех тех, кто на этой библиотеке был так или 
иначе завязан. Что-то - нужно будет сменить, но таких "подавляющее 
меньшинство" :-).

>Есть общепринятые стандарты (такие как FHS), и мы
>будем им следовать. Но пытаться реализовать 100% бинарную совместимость с
>чем-либо - значит в существенной мере подорвать разработку дистрибутива.
>Мы этого делать, разумеется, не будем. :)
>
Не надо делать 100% бинарную НЕсовместимость, и то ладно будет :-).

>>Ваши пользователи будут либо вынуждены либо идти к вам на поклон (а вы 
>>можете заболеть, спиться, уехать на заработки, или еще какое несчастье 
>>приключится, не дай Бог, конечно), либо "собирать все сами". Меня, 
>>например, как человека, который _способен_ все собрать сам, но у 
>>которого просто нет времени сидеть и подгонять детальки, такое положение 
>>уже не устраивает.
>>
>У Вас же не возникает желание взять пакет из suse и поставить его в redhat
>(или наоборот). Да и попытка взять mdk'шный пакет и поставить его в redhat
>скорее всего закончится неудачно.
>
Хе-хе. Глядите.
[alex@sig alex]$ rpm -qa | wc -l
   721
[alex@sig alex]$ rpm -qa --queryformat '%{BUILDHOST}\n' | grep 
'redhat.com' | wc -l
   316
[alex@sig alex]$ rpm -qa --queryformat '%{BUILDHOST}\n' | grep -i 
'mandrakesoft.com' | wc -l
   245
[alex@sig alex]$ rpm -qa --queryformat '%{BUILDHOST}\n' | grep 
'\(iplabs.ru\)\|\(altlinux.ru\)\|\(alt-linux.org\)\|\(novdv.ru\)' | wc -l
    68
[alex@sig alex]$ rpm -qa --queryformat '%{BUILDHOST}\n' | grep 
'\(ximian.com\)\|\(helixcode.com\)' | wc -l
    16
[alex@sig alex]$ rpm -qa --queryformat '%{BUILDHOST}\n' | grep 
'asplinux.ru' | wc -l
     6
[alex@sig alex]$ rpm -qa --queryformat '%{BUILDHOST}\n' | grep 'sig' | wc -l
    68
[alex@sig alex]$ cat /etc/redhat-release
Red Hat Linux release 7.0 (Guinness)
[alex@sig alex]$ _

При этом libc у меня от уже Mdk8, а libstdc++ - старая, от RH7. :-). Это 
не страшно, поверьте, "трудности и прелести секса в космосе сильно 
преувеличены" (С) Артур Кларк :-). Все работает, только шум стоит, и тут 
Вы, с bzip'ом... :-). В общем, предлагаю закрыть тему. Сойдемся на том, 
что полезно давать пакет libXXX-YYY.ZZZ, а при необходимости - давать 
пакет libXXX-compat-MMM.NNN.

>Нет, насколько я понимаю, развитие самостоятельного дистрибутива обречено
>на его бинарную несовместимость.
>А база пакетов Sisyphus тем временем расширяется...
>
На здоровье. Кстати, вы (altlinux team) рассматривали возможность 
"тиснуть" из ASPLinux'а aspell-ru? Я так понимаю, словарь, в общем, 
довольно полный, на обычных текстах aspell c этим словарем и ispell с 
Книжниковским ведут себя, кажется, сравнимо (хотя я не тестировал 
особо). А так всякие gnome-spell'ы заработают (может быть :-)).

>Вопросы идеологии построения дистрибутива - это не догмат, чтобы его
>нельзя было обсуждать. Скажем, если бы Вы написали про bzlib год назад, то
>я, возможно, мог бы сделать что-то иначе. Хотя других прецедентов,
>подобных bzlib (одинаковый soname при разном API), в дистрибутиве нет.
>
На том спасибо :-).

>Bug report maintainer'у initscripts отправлен, problem report #42.
>
Здорово.

>>(/etc/sysconfig/harddisk*) в об-devfs'ленном env. Для себя я, конечно, 
>>подправил, но там, по-хорошему, нужно подумать, как именно скакать по 
>>ide-дивайсам, вместо
>>for i in a b c d e f; do
>>  # а не хард ли это часом?
>>done
>>мне больше нравится идея проскакать по /dev/discs/*, а потом, отдельно, 
>>по /dev/cdroms/*.
>>
>Если бы Вы предложили проверять /proc/ide/hd*, это было бы понятно.
>Но вот /dev/discs/* и /dev/cdroms/* - это странно - в моей системе,
>например, этого нет вообще.
>
Гхм, в том-то вся и шутка. С подгу^H^H^H^H^H C devfs при его правильном 
использовании все может быть проще и приятнее. В общем, я _для себя_ 
сделал примерно так:

evvar="`cat /proc/mounts | awk '{print "HASDEVFS="$3,"; DEVFS="$2;}' | 
grep 'HASDEVFS=devfs'`"
eval $evvar

if [ -n "$HASDEVFS" ]; then
   if [ -d $DEVFS/discs ]; then
      pushd $DEVFS/discs
      for i in *; do
         # выставляем параметры тех, кто у нас сегодня называется диском
      done
      popd
   fi
   if [ -d $DEVFS/cdroms ]; then
      pushd $DEVFS/cdroms
      for i in *; do
        # выставляем параметры тех, кто у нас сегодня называется CD-ROM'ом
      done
      popd
   fi
else
   # старый кусок имени altlinux/mdk
fi

В общем, как мне кажется, такая схема работает чуть проще и чуть лучше, 
т.к. она покрывает не только IDE, но и всякие другие типы HD и CDROM'ов. 
Но ее работоспособность еще нужно (если нужно, конечно), проверять на 
всяких там pd и Co. Ну и со сказью - тоже непонятно, мне, к сожалению, 
не на чем проверить.

>У меня нет данных о том, что умеет делать hdparm с SCSI-дисками.
>Расскажите, будет интересно не только мне.
>
У меня, в общем, тоже только man page :-). Можно, конечно, один из 
конторских серверов изнасиловать во благо прогресса :-).

>Мы открыты к _конструктивному_ диалогу.
>
:-)

>Мы готовы воспринимать свежие идеи (и даже быстрее, чем redhat или mandrake).
>Welcome.
>
Именно поэтому я пишу вам, а не в Mdk или RH :-)

>Не стесняйтесь посылать патчи.
>
Посылаю. И, эта, Вы не рассматривали возможность включения в дистр т.н. 
gtk advanced file selector патча. Довольно удобная штука. Тоже в 
аттачменте (подходит для 1.2.10). .spec'и нужны? (Хотя там все просто, у 
меня это стандартные Mdk'шные спеки с одним добавленным в конец патчем)

Алексей Морозов.


[-- Attachment #2: gnome-libs-zvtkbdhack.patch.bz2 --]
[-- Type: application/octet-stream, Size: 378 bytes --]

[-- Attachment #3: gtk+-1.2.8-advanced-gtkfilesel-0.2.patch.bz2 --]
[-- Type: application/octet-stream, Size: 7713 bytes --]