[sisyphus] Давайте ругаться

[sisyphus] Давайте ругаться

[Alexey Morozov]

В общем, чем дальше в лес, тем толще партизаны.

давеча AEN убеждал меня в том, что AltLinux не нарушает совместимости с 
остальными дистрибутивами, т.к. следует стандартам (его слова, 
натурально), а hvv - в том, что в AltLinux'е нет bloody hack'ов. Ну, по 
поводу такой трактовки совместимости я б еще поспорил, но как мне 
расценивать вот такой кусок SPEC'а (взято с
ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/SRPMS/bzip2-1.0.1-ipl7mdk.src.rpm#bzip2.spec:
--------------------------
# Revert to old API.
for n in `sed -ne 's/^BZ_EXTERN.*BZ_API(BZ2_\(bz[^)]*\).*/\1/gp' 
bzlib.h`; do
       find -type f |xargs fgrep -l "BZ2_$n" |xargs perl -pi -e 
"s/BZ2_$n/$n/g"
done
--------------------------

что это, как не bloody hack, ломающий напрочь совместимость с 
остальными, собранными не в рамках AltLinux'а пакетами?? Чем, как не 
ломанием напрочь совместимости является AltLinux'овая система 
высчитывания зависимостей perl-пакетов (не perl(Some::Module), а 
perl(Some/Module.pm))? И чем последняя лучше общепринятой? И почему бы 
тогда, уж коли нам забить на то, что в природе бывают RPMы, собранные не 
нами, не уползти под какой-нить, более продвинутый, нежели RPM package 
manager? А то ведь обман трудящихся сплошной получается: выглядит как 
пакет, предоставляющий libbz2, ставится как таковой, а вот при попытке 
попользовать его содержимое наивные librpmio (он у меня то ли от RH7, то 
ли от Mandrake8) отваливаются с криками про невозможность нахождения 
функции. "Абидна, да??"

В общем, насколько я понимаю, надо либо работать над собой, либо 
перестать пудрить мозги пользователям про совместимость. В последнем 
случае я, как человек, сидевший на KSI c момента его первых бет, 
построенных еще на RH4.9b, и потом, по, в общем, понятным причинам, 
поставивший RH7 (блин, надоело все руками собирать, захотелось 
попользовать блага цивилизации в виде RPMов, собранных где-то еще, хотя 
идеи, использованные Кубушиным при построении дистрибутива мне очевидным 
образом нравятся больше), в общем, я советую пользователям завязывать с 
AltLinux'ом. Потому что кончится это тем, что вы начнете все 
пересобирать руками, молясь, что отрубили в спеке все суперкулфичи. Но 
это крайняя мера, я еще надеюсь, что есть возможность договориться с AEN 
& Co :-).

Ну, в общем, флеймовая часть закончена :-), с кем можно поговорить 
предметно на повод написания/переписывания /usr/lib/rpm/perl.{req,prov}? 
То, что есть сейчас, в общем, не выдерживает критики. Нет, я еще не 
знаю, как надо, и уже знаю, что у остальных не лучше, а также то, что 
perl, beep-beep-beep, не предоставляет почти никаких средств для 
облегчения задачи, т.к. структура перлового модуля может быть очень 
причудливой :-/. Но пытаться надо, не руками же проставлять зависимости 
по всему CPANу. Сегодняшняя схема некорректна , примеров есть.

С уважением, Алексей Морозов.

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

[Dmitry V. Levin]

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

On Fri, May 18, 2001 at 07:31:54PM +0700, Alexey Morozov wrote:
> В общем, чем дальше в лес, тем толще партизаны.

Это неочевидно :)

> давеча AEN убеждал меня в том, что AltLinux не нарушает совместимости с 
> остальными дистрибутивами, т.к. следует стандартам (его слова, 
> натурально), а hvv - в том, что в AltLinux'е нет bloody hack'ов. Ну, по 
> поводу такой трактовки совместимости я б еще поспорил, но как мне 
> расценивать вот такой кусок SPEC'а (взято с
> ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/SRPMS/bzip2-1.0.1-ipl7mdk.src.rpm#bzip2.spec:
> --------------------------
> # Revert to old API.
> for n in `sed -ne 's/^BZ_EXTERN.*BZ_API(BZ2_\(bz[^)]*\).*/\1/gp' 
> bzlib.h`; do
>        find -type f |xargs fgrep -l "BZ2_$n" |xargs perl -pi -e 
> "s/BZ2_$n/$n/g"
> done
> --------------------------
> 
> что это, как не bloody hack, ломающий напрочь совместимость с 
> остальными, собранными не в рамках AltLinux'а пакетами?? Чем, как не 

Это не hack.
Когда мы год назад перешли на bzip2 с новым API, выяснилось, что
большинство использующих bzlib программ не поддерживают полностью новый API.
Тогда я принял решение вернуться к прежнему API до тех пор, пока
количество пакетов, поддерживающих новый API, не превысит количество
пакетов, не поддерживающих новый API. На момент выпуска Spring2001 время
перехода на новый API еще не наступило. Однако я за этим слежу.

Что касается бинарной совместимости, то ее никто Вам не гарантировал.

> ломанием напрочь совместимости является AltLinux'овая система 
> высчитывания зависимостей perl-пакетов (не perl(Some::Module), а 
> perl(Some/Module.pm))? И чем последняя лучше общепринятой? И почему бы 

Это Вам расскажет maintainer perl'а.

