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'шные спеки с одним добавленным в конец патчем) Алексей Морозов.