Greetings! On Tue, May 22, 2001 at 08:17:57PM +0700, Alexey Morozov wrote: > >>что это, как не bloody hack, ломающий напрочь совместимость с > >>остальными, собранными не в рамках AltLinux'а пакетами?? Чем, как не > >> > >Это не hack. > >Когда мы год назад перешли на bzip2 с новым API, выяснилось, что > >большинство использующих bzlib программ не поддерживают полностью новый API. > >Тогда я принял решение вернуться к прежнему API до тех пор, пока > >количество пакетов, поддерживающих новый API, не превысит количество > >пакетов, не поддерживающих новый API. На момент выпуска Spring2001 время > >перехода на новый API еще не наступило. Однако я за этим слежу. > > > Это, на мой взгляд, неверный подход. Если Вам нужно, чтобы была > поддержка двух апи, то и нужно давать две библиотеки, предоставляющие > данные апи: одна со старым, другая с новым. > Зато потом, при переезде, не надо будет срочно пересобирать всех, кто > таки или иначе был завязан на _любое_ из двух апи. А так, небось, еще и > шибко умных, которые новое апи пользуют, хачить приходится :-/ (Ну, то > есть, это необязательно, если там в заголовках все врапперами обернуто, > но не исключается. А вот пересобирать точно придется). Решать задачи такого рода следует по мере их поступления. На момент выпуска bzip2-1.0.0 не было еще ни одного приложения, которое бы поддерживала новый API. Только сейчас многие производители софта обнаружили новый API и подправили свой код, но при этом поддержка прежнего API сохранена практически всеми производителями софта, поэтому проблем у пользователей нашего дистрибутива не будет, даже если они захотят собрать программу, не входящую в дистрибутив, как не было этой проблемы и раньше. > >Что касается бинарной совместимости, то ее никто Вам не гарантировал. > > > О чем и речь. Надо супер-пупер-куль софтваре от Васи Пупкина - медленно > и печально идем, выкачиваем сорец, пишем спек, плюемся на Васю, снова > пишем... И все это вместо того, чтобы честно пойти на rpmfind и выкачать > [бинарный] rpm. Я Вас уверяю, после окончания великих революций типа > переезда libc5->libc6, а потом (libc6->libc6.1) бОльшая часть пакетов > ставится и работает вполне удовлетворительно безо всякой пересборки. Во > всяком случае, на моей машине после установки год назад седьмого RHа и > последующего "ползучего апгрейда" куча всего работает просто из коробки, > там уже и MDK8 пакеты (в значительной степени) и ASPшные и ваши, > ALTLinux'овые (мозилла вот, например, из-под которой пишу - ваша, > спасибо вам за правку gtkembedded). > > Несомненно, что-то лучше пересобрать, 100% совместимости в бинарниках не > будет, наверное (особенно, если при сборке выпендриваться и всякие > "кульные фичи" включать). Но в целом механизм ld.so работает очень > удовлетворительно, не надо его принудительно ломать. Если Вы имеете ввиду тот факт, что soname нашей bzlib и redhat'овской bzlib совпали, то это скорее всего не наша вина, ибо мы собрали bzip2-1.0.0 гораздо раньше redhat'а. Хотя, конечно, стоило бы предугадать и сменить soname сразу... Несомненно, когда мы перейдем на новый bzlib API, то сменим soname нашей bzlib, чтобы облегчить upgrade. Еще раз: мы не занимаемся созданием искусственных несовместимостей с redhat, но и не стремимся к абсолютной совместимости; последнее никогда не входило в наши планы. Есть общепринятые стандарты (такие как FHS), и мы будем им следовать. Но пытаться реализовать 100% бинарную совместимость с чем-либо - значит в существенной мере подорвать разработку дистрибутива. Мы этого делать, разумеется, не будем. :) > >>Тогда, уж коли нам забить на то, что в природе бывают RPMы, собранные не > >>нами, не уползти под какой-нить, более продвинутый, нежели RPM package > >> > >Конкретнее, пожалуйста. И с вескими, убедительными аргументами. > > > Про что, про то, что бывают RPMы, собранные не на > altair.office.altlinux.ru? Да, бывают :-) Например, на basalt.office.altlinux.ru :) Конечно, бывают, тут важно не место сборки, а среда сборки. Если пакет собран в среде Spring, то он будет работать у всех пользователей Spring. > >Это опять про бинарную совместимость. > > > Это про совместимость с существующей RPMной базой. Мы либо вынуждаем > пользоваться "нашим, только нашим, и ничем кроме нашего", либо не > вынуждаем. Догадываетесь, к чему приведет такое вынуждение? Мы не ставим пользователей перед таким выбором. Хотя честно их предупреждаем: бинарной совместимости между разными дистрибутивами не бывает, разве что в случае, когда сторонний packager специально об этом позаботился. Это не значит, что не будет работать, это значит, что такой режим работы пакета не штатный, ибо не тестировался; со всеми возможными последствиями. > >>образом нравятся больше), в общем, я советую пользователям завязывать с > >>AltLinux'ом. Потому что кончится это тем, что вы начнете все > >> > >ALT Linux Team делает дистрибутив, а не занимается "пересборкой всего > >руками". > > > Ваши пользователи будут либо вынуждены либо идти к вам на поклон (а вы > можете заболеть, спиться, уехать на заработки, или еще какое несчастье > приключится, не дай Бог, конечно), либо "собирать все сами". Меня, > например, как человека, который _способен_ все собрать сам, но у > которого просто нет времени сидеть и подгонять детальки, такое положение > уже не устраивает. У Вас же не возникает желание взять пакет из suse и поставить его в redhat (или наоборот). Да и попытка взять mdk'шный пакет и поставить его в redhat скорее всего закончится неудачно. Нет, насколько я понимаю, развитие самостоятельного дистрибутива обречено на его бинарную несовместимость. А база пакетов Sisyphus тем временем расширяется... > >Но осадок остался. > > > Ну, уж, звыняйте. Я увидел вопиющий, на мой взгляд, просчет в идеологии. > Если такие ляпы допускать с самого начала, то конец, IMHO, будет > грустным :-/. Вопросы идеологии построения дистрибутива - это не догмат, чтобы его нельзя было обсуждать. Скажем, если бы Вы написали про bzlib год назад, то я, возможно, мог бы сделать что-то иначе. Хотя других прецедентов, подобных bzlib (одинаковый soname при разном API), в дистрибутиве нет. > Да, еще вот. initscripts от AltLinux (впрочем, Mdkшные не сильно лучше > :-)). Некорректно место в /etc/rc.d/init.d/halt: 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/* - это странно - в моей системе, например, этого нет вообще. > Заодно и SCSI дивайсы захватим, а не только IDE, их тоже можно > [пытаться] через hdparm загинать. У меня нет данных о том, что умеет делать hdparm с SCSI-дисками. Расскажите, будет интересно не только мне. > Вот, в общем. Короче, мне интересно создание дистрибутива для > профессионалов, качественного, рассчитанного на нестандартные > конфигурации итп. Ради этого я, собственно, сюда и пишу, ради этого > готов помогать по мере сил (хотя, признаюсь, я, в общем, не готов > тратить на это много времени, у меня работа совсем другая). И не Мы открыты к _конструктивному_ диалогу. Мы готовы воспринимать свежие идеи (и даже быстрее, чем redhat или mandrake). Welcome. > P.S. А что, у всех получается в gnome-terminal запустить mc, сказать '+' > '' на _дополнительной_ клавиатуре и получить выделение файлов? А > то ведь уже второй год gnome-libs хачу для себя, а у всех типа все работает? Не стесняйтесь посылать патчи. Regards, Dmitry +-------------------------------------------------------------------------+ Dmitry V. Levin mailto://ldv@alt-linux.org ALT Linux Team http://www.altlinux.ru/ Fandra Project http://www.fandra.org/ +-------------------------------------------------------------------------+ UNIX is user friendly. It's just very selective about who its friends are.