Bug 7557

Дистрибутив: 3.0rc5

Так вы хоть скажите, это бага или фича?

ни слова не понял. Что значит "нельзя вернуться назад"?
Можно, если в listbox справа щёлкнуть на нужный пункт.

(In reply to comment #2)
> ни слова не понял. Что значит "нельзя вернуться назад"?
> Можно, если в listbox справа щёлкнуть на нужный пункт.
> 
 
Меню слева.
Если клацнуть на элемент вышестоящий от текущего то переходит. На нижестоящий не
переходит.

нижестоящий конечно нельзя. Это фича.
Нечего заглядывать в будущее раньше времени ;))

(In reply to comment #4)
> нижестоящий конечно нельзя. Это фича.
> Нечего заглядывать в будущее раньше времени ;))

А если я с него назад уходил и хочу вернуться?

Вообще говоря, некоторые шаги зависят друг от друга. Если выбрать один из
предыдущих шагов и что-то там изменить, то не все последующие шаги остаются
валидными. 
В старом мандрейковском установщике каким-то непонятным образом это, кажется,
учитывалось, и некоторые шаги всё же можно было не проходить по второму кругу.
Но в целом и там эта функциональность хромала. Лучше всего это реализовано в
YaST: нет строгой последовательности действий, взаимозависимые настройки
выносятся в отдельные мастера/окна, а в окне Summary всё суммируется (что уже
настроено, что ещё не настроено, а что настроено автоматически). В этом
отношении YaST очень удобен. Во-первых, Summary наглядно показывает текущее
положение; во-вторых, появляется возможность установить систему буквально
четырьмя кликами мышки, если всё оборудование успешно определилось, и
пользователя устраивает набор пакетов по умолчанию.

(In reply to comment #6)
> Вообще говоря, некоторые шаги зависят друг от друга. Если выбрать один из
> предыдущих шагов и что-то там изменить, то не все последующие шаги остаются
> валидными. 

Логично

> В старом мандрейковском установщике каким-то непонятным образом это, кажется,
> учитывалось, и некоторые шаги всё же можно было не проходить по второму кругу.
> Но в целом и там эта функциональность хромала. Лучше всего это реализовано в
> YaST: нет строгой последовательности действий, взаимозависимые настройки
> выносятся в отдельные мастера/окна, а в окне Summary всё суммируется (что уже
> настроено, что ещё не настроено, а что настроено автоматически). В этом
> отношении YaST очень удобен. Во-первых, Summary наглядно показывает текущее
> положение; во-вторых, появляется возможность установить систему буквально
> четырьмя кликами мышки, если всё оборудование успешно определилось, и
> пользователя устраивает набор пакетов по умолчанию.

Тогда осмелюсь задать провоцирующий вопрос. :)
Что такого, решительно, не понравилось в YaST, что начали создавать подобное с нуля?

(In reply to comment #7)
> Что такого, решительно, не понравилось в YaST, что начали создавать подобное
> с нуля?
YaST несовершенен во многих отношениях, в том числе в архитектурном. Внешне всё
выглядит красиво, модулей много, опять же, но нутрянка у него хуже, чем у
Альтератора. Кроме того, YaST практически нереально адаптировать к нашему
дистрибутиву из-за технологической и идеологической разницы (например, у них
rpm, а у нас apt-rpm; конфигурационные файлы отличаются; alternatives
только-только появились; ну и многое другое). В общем, у YaST'а имеет смысл
только заимствовать некоторые идеи; дорожки у нас и SuSE всё же слишком разные.

Даже нечего добавить. Всё сказано чётко и понятно ;)

(In reply to comment #8)
> (In reply to comment #7)
> > Что такого, решительно, не понравилось в YaST, что начали создавать подобное
> > с нуля?
> YaST несовершенен во многих отношениях, в том числе в архитектурном. Внешне всё
> выглядит красиво, модулей много, опять же, но нутрянка у него хуже, чем у

Может она у него была лучше когда он был на такой же стадии как и Альтератор. :)
Практическая реализация имеет свойство накладывать свои коррективы и чаще всёго
не в лучшую сторону.

> Альтератора. Кроме того, YaST практически нереально адаптировать к нашему
> дистрибутиву из-за технологической и идеологической разницы (например, у них
> rpm, а у нас apt-rpm; конфигурационные файлы отличаются; alternatives

Где разница? YaST оперирует зависимостями пакетов и apt ими оперирует. Можно
ставить и без использования apt, может даже быстрее будет. Старый Мандриковый
установщик работал и он про apt ничего незнал. Кроме того я не думаю что
привязка к RPM распылена по всей программе, а это значит что вклинить apt скорее
всего можно.

А модуль для alternatives можно было и написать, что было бы быстрее и полезнее.

> только-только появились; ну и многое другое). В общем, у YaST'а имеет смысл
> только заимствовать некоторые идеи; дорожки у нас и SuSE всё же слишком разные.

Не доказал. :)

