> 1. Почему вы не делаете всего один дистрибутив, как это в DebianПотому что мы делаем не некоммерческий инструментальный дистрибутив, как Debian, а коммерческую линейку продуктов -- соответственно они должны быть по максимуму готовы к работе минимальными времязатратами (это целеполагание, мы прекрасно понимаем, что до недостижимого идеала тут ещё пахать и пахать).
> но с разными "профилями установки" - минимальный, сервер, рабочая станция, образования
> и т.д., и с возможностью подкорректировать (добавить/удалить) софт, указанный в профиле
> (естественно тот, который можно), а также выбрать выбрать графическую среду (GNOME,
> KDE, Mate, Xfsce) при установке? Если причина - размер установочного диска,
> то, наверое, на установочном диске не обязательно иметь весь софт, что-то
> можно качать из репозитария или зеракал
Как упомянул рядом в #504, технически вполне возможно сделать такой дистрибутив -- причём для тех, кого вполне устраивает установка пакетов по сети, можно изобразить маленький netinst (как вариант, спаренный со спасательным образом).
Это вопрос потребности и готовности участвовать в формировании облика такого дистрибутива тех, кому пригодится именно "общий случай".
Со своей стороны отмечу, что мне такое в целом интересно и могу поучаствовать с целью распространения опыта сборки дистрибутивов на базе альтовой пакетной базы (и заодно реализации своих задумок по теме, где-то даже тудушка такая вроде была) -- при этом собственно выпуск предпочёл бы сразу передать в более вдумчивые руки, как это уже получилось со стартеркитами и регулярками.
> 2. Почему у вас такое экзотическое решение для пакетов - RPM и APT?
См. соответствующий пункт http://altlinux.org/History/FAQ --
---
=== почему apt-rpm? ===
''ответ с исторического конца вопроса, датированный ~2008 годом''
В Mdk использовался urpmi, который хак именно в стиле "французский перл" (как Sympa или DrakX). Бишь после установки системы с его помощью у тебя могли оказаться конфликтующие пакеты, битые зависимости -- всё, что угодно.
apt-rpm делали в Conectiva, к тому времени 0.3.x были уже вполне рабочими (хотя из-за трансляции данных из неродного /var/lib/rpm -- заметно медленней, чем с dpkg).
Я не знаю, кто и как именно принимал это решение -- скорее всего, вся изначальная core team вместе (включая aen@, ldv@, ab@) -- но в Spring 2001 оно уже было включено, хотя ещё толком не работало: репозиторий, ориентированный на urpmi и недалеко ещё отошедший, был попросту ужасен в плане зависимостей (для сравнения -- такой же ужасной федорина пакетная база была пару лет назад, например).
В Junior 1.1 апт уже вполне работал, а к Compact 3.0 на него перешёл и инсталятор.
Как на сейчас видится: на тот момент и у rpm, и у dpkg были различные проблемы [выбора] дизайна. Например, dpkg по определению подразумевает возможность интерактивности при установке (хотя она необязательно используется), а rpm по определению подразумевает невозможность какого-либо ввода (можно сделать интерактивные %pre/%post, но это завесит любой фронтэнд, который такого подвоха не ожидает).
Есть ещё множество подобных различий, но в общем их можно просуммировать так: dpkg -- "инженереный", rpm -- "инженерный".
Например, в dpkg гораздо тоньше продумано состояние пакетов (в т.ч. "частично установлен" -- оставлены конфиги/данные) и зависимости (принципиально есть мягкие), а в rpm этого нет, зато сразу был контроль целостности пакетов по md5/gpg и соответствия содержимого файловой системы записи в базе для данного пакета.
Бишь dpkg был ориентирован изначально на "долго делать, но потом мало морочиться", а rpm -- на "быстро, дёшево, сердито и надёжно".
Как часть этой разницы -- сейчас Edubuntu на AMD64 3000+ с полгигом памяти устанавливается полтора часа (примерно полчаса создавая чрут для отдачи терминалам), а ALTSP5 -- 15--20 минут, при этом создание чрута поленился выделять отдельной стадией, поскольку на этой стендовой -- далеко не самой дорогой -- машинке оно идёт что-то минуту или полторы.
---
> Нет ли планов, в связи с текущей ситуацией санкциями, перейти в последующих версиях
> на более "открытый" формат пакетов *.DEB
Он ни разу не более открытый -- это всего лишь выбор другой точки на шкале "гибкость/поддерживаемость".
Таких планов, насколько мне известно, нет -- как и поводов для них. А какие поводы действительно были (например, из апстрима RPM пару лет назад, что ли, выкинули уже принятый ранее альтовый патч без объяснения причин) -- те не новы.
У нас очень большой опыт по http://altlinux.org/RPM -- как минимум сопоставимый с нынешним редхатовским, а по моему личному мнению, так и далеко его превосходящий.
> и использовать нативный APT а также пакеты из репозитария Debian или Ubuntu
> с небольшой доработкой и тестированием под вашу платформу? Я, думаю, вы
> бы смогли в этом случае сэкономить много сил для более полезных задач.
Таким уже занимается проект AstraLinux -- с забавными "побочками" в виде отправления пользователей в дебиановские репозитории одной рукой и докладами о независимости от западных экосистем -- другой. При этом по крайней мере от формального участия в управлении дебианом (хоть какого-то) их, насколько понимаю, сейчас отстранили. Идти же за "демократическим" проектом, прикладное влияние редхата (читай заклятого врага России в лице IBM) на который уже было продемонстрировано на тот самый #весьмир -- считаю в лучшем случае огромной глупостью.
Ну и не думаю, что альту стоит вляпываться в давно и хорошо нам известные проблемы клонов (которые лично я с Лёней Кантером обсуждал как бы ещё не в нулевых, по сути предсказав судьбу ASPLinux).
Собственно, см. всё тот же [[History/FAQ]] насчёт первого вопроса.