> тогда, уж коли нам забить на то, что в природе бывают RPMы, собранные не 
> нами, не уползти под какой-нить, более продвинутый, нежели RPM package 

Конкретнее, пожалуйста. И с вескими, убедительными аргументами.

> manager? А то ведь обман трудящихся сплошной получается: выглядит как 
> пакет, предоставляющий libbz2, ставится как таковой, а вот при попытке 
> попользовать его содержимое наивные librpmio (он у меня то ли от RH7, то 
> ли от Mandrake8) отваливаются с криками про невозможность нахождения 
> функции. "Абидна, да??"

Это опять про бинарную совместимость.

> В общем, насколько я понимаю, надо либо работать над собой, либо 
> перестать пудрить мозги пользователям про совместимость. В последнем 

Похоже, Вы на самом деле не интересовались вопросами совместимости.

> случае я, как человек, сидевший на KSI c момента его первых бет, 
> построенных еще на RH4.9b, и потом, по, в общем, понятным причинам, 
> поставивший RH7 (блин, надоело все руками собирать, захотелось 
> попользовать блага цивилизации в виде RPMов, собранных где-то еще, хотя 
> идеи, использованные Кубушиным при построении дистрибутива мне очевидным 

Об этом подробнее, ибо то, что Вы называете очевидным, на самом деле не
факт и требует аргументации.

> образом нравятся больше), в общем, я советую пользователям завязывать с 
> AltLinux'ом. Потому что кончится это тем, что вы начнете все 

ALT Linux Team делает дистрибутив, а не занимается "пересборкой всего
руками".

> пересобирать руками, молясь, что отрубили в спеке все суперкулфичи. Но 
> это крайняя мера, я еще надеюсь, что есть возможность договориться с AEN 
> & Co :-).

Начинайте.

> Ну, в общем, флеймовая часть закончена :-), с кем можно поговорить 

Но осадок остался.

> предметно на повод написания/переписывания /usr/lib/rpm/perl.{req,prov}? 

К maintainer'ам perl'а и rpm'а.

> То, что есть сейчас, в общем, не выдерживает критики. Нет, я еще не 
> знаю, как надо, и уже знаю, что у остальных не лучше, а также то, что 
> perl, beep-beep-beep, не предоставляет почти никаких средств для 
> облегчения задачи, т.к. структура перлового модуля может быть очень 
> причудливой :-/. Но пытаться надо, не руками же проставлять зависимости 
> по всему CPANу. Сегодняшняя схема некорректна , примеров есть.

Опять Вы голословны, однако.


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.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [sisyphus] Давайте ругаться

[Aleksey Novodvorsky]

On Fri, 18 May 2001 19:31:54 +0700
Alexey Morozov <morozov@novosoft.ru> wrote:

> В общем, чем дальше в лес, тем толще партизаны.
> 
>
> В общем, насколько я понимаю, надо либо работать над
> собой, либо 
> перестать пудрить мозги пользователям про совместимость. В
> последнем 
> случае я, как человек, сидевший на KSI c момента его
> первых бет, 
> построенных еще на RH4.9b, и потом, по, в общем, понятным
> причинам, 
> поставивший RH7 (блин, надоело все руками собирать,
> захотелось 
> попользовать блага цивилизации в виде RPMов, собранных
> где-то еще, хотя 
> идеи, использованные Кубушиным при построении дистрибутива
> мне очевидным 
> образом нравятся больше), в общем, я советую пользователям
> завязывать с 
> AltLinux'ом. Потому что кончится это тем, что вы начнете
> все 
> пересобирать руками, молясь, что отрубили в спеке все
> суперкулфичи. Но 
> это крайняя мера, я еще надеюсь, что есть возможность
> договориться с AEN 
> & Co :-).

Осатвьте эмоции для форумов. Здесь принято разговаривать
по-другому. Про bzip Вам ответили, про perl объяснит Михаил
Забалуев. Про идеи rpm можно поговорить.

Rgrds, AEN

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

[Alexey Morozov]

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 хачу для себя, а у всех типа все работает?

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

[Aleksey Novodvorsky]

On Tue, 22 May 2001 20:17:57 +0700
Alexey Morozov <morozov@novosoft.ru> wrote:

>
> >Что касается бинарной совместимости, то ее никто Вам не
> гарантировал.
> >
> О чем и речь. Надо супер-пупер-куль софтваре от Васи
> Пупкина - медленно 
> и печально идем, выкачиваем сорец, пишем спек, плюемся на
> Васю, снова 
> пишем... И все это вместо того, чтобы честно пойти на
> rpmfind и выкачать 
> [бинарный] rpm. Я Вас уверяю, после окончания великих
> революций типа 
> переезда libc5->libc6, а потом (libc6->libc6.1) бОльшая
> часть пакетов 
> ставится и работает вполне удовлетворительно безо всякой
> пересборки.
Да нет, не лукавьте! Ни хрена там не работает. Я уж не
говорю про SuSE, так и мандрейковские rpm с их updates-menu
будут ругаться под RH. И с init-scripts намучаетесь. А если
захотите установить Gnome, например, то утонете на
несовместисомсти версий библиотек. А KDE -- на разной i18n.
Мы отказались от бинарной совместимости с MDK только после
того, как создали стали поддерживать Sisyphus.


 Во 
