ALT-Linux объявляет о начале тестирования серверного дистрибутива

> Вообще, честно говоря, FC я уже даже не смотрел.

FC4 - это основа RHEL4, IIRC

>Этого вообще ни один дистр не делает, RPM или нет. :(

ты Debian видел?

>во всех руководствах по сборке RPM-пакетов сказано, что скрипты - НЕинтерактивны.

вот, а скрипты для deb могут быть интерактивны. мало того сделано все для простой интернационализации

>В общем, RPM - конечно, не идеал, но не надо ему приписывать лишнего (типа неумения общаться с debconf).

так это не приписывается, это наоборот, говорится: такой возможности нет - ПЛОХО.

> > Я не вижу тут проблем, которые бы сильно мешали жить.

> зато я вижу :) это когда totem-xine тянет за собой кдеешный arts

$ apt-cache depends totem-xine|grep arts
$

Не вижу. Может кошек готовить уметь надо ?

>>Этого вообще ни один дистр не делает, RPM или нет. :(

>ты Debian видел?

Да. И внимательно (хотя и давно) прочитал руководство по созданию пакетов.

> а скрипты для deb могут быть интерактивны.

Поправь меня, если я ошибаюсь, но "интерактивность" скриптов в .deb заключается в том, что они взаимодействуют с базой debconf, а не пользователем. Точно так же могут поступить и скрипты в RPM - если будет желание разработчиков дистра.

>>В общем, RPM - конечно, не идеал, но не надо ему приписывать лишнего (типа неумения общаться с debconf).

>так это не приписывается, это наоборот, говорится: такой возможности нет - ПЛОХО.

Я попробую еще раз: это не является недостатком RPM, это недостаток _дистрибутивов_, в том числе - и не основанных на RPM. ALT использовал apt-get - может, они и debconf адаптируют.

> это основа RHEL4

RHEL4 я тоже не смотрел. :-)

> RHEL4 я тоже не смотрел. :-)

Ну, тогда заявления типа "наш RPM лучше" - это, ммм, некорректно? Вы не считаете RHEL конкурентом?

> Или ты хочешь сказать, что ALT Linux'овые аналоги работают лучше RedHat'овских?

Таки да, благодаря трудам Алексея Турбина.

> В FC4 (отнюдь не новой) уже есть.

Там используется пакеты из jpackage, в которых трудолюбивыми ручками в спеках прописываются зависимости. Это не автомат, и даже не полуавтомат.

>Поправь меня, если я ошибаюсь, но "интерактивность" скриптов в .deb заключается в том, что они взаимодействуют с базой debconf, а не пользователем. Точно так же могут поступить и скрипты в RPM - если будет желание разработчиков дистра.

да ты ошибаешься. deb-скрипты взаимодействуют именно с пользователем и на этом построено множество разного рода конфигураторов: устанавливаешь пакет, а он несколькими вопросами к тебе устанавливается в уже сконфигурированном для тебя виде, так же можно вызвать эти настроечные диалоги позже.

это очень сильная сторона Debian: фактически куча дистрибутивов работала над созданием разного рода linuxconf'ов, но универсального конфигуратора приемлемого качества так и не создано.

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

>Я попробую еще раз: это не является недостатком RPM, это недостаток _дистрибутивов_,

я бы с тобой согласился будь хоть один RPM дистрибутив с этими возможностями. однако его нет. и это говорит скорее о проблемах в "консерватории" (RPM) нежели о музыкантах (дистростроители)

>> В FC4 (отнюдь не новой) уже есть.

>Там используется пакеты из jpackage, в которых трудолюбивыми ручками в спеках прописываются зависимости. Это не автомат, и даже не полуавтомат.

я говорю о /usr/lib/rpm/javadeps, а ты мне об отсуствии автоматизации. Причем здесь jpackage? :/

> Не вижу. Может кошек готовить уметь надо ?

это в пятой федоре было. Раз ты говоришь что rpm в альте круче и фичастее, значит так оно есть ;)

> Кто юзал сабж?

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

> > RHEL4 я тоже не смотрел. :-)

> Ну, тогда заявления типа "наш RPM лучше" - это, ммм, некорректно?

Оно верно с учётом некоторой экстраполяции в прошлое, на уровень RH 7.3/Master 2.4. Хотя, конечно, Мастер поновее на тот момент был.

