From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <3B0A6705.2060705@novosoft.ru> Date: Tue, 22 May 2001 20:17:57 +0700 From: Alexey Morozov Organization: Novosoft, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3 i686; en-US; rv:0.9) Gecko/20010511 X-Accept-Language: ru, en MIME-Version: 1.0 To: sisyphus@altlinux.ru Subject: Re: [sisyphus] Re: [sisyphus] =?KOI8-R?Q?=E4=C1=D7=C1=CA=D4=C5=20=D3=D0=CF=D2=C9=D4=D8?= References: <3B05163A.3040800@novosoft.ru> <20010522134047.I12506@ldv.office.alt-linux.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Sender: sisyphus-admin@altlinux.ru Errors-To: sisyphus-admin@altlinux.ru X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: sisyphus@altlinux.ru List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Archived-At: List-Archive: Dmitry V. Levin wrote: >>что это, как не bloody hack, ломающий напрочь совместимость с >>остальными, собранными не в рамках AltLinux'а пакетами?? Чем, как не >> >Это не hack. >Когда мы год назад перешли на bzip2 с новым API, выяснилось, что >большинство использующих bzlib программ не поддерживают полностью новый API. >Тогда я принял решение вернуться к прежнему API до тех пор, пока >количество пакетов, поддерживающих новый API, не превысит количество >пакетов, не поддерживающих новый API. На момент выпуска Spring2001 время >перехода на новый API еще не наступило. Однако я за этим слежу. > Это, на мой взгляд, неверный подход. Если Вам нужно, чтобы была поддержка двух апи, то и нужно давать две библиотеки, предоставляющие данные апи: одна со старым, другая с новым. Зато потом, при переезде, не надо будет срочно пересобирать всех, кто таки или иначе был завязан на _любое_ из двух апи. А так, небось, еще и шибко умных, которые новое апи пользуют, хачить приходится :-/ (Ну, то есть, это необязательно, если там в заголовках все врапперами обернуто, но не исключается. А вот пересобирать точно придется). >Что касается бинарной совместимости, то ее никто Вам не гарантировал. > О чем и речь. Надо супер-пупер-куль софтваре от Васи Пупкина - медленно и печально идем, выкачиваем сорец, пишем спек, плюемся на Васю, снова пишем... И все это вместо того, чтобы честно пойти на rpmfind и выкачать [бинарный] rpm. Я Вас уверяю, после окончания великих революций типа переезда libc5->libc6, а потом (libc6->libc6.1) бОльшая часть пакетов ставится и работает вполне удовлетворительно безо всякой пересборки. Во всяком случае, на моей машине после установки год назад седьмого RHа и последующего "ползучего апгрейда" куча всего работает просто из коробки, там уже и MDK8 пакеты (в значительной степени) и ASPшные и ваши, ALTLinux'овые (мозилла вот, например, из-под которой пишу - ваша, спасибо вам за правку gtkembedded). Несомненно, что-то лучше пересобрать, 100% совместимости в бинарниках не будет, наверное (особенно, если при сборке выпендриваться и всякие "кульные фичи" включать). Но в целом механизм ld.so работает очень удовлетворительно, не надо его принудительно ломать. >>высчитывания зависимостей perl-пакетов (не perl(Some::Module), а >>perl(Some/Module.pm))? И чем последняя лучше общепринятой? И почему бы >> >Это Вам расскажет maintainer perl'а. > Угу. >>Тогда, уж коли нам забить на то, что в природе бывают RPMы, собранные не >>нами, не уползти под какой-нить, более продвинутый, нежели RPM package >> >Конкретнее, пожалуйста. И с вескими, убедительными аргументами. > Про что, про то, что бывают RPMы, собранные не на altair.office.altlinux.ru? Да, бывают :-) Про то, что бывают более продвинутые PM? Да, бывают, deb, например (хотя да, это повод для безрезультатного флейма, фиг с ним :-)) >Это опять про бинарную совместимость. > Это про совместимость с существующей RPMной базой. Мы либо вынуждаем пользоваться "нашим, только нашим, и ничем кроме нашего", либо не вынуждаем. Догадываетесь, к чему приведет такое вынуждение? >>В общем, насколько я понимаю, надо либо работать над собой, либо >>перестать пудрить мозги пользователям про совместимость. В последнем >> >Похоже, Вы на самом деле не интересовались вопросами совместимости. > :-). Наверное. Если Вам удобнее так думать. >>случае я, как человек, сидевший на KSI c момента его первых бет, >>построенных еще на RH4.9b, и потом, по, в общем, понятным причинам, >>поставивший RH7 (блин, надоело все руками собирать, захотелось >>попользовать блага цивилизации в виде RPMов, собранных где-то еще, хотя >>идеи, использованные Кубушиным при построении дистрибутива мне очевидным >> >Об этом подробнее, ибо то, что Вы называете очевидным, на самом деле не >факт и требует аргументации. > Мне нравилось: более четкие, по сравнению с RH принципы построения пакетов (то, что вы разносите сейчас по package, libpackage-devel, libpackage-devel-static, только у Кубушина -static принудительно собирался с -m386); (Замечу, тогда ничего более разумного чем RH в этой области (RPM-based дистрибутив линуха) фактически не существовало, напомню, речь о 97 годе, mdk не было, caldera существовала в виде openlinux-1.1 и была ценна лишь своей Novel-related частью (мы эти части вытащили, а потом коробка у дружка так и болталась на полке), а на сусь меня никогда особенно не тянуло :-)) нравилась локализация из коробки (да, я знаю о блуди хаке в Xах в KSI1 :-) и IPLabs'овой ругательной статье про это), но, насколько я понимаю, ничего лучшего _на тот момент_ просто не было, нравилось включение при сборке всяких фишечных опций (я до сих пор имею threaded и non-threaded perl'ы, хотя большинство вендоров, может, за исключением ActiveState'а не включают/включали threaded перл в поставку). В общем, Кубушину, Хименко и Co нужно сказать спасибо. Жаль, что все так вышло. >>образом нравятся больше), в общем, я советую пользователям завязывать с >>AltLinux'ом. Потому что кончится это тем, что вы начнете все >> >ALT Linux Team делает дистрибутив, а не занимается "пересборкой всего >руками". > Ваши пользователи будут либо вынуждены либо идти к вам на поклон (а вы можете заболеть, спиться, уехать на заработки, или еще какое несчастье приключится, не дай Бог, конечно), либо "собирать все сами". Меня, например, как человека, который _способен_ все собрать сам, но у которого просто нет времени сидеть и подгонять детальки, такое положение уже не устраивает. >>пересобирать руками, молясь, что отрубили в спеке все суперкулфичи. Но >>это крайняя мера, я еще надеюсь, что есть возможность договориться с AEN >>& Co :-). >> >Начинайте. > Уже. >Но осадок остался. > Ну, уж, звыняйте. Я увидел вопиющий, на мой взгляд, просчет в идеологии. Если такие ляпы допускать с самого начала, то конец, IMHO, будет грустным :-/. >>предметно на повод написания/переписывания /usr/lib/rpm/perl.{req,prov}? >> >К maintainer'ам perl'а и rpm'а. > Ok. Неплохо б только пообсуждать, что и как делать. Одна голова хорошо... >Опять Вы голословны, однако. > Хорошо. Пример кода: -------------------------------------------------- package Test::Module; use Config; if ($Config{'usethreads'}) { require Thread; # начинаем колбаситься в threaded model } else { # куча-куча форков и колбасенье через shmem/pipe } 1; ------------------------------------------------- рекомендую Вам поставить для хохмы два perl'а, так, чтобы Thread.pm оказался в путях и попробовать собрать такой вот пакет. Я Вас уверяю, Thread.pm _попадет_ в зависимости нашего модуля, хотя, гхм, ну, Вы видите... Собственно, я наткнулся на что-то похожее, хотя и не столь явно выраженное, когда собирал DBI, Нет, я еще раз повторю, я не знаю, как правильно. Возможно, совсем правильно, но ломово - руками. Да, еще вот. initscripts от AltLinux (впрочем, Mdkшные не сильно лучше :-)). Некорректно место в /etc/rc.d/init.d/halt: UnmountFilesystems 3 5 \ '!/(proc|loopfs|autofs|^none|^\/dev\/root| \/ )/ {print $2}' \ "Unmounting filesystems:" \ "Unmounting filesystems (retry):" Для тех, кто не верит - попробуйте такую вот раскладку: / ("Пол нэ важэн") /var ("Пол нэ важэн") /var/shm (ну, тут, понятно, тип shm). говорим в консоли /sbin/init 6, радуемся, глядя на umount failed. А все от того, что задали неверный regexp для откручивания всех ненужных файлух: правильным будет нечто вроде $3 != 'proc' && $3 != "devfs" && <вставьте все остальные условия> && $3 != "loop" && \ $2 != "/" (насчет loop'ов - тут проверять надо (и править), у меня их нет, по-хорошему, еще нужно оставлять ту файловую систему, на которой лежит initrd, но это уже детали). Также наличествуют косячки (ну, они у всех есть) в выставлении параметров харддиска (/etc/sysconfig/harddisk*) в об-devfs'ленном env. Для себя я, конечно, подправил, но там, по-хорошему, нужно подумать, как именно скакать по ide-дивайсам, вместо for i in a b c d e f; do # а не хард ли это часом? done мне больше нравится идея проскакать по /dev/discs/*, а потом, отдельно, по /dev/cdroms/*. Заодно и SCSI дивайсы захватим, а не только IDE, их тоже можно [пытаться] через hdparm загинать. Вот, в общем. Короче, мне интересно создание дистрибутива для профессионалов, качественного, рассчитанного на нестандартные конфигурации итп. Ради этого я, собственно, сюда и пишу, ради этого готов помогать по мере сил (хотя, признаюсь, я, в общем, не готов тратить на это много времени, у меня работа совсем другая). И не обижайтесь сильно на ругательный тон, "Спасибо! Поставил ALTLinux, в GNOME и KDE с русским полный порядок!" вам другие люди говорить будут, меня это уже не очень интересует, в большинстве мест я и сам локальку выставить могу :-). Алексей Морозов. P.S. А что, у всех получается в gnome-terminal запустить mc, сказать '+' '' на _дополнительной_ клавиатуре и получить выделение файлов? А то ведь уже второй год gnome-libs хачу для себя, а у всех типа все работает?