> всяком случае, на моей машине после установки год назад
> седьмого RHа и 
> последующего "ползучего апгрейда" куча всего работает
> просто из коробки, 
> там уже и MDK8 пакеты (в значительной степени) и ASPшные и
> ваши, 
> ALTLinux'овые (мозилла вот, например, из-под которой пишу
> - ваша, 
> спасибо вам за правку gtkembedded).
> 
>


> 
> >Это опять про бинарную совместимость.
> >
> Это про совместимость с существующей RPMной базой. Мы либо
> вынуждаем 
> пользоваться "нашим, только нашим, и ничем кроме нашего",
> либо не 
> вынуждаем. Догадываетесь, к чему приведет такое
> вынуждение?

Эта база, увы, несовместима сама с собой. Ломать
совместимость без веских оснований -- плохо, если у нас
где-то это сделано -- плохо сделано, исправим. Но не
случайно тот же Helix собирает rpm для RH и MDK отдельно.
Таковы грустные реалии. 
Мы предлагаем пользователям:
-- совместимые по возможности c MDK пакеты;
-- большой выбор постоянно обновляющихся пакетов.
Что же Вы хотите? Гарантий? MDK начиная с 7.1 стал писать
про 99% совместимости с RH :-) Мы так шутить не будем.


> нравилась локализация из коробки (да, я знаю о блуди хаке
> в Xах в KSI1 
> :-) и IPLabs'овой ругательной статье про это), но,
> насколько я понимаю, 
> ничего лучшего _на тот момент_ просто не было,

Было. Но это отдельный вопрос.


> Ваши пользователи будут либо вынуждены либо идти к вам на
> поклон (а вы 
> можете заболеть, спиться, уехать на заработки, или еще
> какое несчастье 
> приключится, не дай Бог, конечно),


Да что же Вы все каркаете! Такое может в принципе случиться
и с MDK, и с RH (не дай Бог!). Тогда -- переходите на
Debian, который не развалится.
Выход, на самом деле, -- создать структуру, подобную Debian,
которая будет вести Sisyphus, -- мы к этому готовы, но это
непросто.


> либо "собирать все
> сами". Меня, 
> например, как человека, который _способен_ все собрать
> сам, но у 
> которого просто нет времени сидеть и подгонять детальки,
> такое положение 
> уже не устраивает.

Конечно. Но детали-то у всех разные, вот в чем вопрос. 

> 

> >
> Ну, уж, звыняйте. Я увидел вопиющий, на мой взгляд,
> просчет в идеологии. 
> Если такие ляпы допускать с самого начала, то конец, IMHO,
> будет 
> грустным :-/.

Что касается bzip -- это не вопиющий просчет (я полагаю, что
это не просчет вовсе), пример не вполне удачный.

> 
> >>предметно на повод написания/переписывания
> /usr/lib/rpm/perl.{req,prov}? 
> >>
> >К maintainer'ам perl'а и rpm'а.
> >
> Ok. Неплохо б только пообсуждать, что и как делать. Одна
> голова хорошо...

Несомненно.


> 
> Вот, в общем. Короче, мне интересно создание дистрибутива
> для 
> профессионалов, качественного, рассчитанного на
> нестандартные 
> конфигурации итп. Ради этого я, собственно, сюда и пишу,
> ради этого 
> готов помогать по мере сил (хотя, признаюсь, я, в общем,
> не готов 
> тратить на это много времени, у меня работа совсем
> другая). И не 
> обижайтесь сильно на ругательный тон, "Спасибо! Поставил
> ALTLinux, в 
> GNOME и KDE с русским полный порядок!" вам другие люди
> говорить будут, 
> меня это уже не очень интересует, в большинстве мест я и
> сам локальку 
> выставить могу :-).

Ok. Мы будем рады любым замечаниям и конструктивным
предложениям. Желательно, конечно, не подозревать нас в:
-- наполеонстве;
-- стремлении за счет несовместимости подгрести под себя
кучу пользователей;
-- болезненности (особенно свинкой) и алкоголизме.
А если еще возьметесь собирать какие-то пакеты -- совсем
здорово.



> 
> 
> Алексей Морозов.
> 
> P.S. А что, у всех получается в gnome-terminal запустить
> mc, сказать '+' 
> '<Enter>' на _дополнительной_ клавиатуре и получить
> выделение файлов? А 
> то ведь уже второй год gnome-libs хачу для себя, а у всех
> типа все работает?

У меня -- работает. Может, Spring поставите? :-)

Спасибо за это письмо.

Rgrds, AEN


> 
> 
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@altlinux.ru
> http://altlinux.ru/mailman/listinfo/sisyphus

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

[Aleksey Novodvorsky]

On Tue, 22 May 2001 21:50:35 +0400
Aleksey Novodvorsky <aen@logic.ru> wrote:

>
> > 
> > P.S. А что, у всех получается в gnome-terminal запустить
> > mc, сказать '+' 
> > '<Enter>' на _дополнительной_ клавиатуре и получить
> > выделение файлов? А 
> > то ведь уже второй год gnome-libs хачу для себя, а у
> всех
> > типа все работает?
> 
> У меня -- работает. Может, Spring поставите? :-)

Соврал! просто привык нажимать + -- не дополнительной, а
Enter -- на обычной.

Пришлите патч -- пересоберем.

Rgrds, AEN

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

[Dmitry V. Levin]

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

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:
<skip>

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

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

[Mikhail Zabaluev]

Hello Alexey,

