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

[Alexey Morozov <morozov@novosoft.ru>]

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, сказать '+' 
'<Enter>' на _дополнительной_ клавиатуре и получить выделение файлов? А 
то ведь уже второй год gnome-libs хачу для себя, а у всех типа все работает?