> Вы не считаете RHEL конкурентом?

Хозяйство, с которым работаю я, работает на Alt, а не RH... Соответственно, по совокупности факторов, не конкурент на текущий момент. Если завтра факторы изменятся, буду смотреть завтра.

Вообще в Alt мне нравится то, что я реально имею шанс получить от дистрибутива нужное именно мне. Может быть, это случайность в какой-то мере, но меня устраивает.

> я говорю о /usr/lib/rpm/javadeps, а ты мне об отсуствии автоматизации. Причем здесь jpackage? :/

Ну, вон, JB написал про totem-xine. В Alt это не вылезло. Довод ?

http://tv.rambler.ru/event.html?event=13372807&d=2007-04-04

> да ты ошибаешься. deb-скрипты взаимодействуют именно с пользователем и на этом построено множество разного рода конфигураторов: устанавливаешь пакет, а он несколькими вопросами к тебе устанавливается в уже сконфигурированном для тебя виде, так же можно вызвать эти настроечные диалоги позже.

очень удобно использовать подобные вещи на машине с автоапдейтами ;-)

в rpm это делается на раз-два, но ни один идиот делать не будет - под всех не угодишь. Если надо - в постинсталл скрипте лучше написать, что и как запускать для конфигурирования с использованием рюшечек, чем использовать интерактивность, там, где не надо.

Этак скоро "в заботе о пользователе" нельзя будет сделать апдейт машины без установленных иксов и открытого графического терминала ;-(

Что дает этот javadeps? Где он используется?

Вот у меня тут FC5. Проверяю на пакете ant-1.6.5-1jpp_7fc.i386.rpm.

В списке provides нету никаких java(org.apache.tools.ant.*)

В списке Requires - тоже.

Если бы этот javadeps использовался - там было бы куча java(*) Provides и Requires. Всего этого нет. Зависимости пакетов пишутся по старинке, вручную.

> а ты мне об отсуствии автоматизации.

Ещё момент. Собирал сегодня пакет. В пакет положил скрипт с ошибкой. Сборка не прошла. Пустячок, а приятно...

> да ты ошибаешься. deb-скрипты взаимодействуют именно с пользователем

Значит, я серьезно недопонял такие фразы, как:

"Briefly, debconf communicates with maintainer scripts or other programs via standard input and output, using a simple line-oriented command language similar to that used by common internet protocols such as SMTP. Programs use this protocol to ask debconf to display questions to the user, and retrieve the user's answers. "

и

"Package maintainer scripts may prompt the user if necessary. Prompting should be done by communicating through a program, such as debconf, which conforms to the Debian Configuration management specification, version 2 or higher. Prompting the user by other means, such as by hand[8], is now deprecated."

:)

> проблемах в "консерватории" (RPM) нежели о музыкантах (дистростроители)

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

> Оно верно с учётом некоторой экстраполяции в прошлое, на уровень RH 7.3/Master 2.4

В прошлый век :D

> Хозяйство, с которым работаю я, работает на Alt, а не RH...

Сорри, я принял вас за разработчика дистрибутива ;)

> Если надо - в постинсталл скрипте лучше написать, что и как запускать для конфигурирования

Это как? Чтобы он на экране напечатал инструкции по дальнейшему конфигурированию? o_O

> Этак скоро "в заботе о пользователе" нельзя будет сделать апдейт машины без установленных иксов и открытого графического терминала ;-(

Гон^WКажется, ты знаком с debconf еще хуже, чем я ;) Это система, предназначенная для unattended installation.

> > Хозяйство, с которым работаю я, работает на Alt, а не RH...

> Сорри, я принял вас за разработчика дистрибутива ;)

Не надо извиняться. :-)

Было несколько пакетов, состояние которых меня не устроило и кое-чего, мне нужного, не хватало. Так что пришлось впрячься. Но основная моя работа - это именно эксплуатация результата. В какой-то момент пришлось выбирать, что удобнее эксплуатировать. Это, как раз, момент рождения FC был, а до того, как раз, эксплуатировался RH.

> пришлось выбирать, что удобнее эксплуатировать. Это, как раз, момент рождения FC был

в те времена ALT мог из-за одного apt-get быть удобнее. Хотя лично я привинтил apt-get от Connectiva к RH7.2 и жизнь наладилась :D