On Tue, May 22, 2001 at 08:17:57PM +0700, Alexey Morozov wrote:
>
> >>высчитывания зависимостей perl-пакетов (не perl(Some::Module), а 
> >>perl(Some/Module.pm))? И чем последняя лучше общепринятой? И почему бы 
> >>
> >Это Вам расскажет maintainer perl'а.
> >
> Угу.

А что, и расскажу. Когда мы с Дмитрием обсуждали авто-зависимости для
Perl, никаких общепринятых схем, кроме perl-Some-Module в имени
пакета, на горизонте не было. Выбранная схема позволяет включать в
зависимости не только .pm-модули, но и .pl, .ph и -- теоретически --
любые другие. Почитайте внимательно TFM: оператор require допускает
явную файловую форму, а также разделитель "'" вместо "::". Вы уже
ненавидите Perl так, как ненавижу его я? :) Во всем этом разнобое
самыми надежными выглядят имена файлов.

> >>предметно на повод написания/переписывания /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,
> 
> Нет, я еще раз повторю, я не знаю, как правильно. Возможно, совсем 
> правильно, но ломово - руками.

Истинно так. AutoReq и AutoProv - подпорки, которые не должны
полностью заменять высшую нервную деятельность. Они должны работать
там, где эта деятельность не требуется. В тех же пакетах, где
встречаются такие require "из-за угла", AutoReq: perl (на финальной
стадии работы над пакетом) не используется.

В текущей версии скриптов perl.{req,prov} анализируются наиболее
распространенные формы операторов включения, да еще делается eval в
"сейфе" как попытка определения номера версии. Есть ухищрения, которые
можно применить -- например, в Perl 5.6.x можно прогнать байт-код
через декомпилятор, и если тот не загнется, получить идеально
выровненный текст, где уровень отступа означает вложенность. Но пока
не видно практической нужды увеличивать точность работы за счет
понижения производительности. Идеи, разумеется, приветствуются.
Особенно - в виде кода, патчей и т.п.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
The most costly of all follies is to believe passionately in the palpably
not true.  It is the chief occupation of mankind.
		-- H.L. Mencken

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

[Alexey Morozov]

[-- 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 --]

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

[Alexey Morozov]

Mikhail Zabaluev wrote:

>А что, и расскажу. Когда мы с Дмитрием обсуждали авто-зависимости для
>Perl, никаких общепринятых схем, кроме perl-Some-Module в имени
>пакета, на горизонте не было. Выбранная схема позволяет включать в
>
Гхм. Насколько я понимаю ситуацию, уже в 98 году у меня были модули, 
собранные именно через perl(Test::Module) :-)

>зависимости не только .pm-модули, но и .pl, .ph и -- теоретически --
>любые другие. Почитайте внимательно TFM: оператор require допускает
>явную файловую форму, а также разделитель "'" вместо "::". Вы уже
>
Я это знаю. Я профессиональный писатель на perl (ну, нет, разумеется, не 
только :-)) Я даже знаю, что require можно заменить на do + 
манипулирование %INC :-). А в некоторых, совсем клинических местах 
(например, у меня) встречается

$module = get_app_name($somedata);
eval "require $app"; # Вот именно так, в строчном контексте, чтобы не 
колбасить руками преобразование Test::Module -> Test/Module.pm :-)

Я это все знаю. Более того, пользуюсь. И поэтому не могу сказать: "а, вы 
все дураки, один я Д'Артаньян". Но думать надо. Вы не задумывались над 
тем, что бы пытаться грузить модуль, а потом анализировать изменения в 
%INC? По-видимому, это даст нам _минимальный_ набор требуемых модулей, 
хотя, конечно, если модули цепляются через require, там придется еще 
подумать, а удается ли их зацепить таким вот образом. Короче, надо думать...

>ненавидите Perl так, как ненавижу его я? :)
>
"Это наша родина, сынок" :-)

> Во всем этом разнобое самыми надежными выглядят имена файлов.
>
Собственно, большой разницы, что цеплять perl(Test/Module.pm) или 
perl(Test::Module) я не вижу (разве что, второе более наглядно и, 
наверное, более портабельно между системами :-)). Но вот как эти 
Test::Module выбирать - это вопрос...

>>Нет, я еще раз повторю, я не знаю, как правильно. Возможно, совсем 
>>правильно, но ломово - руками.
>>
>Истинно так. AutoReq и AutoProv - подпорки, которые не должны
>полностью заменять высшую нервную деятельность. Они должны работать
>
Глядя на размер CPAN начинаешь тосковать по более полезному применению 
"высшей нервной" :-)

>там, где эта деятельность не требуется. В тех же пакетах, где
>встречаются такие require "из-за угла", AutoReq: perl (на финальной
>стадии работы над пакетом) не используется.
>
>В текущей версии скриптов perl.{req,prov} анализируются наиболее
>распространенные формы операторов включения, да еще делается eval в
>"сейфе" как попытка определения номера версии. Есть ухищрения, которые
>можно применить -- например, в Perl 5.6.x можно прогнать байт-код
>через декомпилятор, и если тот не загнется, получить идеально
>выровненный текст, где уровень отступа означает вложенность. Но пока
>
Гхм... Что-то в этом есть...

>не видно практической нужды увеличивать точность работы за счет
>понижения производительности. Идеи, разумеется, приветствуются.
>Особенно - в виде кода, патчей и т.п.
>
Угу.

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

[Alexey Morozov]

Aleksey Novodvorsky wrote:

>>переезда libc5->libc6, а потом (libc6->libc6.1) бОльшая
>>часть пакетов 
>>ставится и работает вполне удовлетворительно безо всякой
>>пересборки.
>>
>Да нет, не лукавьте! Ни хрена там не работает. Я уж не
>говорю про SuSE, так и мандрейковские rpm с их updates-menu
>будут ругаться под RH. И с init-scripts намучаетесь. А если
>захотите установить Gnome, например, то утонете на
>несовместисомсти версий библиотек. А KDE -- на разной i18n.
>Мы отказались от бинарной совместимости с MDK только после
>того, как создали стали поддерживать Sisyphus.
>
Алексей, я сегодня уже демонстрировал так сказать summary по конкретным 
пакетам, теперь конкретные детали :-) :


[alex@sig SRPMS]$ rpm -qa --queryformat '%{NAME} %{BUILDHOST}\n' | grep 
'\(ximian.com\)\|\(helixcode.com\)'       
dia woolly-mammoth.helixcode.com
libvorbis-devel cul-de-sac.ximian.com
libgtop-devel cul-de-sac.ximian.com
helix-sweetpill woolly-mammoth.helixcode.com
libogg cul-de-sac.ximian.com
xml-i18n-tools cul-de-sac.ximian.com
memprof woolly-mammoth.helixcode.com
xalf cul-de-sac.ximian.com
libgtop cul-de-sac.ximian.com
swig cul-de-sac.ximian.com
libghttp cul-de-sac.ximian.com
libogg-devel cul-de-sac.ximian.com
ORBit-devel cul-de-sac.ximian.com
libghttp-devel cul-de-sac.ximian.com
libvorbis cul-de-sac.ximian.com
ORBit cul-de-sac.ximian.com
[alex@sig SRPMS]$ rpm -qa --queryformat '%{NAME} %{BUILDHOST}\n' | grep 
-i 'mandrakesoft.com' | grep -i gnome | wc -l
    28
[alex@sig SRPMS]$ _

А мозилла, наутилус и галеон у меня с altlinux.ru. И, все, что 
характерно, работает (ну, nau, конечно, тормозит, но русские шрифты 
антиалиасит и все такое), иначе, как бы я вам это все писал :-).

>Мы предлагаем пользователям:
>-- совместимые по возможности c MDK пакеты;
>-- большой выбор постоянно обновляющихся пакетов.
>Что же Вы хотите? Гарантий? MDK начиная с 7.1 стал писать
>про 99% совместимости с RH :-) Мы так шутить не будем.
>
В восьмерке - фраза "И запомните, Mandrake Linux 100% совместим с RedHat 
Linux" Натурально, зуб даю, домой схожу, посмотрю, где именно. Я, помню, 
веселился от души :-)

>>нравилась локализация из коробки (да, я знаю о блуди хаке
>>в Xах в KSI1 
>>:-) и IPLabs'овой ругательной статье про это), но,
>>насколько я понимаю, 
>>ничего лучшего _на тот момент_ просто не было,
>>
>Было. Но это отдельный вопрос.
>
Гхм... Ну, да ладно, оставим историкам преданья старины глубокой, Вы 
сейчас еще про "Линукс Красная Шапочка" имени Тоботраса вспомните :-)

>Да что же Вы все каркаете! Такое может в принципе случиться
>
Я вообще пессимист по натуре :-). Жить легче.

>и с MDK, и с RH (не дай Бог!). Тогда -- переходите на
>Debian, который не развалится.
>Выход, на самом деле, -- создать структуру, подобную Debian,
>которая будет вести Sisyphus, -- мы к этому готовы, но это
>непросто.
>
Согласен. Либо найти устойчивый источник финансирования. Насколько я 
могу судить, ни одному "русскому" линуксу этого до сих пор не удавалось.

>Конечно. Но детали-то у всех разные, вот в чем вопрос. 
>
Угу. На это maintainer'ы и существуют, себе-то я грязным хаком подправлю :-)

В общем, патчи я вам отправил, из актуального (для меня) остался еще 
xemacs-21.4, но там Алекс Махоткин разберется с локализацией, ему, 
вроде, удалось maintain'еров подбить на включение вещей, подобных 
Перминовскому rus-encodings, и отрепортить пару багов (один имени меня 
:-)). Я думаю, что к 21.4.3 можно будет аплоадить SRPM на альтлинукс. 
Да, кстати, я не смотрел, у вас xemacs-21.2 имеет в своей основе mdk? 
Дак там ляп в site-start.el :-/

>У меня -- работает. Может, Spring поставите? :-)
>
Не-а, не поставлю :-). Ставил уже :-)

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

[Mikhail Zabaluev]

Hello Alexey,

On Wed, May 23, 2001 at 08:44:19AM +0700, Alexey Morozov wrote:
>
> Mikhail Zabaluev wrote:
> 
> >А что, и расскажу. Когда мы с Дмитрием обсуждали авто-зависимости для
> >Perl, никаких общепринятых схем, кроме perl-Some-Module в имени
> >пакета, на горизонте не было. Выбранная схема позволяет включать в
> >
> Гхм. Насколько я понимаю ситуацию, уже в 98 году у меня были модули, 
> собранные именно через perl(Test::Module) :-)

Дистрибутив, plz. Это вряд ли был RH или Mandrake, с которыми имеет
смысл хотя бы декларировать совместимость.