Кстате, если вы серьёзно разрабатываете Альтератор то ткните пожалуйста в проект
который предшествовал реализации с модельками, анализом, обоснованием
целесообразности создания и т.д. :)

Извените что расшатываю фундамент, но хотелось бы его проверить.
Да и для вас, как авторов это будет полезно. :)

(In reply to comment #10)
> ставить и без использования apt, может даже быстрее будет. Старый Мандриковый
> установщик работал и он про apt ничего незнал.
Хреново он работал.

> > YaST несовершенен во многих отношениях, в том числе в архитектурном.
> > Внешне всё выглядит красиво, модулей много, опять же, но нутрянка
> > у него хуже, чем у Альтератора.
> 
> Может она у него была лучше когда он был на такой же стадии как и Альтератор. 
Нет. В YaST изначально не было заложено гибкости Альтератора и разрабатывался он
в других условиях (начиная с того, что его исходный код лишь недавно был открыт).

> > Кроме того, YaST практически нереально адаптировать к нашему
> > дистрибутиву из-за технологической и идеологической разницы (например, у них
> > rpm, а у нас apt-rpm; конфигурационные файлы отличаются; alternatives
> 
> Где разница? YaST оперирует зависимостями пакетов и apt ими оперирует.
Настройки rpm в SuSE существенно отличаются от наших. Например, там есть
специальный скрипт SuSEconfig, который запускается после каждой транзакции rpm
(и вообще после любого изменения конфигурации системы) и контролирует
целостность системы. У нас такого скрипта нет и многое из того, что делает
SuSEconfig, делается установочными скриптами.

> Можно ставить и без использования apt, может даже быстрее будет.
> Старый Мандриковый установщик работал и он про apt ничего незнал.
Как уже сказал wrar, работал он так себе. Там использовался urpmi, костыль для
rpm, разрешающий зависимости. До apt этому костылю было очень далеко.

> Кроме того я не думаю что
> привязка к RPM распылена по всей программе, а это значит что вклинить
> apt скорее всего можно.
Боюсь, что для этого пришлось бы переписать соответствующий модуль YaST (и ещё
два модуля сильно поправить). Он фактически дублирует функциональность apt.

> А модуль для alternatives можно было и написать, что было бы быстрее и
> полезнее.
Это как раз ерунда. Гораздо хуже то, что пришлось бы переделывать многие
существующие модули.

> > только-только появились; ну и многое другое). В общем, у YaST'а имеет смысл
> > только заимствовать некоторые идеи; дорожки у нас и SuSE всё же слишком
> разные.
> 
> Не доказал. :)
А теперь? :)

> Кстате, если вы серьёзно разрабатываете Альтератор то ткните пожалуйста в
> проект который предшествовал реализации с модельками, анализом, обоснованием
> целесообразности создания и т.д. :)
Ну вот тут уже лучше inger скажет, пожалуй.

> Извените что расшатываю фундамент, но хотелось бы его проверить.
> Да и для вас, как авторов это будет полезно. :)
Я в число авторов не вхожу, я просто на летней конференции был :), где обо всём
этом рассказывали, и в частности был сравнительный анализ различных
установщиков/настройщиков.

1. Что касается общих измышлений о конфигураторах и alterator'ах, то фактически
эта работа была проведена george@ и voins@ и потом оформлена как статья для IBM
LTC. Там уже выложена первая часть этих статей, когда будут остальные - не известно.
2. Если смотреть на мир, то в нём существует миллион готовых архитектур на
основе которых можно было сделать конфигуратор, та же Mozilla + XPCOM очень не
плохая основа для разработки конфигуратора. YaST,Debconf,MDK - всё это прекрасно
было известно и рассметривалось уже наверное лет эдак 5. Неоднократно были мысли
"А может взять просто что-то готовое и написать своё"  но ...

Всё всегда останавливалось на вопросе "а как это всё потом поддерживать". Вам
возможно покажется, ну взяли, написали модули и вперёд.
Но во-первых, писать надо будет абсолютно все модули, это уже проверено со
времён MDK. Что в MDK, что в SuSE, в модулях фактически гвоздями прибит тот или
иной дистрибутив. Вы не сможете мне назвать не одного модуля Yast который не
надо было бы переписывать. Тут же не лишним будет добавить что Yast
разрабатывался не для community, чтобы писать модули для него надо осваивать
некий язык программирований.