>в те времена ALT мог из-за одного apt-get быть удобнее. Хотя лично я >привинтил apt-get от Connectiva к RH7.2 и жизнь наладилась :D

Ага. .только вот зависимости в RH не предполагают его использование с apt-get'ом, а apt весьма и весьма требователен к качеству зависимостей и если что не так - начинает выносить часть системы (unmet'ы, например).

Соответственно базу пакетов, которая специально продуманно не делается под APT - невозможно корректно с его помощью эксплуатировать.

Меня поддержат люди как и из Debian, так и из ALT'а.

>Аутентификация не через /etc/shadow (ldap, winbind, *sql).

Вполне может быть сделана силами nss. Вообще единственный testcase, который действительно стоит упоминания --- это всевозможная нестандартная авторизация --- брелками, отпечатками пальцев и сканированием радужки, смарткартами, одноразовыми паролями. И то в силу того, что драйвера для такого дела исторически пишутся для pam, а не для nss.

> в те времена ALT мог из-за одного apt-get быть удобнее.

а теперь вот etcnet. Преимущества начинаешь ощущать, когда интерфейсов сильно больше одного. Причём даже с ещё имеющимися недостатками.

> зависимости в RH не предполагают его использование с apt-get'ом

> базу пакетов, которая специально продуманно не делается под APT - невозможно корректно с его помощью эксплуатировать.

Ну, значит мне везет последние несколько лет - я apt-get и на FC использую. И еще куча народа использует - и ничего. Везет нам.

"Качество зависимостей", надо же. Чем оно для yum или smartpm другое?

"Чем оно для yum или smartpm другое?"

а что, smartrpm или yum не устраивает ?

Кстати, если вы используете apt-rpm, то значит вы пользуетесь тем, в разработке чего участвовали люди из ALT.

Ну и я сильно надеюсь, что тот анонимус, который тут в серёдке долго пытался запостить что-нибудь оскорбительное, не является одним из ведущих разработчиков из Team.

> а что, smartrpm или yum не устраивает ?

yum - тормозное у#бище, smart - выглядит интересно, но у меня уже есть работающий apt-get.

> Кстати, если вы используете apt-rpm, то значит вы пользуетесь тем, в разработке чего участвовали люди из ALT.

Знаю. Благодарен людям из ALT за это. Только жаль, что они распыляют силы.

> >Обоснуй. :-)

> например скрипты пост-пре-конфиг.
> в rpm их писать вроде бы и можно,

Я, почему-то, пишу. И не только я.

> потому что неизвестно в какой гуйне этот rpm ставиться будет.

Известно. В той, для которой его собирали. А если не в той, то надо с src.rpm начинать.

>очень удобно использовать подобные вещи на машине с автоапдейтами ;-)

этот вопрос кстати очень продуман в Debian. апдейты != инсталляция

и debian можно автоапдейтить из секьюрити-апдейтов совершенно спокойно.

я кстати с АЛЬТлинукса ушел в свое время именно из за того что наткнулся на некорректный автоапдейт из секьюрити-репозитария в стабильном Мастер2.0 (была большая трабла в постфиксе).

>в rpm это делается на раз-два, но ни один идиот делать не будет - под всех не угодишь.

гхм в deb- это получается, а в rpm ни один идиот делать не будет. так и что лучше deb или rpm? ;)

>Если надо - в постинсталл скрипте лучше написать, что и как запускать для конфигурирования с использованием рюшечек, чем использовать интерактивность, там, где не надо.

это костыли от непроработанности rpm

>Этак скоро "в заботе о пользователе" нельзя будет сделать апдейт машины без установленных иксов и открытого графического терминала ;-(

глупость. debian вполне хорошо обновляется и без Хов. у меня несколько серверов об Х'ах и не помышляли. :)

>Значит, я серьезно недопонял такие фразы, как:

серьезно недопонял :)

примерная структура вызовов скриптов есть тут: http://wiki.debian.org/DebianRussian/deb-inside

а вкратце работает так:

скрипт config задает вопросы через систему debconf. причем система debconf отслеживает какие вопросы ранее задавались а какие нет (вообще этим поведением можно управлять). И перечень вопросов соответственно сильно сокращается если два раза вызвать конфиг. (есть еще реконфиг).

так вот, при повторном вызове вопросы задаваться не будут, ибо пользователь на них уже ответил :)