> >зависимости не только .pm-модули, но и .pl, .ph и -- теоретически --
> >любые другие. Почитайте внимательно TFM: оператор require допускает
> >явную файловую форму, а также разделитель "'" вместо "::". Вы уже
> >
> Я это знаю. Я профессиональный писатель на perl (ну, нет, разумеется, не 
> только :-)) Я даже знаю, что require можно заменить на do + 
> манипулирование %INC :-). А в некоторых, совсем клинических местах 
> (например, у меня) встречается
> 
> $module = get_app_name($somedata);
> eval "require $app"; # Вот именно так, в строчном контексте, чтобы не 
> колбасить руками преобразование Test::Module -> Test/Module.pm :-)
> 
> Я это все знаю. Более того, пользуюсь. И поэтому не могу сказать: "а, вы 
> все дураки, один я Д'Артаньян". Но думать надо. Вы не задумывались над 
> тем, что бы пытаться грузить модуль, а потом анализировать изменения в 
> %INC? По-видимому, это даст нам _минимальный_ набор требуемых модулей, 
> хотя, конечно, если модули цепляются через require, там придется еще 
> подумать, а удается ли их зацепить таким вот образом. Короче, надо
думать...

Загрузка модуля через use чревата побочными эффектами, а в некоторых
файлах есть злостные блоки, которые выполняются при компиляции. Можно,
конечно, грузить их в сейфе с запретом на опасные операции, но все же
надежность и здравость такого решения в плане влияния на процесс
сборки сомнительна. Тормозить все это будет точно.

> >ненавидите Perl так, как ненавижу его я? :)
> >
> "Это наша родина, сынок" :-)

Ну нееет. Я уже собрал свой чемодан для переезда в Python.

> > Во всем этом разнобое самыми надежными выглядят имена файлов.
> >
> Собственно, большой разницы, что цеплять perl(Test/Module.pm) или 
> perl(Test::Module) я не вижу (разве что, второе более наглядно и, 
> наверное, более портабельно между системами :-)).

Вы видели где-нибудь эти зависимости perl(Test::Module)? Я,
признаться, долго не подымал головы, чтобы поглядеть через забор...

> Но вот как эти 
> Test::Module выбирать - это вопрос...

Повторюсь, этот вопрос мы однажды обдумали и решили так, как
решили. Какой-нибудь foo/bar.ph ведь не запишешь через
двоеточия. Кстати, почему я не слышу ругательств насчет версий с
эпохами? :)

> >>Нет, я еще раз повторю, я не знаю, как правильно. Возможно, совсем 
> >>правильно, но ломово - руками.
> >>
> >Истинно так. AutoReq и AutoProv - подпорки, которые не должны
> >полностью заменять высшую нервную деятельность. Они должны работать
> >
> Глядя на размер CPAN начинаешь тосковать по более полезному применению 
> "высшей нервной" :-)

На самом деле, плохого для наших скриптов кода в популярных модулях
не так уж и много. Авторы правильного Perl не такие уж и грязные
недисциплинированные хакеры, как можно себе представить :)
И потом, никто не собирается паковать в дистрибутив весь CPAN.
Оставьте кучу там, где ей лежать хорошо.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
Laugh when you can; cry when you must.

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

[Mikhail Zabaluev]

Hello Alexey,

On Wed, May 23, 2001 at 08:27:33AM +0700, Alexey Morozov wrote:
>
> >>Ваши пользователи будут либо вынуждены либо идти к вам на поклон (а вы 
> >>можете заболеть, спиться, уехать на заработки, или еще какое несчастье 
> >>приключится, не дай Бог, конечно), либо "собирать все сами". Меня, 
> >>например, как человека, который _способен_ все собрать сам, но у 
> >>которого просто нет времени сидеть и подгонять детальки, такое положение 
> >>уже не устраивает.
> >>
> >У Вас же не возникает желание взять пакет из 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]$ _

Reality check -- вы хотите, чтобы пакеты Sisyphus были бинарно
совместимы со всей этой сборной солянкой при отстутствии гарантий
бинарной совместимости у всех остальных производителей?
Та же libstdc++ несовместима между SUSE и RH6-based дистрибутивами с
одной стороны и новыми Mdk, AltLinux, RH -- с другой.

То есть здорово, конечно, если пакеты Ximian для RH7 загоняются в
систему Sisyphus без проблем. Ну, не будет их в меню, это мелочи.
Но пока что они не умеют разговаривать по-русски, и это их губит.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
SHHHH!!  I hear SIX TATTOOED TRUCK-DRIVERS tossing ENGINE BLOCKS into
empty OIL DRUMS ...

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

[Alexey Morozov]

Mikhail Zabaluev wrote:

>Reality check -- вы хотите, чтобы пакеты Sisyphus были бинарно
>совместимы со всей этой сборной солянкой при отстутствии гарантий
>бинарной совместимости у всех остальных производителей?
>
:-) Нет, я хочу, чтобы вендоры не пытались создавать мне проблем с 
совместимостью искусственным образом. Собственно, я это уже высказывал.

>Та же libstdc++ несовместима между SUSE и RH6-based дистрибутивами с
>одной стороны и новыми Mdk, AltLinux, RH -- с другой.
>
На здоровье. Дело не в том, чтобы всеми силами бороться против второго 
закона термодинамики, дело в отсутствии действий по претворению этого 
второго закона в жизнь :-)