Во-вторых, как показывет практика (на том же MDK), написанием модулей дело не
ограничивается. В след за переписыванием модулей начинается допиливание самой
архитектуры. Ну про debconf я молчу - он просто не создан для rpm, там другая
идеология уже пакетов. Ну а YaST конечно теоретически должен архитектурно
подойти к любому дистрибутиву, однако написан в тяжёлом и просто неподъёмном
стиле. Чтобы там хоть что-то не совсем тривиальное исправить (например в
последнюю минуту перед выходом дистрибутива ) - это просто повеситься . Это мы
уже проходили, достаточно нам уже bootsplash, который вроде как тоже
дистрибутиво-назависим.
А если подумать об инсталляторе? Вы не представляете сколько там
дистрибутивно-зависимых хаков. Делать инсталлятор на основе Yast? Это не просто.

Ну а коли так, то не проще ли написать свой конфигуратор, нежели фактически
полностью переделывать чужой.

alterator изначально имеет более современную архитектуру, Без сомнений он сейчас
ещё находится в стадии детских болезней, но также без сомнений разработка над
ним идёт каждую минуту. Выпуски Compact за два месяца отличаются очень разительно.

Ну это вот вкратце обзор двух основных причин - остальное уже вторично, хотя
можно доводы приводить до бесконечности.

(In reply to comment #13)
> 1. Что касается общих измышлений о конфигураторах и alterator'ах, то фактически
> эта работа была проведена george@ и voins@ и потом оформлена как статья для IBM
> LTC. Там уже выложена первая часть этих статей, когда будут остальные - не
известно.

Что есть LTC?
Хотелось бы взглянуть. :)

> 2. Если смотреть на мир, то в нём существует миллион готовых архитектур на
> основе которых можно было сделать конфигуратор, та же Mozilla + XPCOM очень не
> плохая основа для разработки конфигуратора. YaST,Debconf,MDK - всё это прекрасно
> было известно и рассметривалось уже наверное лет эдак 5. Неоднократно были мысли
> "А может взять просто что-то готовое и написать своё"  но ...
> 
> Всё всегда останавливалось на вопросе "а как это всё потом поддерживать". Вам
> возможно покажется, ну взяли, написали модули и вперёд.

Не покажется. :)
Я пологал что можно выйти на контакт с разработчиками YaST и состыковаться с ними.

> Но во-первых, писать надо будет абсолютно все модули, это уже проверено со
> времён MDK. Что в MDK, что в SuSE, в модулях фактически гвоздями прибит тот или
> иной дистрибутив. Вы не сможете мне назвать не одного модуля Yast который не
> надо было бы переписывать. Тут же не лишним будет добавить что Yast
> разрабатывался не для community, чтобы писать модули для него надо осваивать
> некий язык программирований.

А это существенно! Если у него нет внятного публичного API то для community его
ценность приближается к нулю.
 
> Во-вторых, как показывет практика (на том же MDK), написанием модулей дело не
> ограничивается. В след за переписыванием модулей начинается допиливание самой
> архитектуры. Ну про debconf я молчу - он просто не создан для rpm, там другая
> идеология уже пакетов. Ну а YaST конечно теоретически должен архитектурно
> подойти к любому дистрибутиву, однако написан в тяжёлом и просто неподъёмном
> стиле. Чтобы там хоть что-то не совсем тривиальное исправить (например в
> последнюю минуту перед выходом дистрибутива ) - это просто повеситься . Это мы
> уже проходили, достаточно нам уже bootsplash, который вроде как тоже
> дистрибутиво-назависим.
> А если подумать об инсталляторе? Вы не представляете сколько там
> дистрибутивно-зависимых хаков. Делать инсталлятор на основе Yast? Это не просто.

Опятьже отсутствие внятного публичного API не в его пользу.
 
> Ну а коли так, то не проще ли написать свой конфигуратор, нежели фактически
> полностью переделывать чужой.

Логично! Когда трудоёмкость адаптации YaST превышает трудоёмкость создания
нового с нормальным открытым API то целесообразно подумать о создании нового. :)

> alterator изначально имеет более современную архитектуру, Без сомнений он сейчас
> ещё находится в стадии детских болезней, но также без сомнений разработка над
> ним идёт каждую минуту. Выпуски Compact за два месяца отличаются очень разительно.
> 

Естественно, практическое внедрение и множественое тестирование подстегнули. :)

> Ну это вот вкратце обзор двух основных причин - остальное уже вторично, хотя
> можно доводы приводить до бесконечности.

Уже достаточно.
Одно но, хотелось бы проект увидеть. :)

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

Ну а проект можно смотреть, сейчас, ещё немного разгребусь и сделаю rsync дерева
в people.

Ну а tarball'ы всегда доступны.

(In reply to comment #15)
> внешнее-то API- у YaST есть и оно даже документировано, только не просто это
> использовать.
> YaST всё-таки разрабатывался для корпоративных нужд, где можно засадить кучу
> штатных разработчиков и они срочат код, а мы всё-таки хотели сделать
> конфигуратор для community.
> 
> Ну а проект можно смотреть, сейчас, ещё немного разгребусь и сделаю rsync дерева
> в people. 
> Ну а tarball'ы всегда доступны.

URL, пожалуйста, скажите.