а при реконфигурации (которую может инициировать пользователь) все блоки диалога могут быть опять перевызваны.

PS: кстати debconf-devel переведен на русский язык, ты мог бы его посмотреть :)

>А я бы согласился насчет дистростроителей, если бы еще хоть кто-нибудь (скажем, те, кто не используют RPM) использовал debconf :)

я же не говорю о конкретно debconf, я говорю об идентичной функциональности. ее в не-deb дистрибутивах нет просто :(

>но debconf разрабатывался, чтобы быть независимым от пакетного менеджера.

это да, но интерактив в rpm не попал. потому и debconf не попал. вот АЛЬТы своим патченьем rpm (о котором говорилось выше) могли бы и добавить.

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

"Ну и я сильно надеюсь, что тот анонимус, который тут в серёдке долго пытался запостить что-нибудь оскорбительное, не является одним из ведущих разработчиков из Team."

Вам ли это говорить.

>>Значит, я серьезно недопонял такие фразы, как:

>серьезно недопонял :)

>а вкратце работает так:

>скрипт config задает вопросы через систему debconf

Вообще-то я именно так и понял - что скрипт задает вопросы debconf, а тот уже сам решает, откуда брать ответы - от живого юзера или преконфигурированной базы. И исходя из того, что я знаю об RPM, он тоже мог бы так делать.

> вот АЛЬТы своим патченьем rpm (о котором говорилось выше) могли бы и добавить.

Хорошо бы :)

Если бы ALT делал CentOS + etcnet + wine@etersoft + русские шрифты + лицензии + вылизанный RPM с debconf, эх... мечты :D

"примерная структура вызовов скриптов есть тут: http://wiki.debian.org/DebianRussian/deb-inside";

расскажите лучше про недостатки debconf, нам это интереснее ;) Идеальных систем не бывает.

> расскажите лучше про недостатки debconf, нам это интереснее ;)

ее нет а ALT Linux :D

>Если бы ALT делал CentOS + etcnet + wine@etersoft + русские шрифты + лицензии + вылизанный RPM с debconf, эх... мечты :D

Вы сами понимаете, какой бред вы несете?

> Вы сами понимаете, какой бред вы несете?

Не-а. Что бредового в моих мечтах? :)

"Если бы ALT делал CentOS + etcnet + wine@etersoft + русские шрифты + лицензии + вылизанный RPM с debconf, эх... мечты :D"

ALT делает то, что делает. И это хорошо. Зачем нам ещё одно поделие на базе RH ? По моему ASP вполне достаточно.

>Не-а. Что бредового в моих мечтах? :)

Хм. Заставить заниматься разработчиков одного дистрибутива разработкой другого -- бредовая идея, как мне кажется.

> Зачем нам ещё одно поделие на базе RH ? По моему ASP вполне достаточно.

apt-get, etcnet, русские шрифты, лицензия и - главное! - фотографии русской природы :D

ну и хорошая совместимость с RHEL в виде бонуса :)

мне не нужна совместимость с RHEL, а все остальное есть и здесь

> Заставить заниматься разработчиков одного дистрибутива разработкой другого -- бредовая идея, как мне кажется.

То есть с технической точки зрения идея бредовой не кажется? :)

"ну и хорошая совместимость с RHEL в виде бонуса :)"

Нахрена нужна совместимость с RHEL ? Лучше обеспечить совместимость с Slackware!

> То есть с технической точки зрения идея бредовой не кажется? :)

С технической точки зрения можно скрестить и ежа с ужём, лиш бы бабки платили.. чем сложнее процесс, тем дороже.

Давайте скинемся анонимумсами, дадим бабла RH, пускай обеспечат совместимость с ALT'ом в плане etcnet, apt'а и всех остальных прелестей!

> это когда totem-xine тянет за собой кдеешный arts
Майнтейнерская жопорукость не проблема rpm. Это когда вместо того чтобы сделать несколько пакетов разнородные бинари/либы, тянущие за собой свои зависимости, сливают в один пакет да ещё и всякую гадость в Requires пишут. Fedora как раз такими кривульками и славится. Только какое это имеет отношение к rpm?

Единственный "национальный дистр" из top10 на дистровотче начинался именно как слакварь с улучшенной поддержкой немецкого.

Интересно,а при чём тут слакварь ?

Казалось бы причём тут Slackware, тундра.

700