>То есть здорово, конечно, если пакеты Ximian для RH7 загоняются в
>систему Sisyphus без проблем. Ну, не будет их в меню, это мелочи.
>Но пока что они не умеют разговаривать по-русски, и это их губит.
>
Гхм... :-)

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

[Aleksey Novodvorsky]

Hi!

On Wed, 23 May 2001 08:27:33 +0700
Alexey Morozov <morozov@novosoft.ru> wrote:


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


Может быть. Хотя, на самом деле, aspell совершенно не
подходит для русского. Мы будем переходить на словарь
Лебедева, благо nidd убедил автора сменить лицензию на Open
Source (деталей ее сейчас не помню, но в Debian уже этот
словарь).

> 

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

Спасибо, я посмотрю.

Rgrds, AEN

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

[Alexey Morozov]

Mikhail Zabaluev wrote:

>>>А что, и расскажу. Когда мы с Дмитрием обсуждали авто-зависимости для
>>>Perl, никаких общепринятых схем, кроме perl-Some-Module в имени
>>>пакета, на горизонте не было. Выбранная схема позволяет включать в
>>>
>>Гхм. Насколько я понимаю ситуацию, уже в 98 году у меня были модули, 
>>собранные именно через perl(Test::Module) :-)
>>
>Дистрибутив, plz. Это вряд ли был RH или Mandrake, с которыми имеет
>смысл хотя бы декларировать совместимость.
>
Ну, насколько я понимаю, одним из первых начал повсеместно использовать 
эту схему Кубушин. Но, насколько я понимаю, код был написан не в рамках KSI.

>>Я это все знаю. Более того, пользуюсь. И поэтому не могу сказать: "а, вы 
>>все дураки, один я Д'Артаньян". Но думать надо. Вы не задумывались над 
>>тем, что бы пытаться грузить модуль, а потом анализировать изменения в 
>>%INC? По-видимому, это даст нам _минимальный_ набор требуемых модулей, 
>>хотя, конечно, если модули цепляются через require, там придется еще 
>>подумать, а удается ли их зацепить таким вот образом. Короче, надо
>>
>Загрузка модуля через use чревата побочными эффектами, а в некоторых
>файлах есть злостные блоки, которые выполняются при компиляции. Можно,
>конечно, грузить их в сейфе с запретом на опасные операции, но все же
>надежность и здравость такого решения в плане влияния на процесс
>сборки сомнительна. Тормозить все это будет точно.
>
Гхм... _Тормозить_ (с большой буквы T) - "эт-вряд ли". Работать 
медленнее - да, наверняка.
Есть, конечно, опасность, что соответствующие модули будут гадить в 
"host-process" namespace и прочее, но это надо быть совсем зловредным и 
невоспитанным, насколько я понимаю, в рамках CPAN таковых модулей не 
должно быть много (то есть, _очень немного_). Для особых параноиков 
можно fork'аться и всю грязную работу проводить в отдельном процессе с 
контролем по времени исполения etc etc. Но факт, что руками пытаться 
вылавливать все use/require/do/eval - более чревато, и сильно менее 
прозрачно.

>>>ненавидите Perl так, как ненавижу его я? :)
>>>
>>Это наша родина, сынок" :-)
>>
>Ну нееет. Я уже собрал свой чемодан для переезда в Python.
>
А что, есть коммерческий спрос на программистов на python? Где 
записываться? :-)

>>Собственно, большой разницы, что цеплять perl(Test/Module.pm) или 
>>perl(Test::Module) я не вижу (разве что, второе более наглядно и, 
>>наверное, более портабельно между системами :-)).
>>
>Вы видели где-нибудь эти зависимости perl(Test::Module)? Я,
>признаться, долго не подымал головы, чтобы поглядеть через забор...
>
У KSI. У себя. Где-то еще, где пытаются автоматизировать процесс сборки 
и думают о последствиях (дебиан?). Но на самом деле, эта часть (включая 
зависимости по другим языкам/типам) - похоже, стала или становится 
стандартом в rpm-based distros. По крайней мере, в стоящем у меня RPM4 
имени Mdk8 вполне присутствует файл /usr/lib/rpm/find-req.pl (хотя это 
shell-скрипт и им, похоже, никто не пользуется :-)), аналогичный тому, 
что я подсмотрел в AltLinux'овом rpm-build. Тоже пытается догадаться, 
кто такой, и натравить соответствующую программу поиска зависимостей.

>Повторюсь, этот вопрос мы однажды обдумали и решили так, как
>решили. Какой-нибудь foo/bar.ph ведь не запишешь через
>двоеточия. Кстати, почему я не слышу ругательств насчет версий с
>эпохами? :)
>
:-). Рука бойцов колоть устала. :-)

>>Глядя на размер CPAN начинаешь тосковать по более полезному применению 
>>"высшей нервной" :-)
>>
>На самом деле, плохого для наших скриптов кода в популярных модулях
>не так уж и много. Авторы правильного Perl не такие уж и грязные
>недисциплинированные хакеры, как можно себе представить :)
>
:-) О чем и речь. Но все же, недостаточно дисциплинированные, чтобы 
говорить use Bla::Bla; в начале и успокаиваться :-)

>И потом, никто не собирается паковать в дистрибутив весь CPAN.
>Оставьте кучу там, где ей лежать хорошо.
>
Хех, "а рыбки-то хочется".

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

[S. Budnevitch]

On Wed, May 23, 2001 at 09:06:27AM +0700, Alexey Morozov wrote:
> Перминовскому rus-encodings, и отрепортить пару багов (один имени меня 
> :-)). Я думаю, что к 21.4.3 можно будет аплоадить SRPM на альтлинукс. 

Так он уж неделю как вышел.

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

[Alexey Morozov]

S. Budnevitch wrote:

>On Wed, May 23, 2001 at 09:06:27AM +0700, Alexey Morozov wrote:
>
>>Перминовскому rus-encodings, и отрепортить пару багов (один имени меня 
>>:-)). Я думаю, что к 21.4.3 можно будет аплоадить SRPM на альтлинукс. 
>>
>Так он уж неделю как вышел.
>
Гхм... Опять на соурсфорже страничку не проапдейтили?... В общем, тогда, 
видимо, ждем 21.4.4 :-). Хотя я сейчас посмотрю, если порядок загрузки 
custom.el и init.el поменяли местами, то, наверное, соберу... Но 
cyr-set-encodings все равно еще не готова, скорее всего :-/

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

[Mikhail Zabaluev]

Hello Alexey,

On Wed, May 23, 2001 at 06:02:33PM +0700, Alexey Morozov wrote:
>
> >Загрузка модуля через use чревата побочными эффектами, а в некоторых
> >файлах есть злостные блоки, которые выполняются при компиляции. Можно,
> >конечно, грузить их в сейфе с запретом на опасные операции, но все же
> >надежность и здравость такого решения в плане влияния на процесс
> >сборки сомнительна. Тормозить все это будет точно.
> >
> Гхм... _Тормозить_ (с большой буквы T) - "эт-вряд ли". Работать 
> медленнее - да, наверняка.
> Есть, конечно, опасность, что соответствующие модули будут гадить в 
> "host-process" namespace и прочее, но это надо быть совсем зловредным и 
> невоспитанным,

На это есть контрманевры, см 'perldoc Safe'.

> насколько я понимаю, в рамках CPAN таковых модулей не 
> должно быть много (то есть, _очень немного_). Для особых параноиков 
> можно fork'аться и всю грязную работу проводить в отдельном процессе с 
> контролем по времени исполения etc etc. Но факт, что руками пытаться 
> вылавливать все use/require/do/eval - более чревато, и сильно менее 
> прозрачно.

Пока что работает на достаточно большом количестве материала. Доля
ложных срабатываний как-то не настолько велика, чтобы заставить меня
чесаться :) Если есть готовый скрипт - тогда другое дело.

> >>>ненавидите Perl так, как ненавижу его я? :)
> >>>
> >>Это наша родина, сынок" :-)
> >>
> >Ну нееет. Я уже собрал свой чемодан для переезда в Python.
> >
> А что, есть коммерческий спрос на программистов на python? Где 
> записываться? :-)

Так я не из коммерческого интереса. Меня C/C++ неплохо кормят. А
вообще - наблюдая усилия ActiveState, проект Zope и поток PR'а,
превозносящего Python со всякими знаковыми словечками типа
maintainability, Jython и т.п., смею предположить, что спрос если не
есть уже, то будет в ближайшее время. Успех Perl в среде
веб-разработки объясняется IMHO тем, что массе недалеких, в-общем,
веб-девелоперов в одно время стал доступен свободный Web-сервер и
единственный практически годный свободный интерпретатор
скриптов. Чертовски кстати оказались книги от O'Reilly и действительно
грандиозная и небывалая штука - CPAN. Да что там, все мы выросли из
этой "шинели"... :)

> 
> >>Собственно, большой разницы, что цеплять perl(Test/Module.pm) или 
> >>perl(Test::Module) я не вижу (разве что, второе более наглядно и, 
> >>наверное, более портабельно между системами :-)).
> >>
> >Вы видели где-нибудь эти зависимости perl(Test::Module)? Я,
> >признаться, долго не подымал головы, чтобы поглядеть через забор...
> >
> У KSI. У себя. Где-то еще, где пытаются автоматизировать процесс сборки 
> и думают о последствиях (дебиан?). Но на самом деле, эта часть (включая 
> зависимости по другим языкам/типам) - похоже, стала или становится 
> стандартом в rpm-based distros. По крайней мере, в стоящем у меня RPM4 
> имени Mdk8 вполне присутствует файл /usr/lib/rpm/find-req.pl (хотя это 
> shell-скрипт и им, похоже, никто не пользуется :-)), аналогичный тому, 
> что я подсмотрел в AltLinux'овом rpm-build. Тоже пытается догадаться, 
> кто такой, и натравить соответствующую программу поиска зависимостей.

Эти скрипты там лежат мертвым грузом уже давно. Два из них я и модифицировал.

> >>Глядя на размер CPAN начинаешь тосковать по более полезному применению 
> >>"высшей нервной" :-)
> >>
> >На самом деле, плохого для наших скриптов кода в популярных модулях
> >не так уж и много. Авторы правильного Perl не такие уж и грязные
> >недисциплинированные хакеры, как можно себе представить :)
> >
> :-) О чем и речь. Но все же, недостаточно дисциплинированные, чтобы 
> говорить use Bla::Bla; в начале и успокаиваться :-)

Да ладно. Говорят, как миленькие.

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
There goes the good time that was had by all.
		-- Bette Davis, remarking on a passing starlet

[sisyphus] первый login

[Sergey S. Skulachenko]

Дмитрий!
Последний pam-0.75-alt3 проблему первого login'а пользователя
снял.
С уважением,
С.С.Скулаченко