Т.к. никаких изменений сделано не было, вынесу в bugzilla. Если возникнет ситуация, при которой будет сненсено полсистемы, он даже не чихнёт.
Решение проблемы в проработке. Рассматривается три варианта (возможно, в комплексе): - блокировка перечня значимых пакетов в компонентах; - указание перечня пакетов в pkgpriorities; - реализация интерфейса apt, позволяющего вычислять транзакцию до установки, по аналогии с выводом apt-get в консоли.
Текущий функционал apt в одной из последних статей на wiki: https://www.altlinux.org/Команды_APT
(Ответ для Evgeny Sinelnikov на комментарий #1) > Решение проблемы в проработке. Рассматривается три варианта (возможно, в > комплексе): > - блокировка перечня значимых пакетов в компонентах; > - указание перечня пакетов в pkgpriorities; > - реализация интерфейса apt, позволяющего вычислять транзакцию до установки, > по аналогии с выводом apt-get в консоли. Получается, все варианты -- одно и то же: будет за пользователя решать. А это значит, что будет либо грохать полсистемы, либо тупо ничего не делать(видимо, это). P.S. Это всё костыли(нейросети не хватает) и об изменении архитектуры в правильную сторону речи не идет, как вижу.
(Ответ для Evgeny Sinelnikov на комментарий #1) > - блокировка перечня значимых пакетов в компонентах; Перечень на конкретной системе разный и вы никак не сможете его определить. Особенно с учётом сторонних пакетов. > - указание перечня пакетов в pkgpriorities; Вы тут нипричём, лазить туда вам не надо и уметь работать с имеющимся. > - реализация интерфейса apt, позволяющего вычислять транзакцию до установки, > по аналогии с выводом apt-get в консоли. Если оно предполагает интерактив, то, видимо, оно.
Считаю это блокером для дистрибутивов. Я проверил alterator-application-components -- да, втихушку сносит всё, что попало под руку.
Проблема в "-y" тут https://git.altlinux.org/gears/a/alterator-backend-packages.git?p=alterator-backend-packages.git;a=blob;f=apt/apt.backend
'-y' - это данность для не интерактивного режима. Есть два решения текущей проблемы: - настройками: при установке/удалении компонент включать в настройки apt жёсткое ограничение на перечень пакетов, которые не могут быть удалены. - логикой реализации: нужно брать и переносить логику install/dist-upgrade из утилит в библиотеки, тогда не интерактивный режим можно будет обеспечить системными модулями. Рассчитываю, что сначала мы это реализуем "настройками".
(Ответ для Evgeny Sinelnikov на комментарий #7) > '-y' - это данность для не интерактивного режима. А неинтерактивный режим -- это задница для системы. > Есть два решения текущей проблемы: Больше. Еще вариант -- сделать правильно, но сложнее.
(Ответ для Evgeny Sinelnikov на комментарий #7) > - настройками: при установке/удалении компонент включать в настройки apt > жёсткое ограничение на перечень пакетов, которые не могут быть удалены. Без ведома пользователя не должен удалиться ни один пакет. Т.к. все пакеты в настройки внести нельзя -- неосуществимый вариант.
(Ответ для Evgeny Sinelnikov на комментарий #7) > - логикой реализации: нужно брать и переносить логику install/dist-upgrade > из утилит в библиотеки, тогда не интерактивный режим можно будет обеспечить > системными модулями. Не знаю, как вы интерактивный режим превратите в неинтерактивный без вреда системе. Считаю, что вы не в том направлении думаете и интерактивный режим необходим.
Одно дело интерактивный режим в конечном приложении, а другое - это интерактивный режим на стыке между приложениями из-за того, что наши apt'овые библиотеки заброшены. От первого никто не отказывается. Вопрос в том, как это технически правильно реализовать. Тыркать в приложение apt-get через pipe строками - это кривое и не гибкое решение. Добиться "неинтерактивного" режима без вреда системе можно только при жёстких ограничениях. Добиться этого можно теми же настройками,
как это делается для ключевых системных пакетов: $ cat /etc/apt/pkgpriorities Important: basesystem Required: apt systemd-sysvinit sysvinit openssh-server Standard: postfix $ sudo apt-get -y remove apt Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Следующие пакеты будут УДАЛЕНЫ: alt-panelmoded alteratorctl cinnamon-default gnome-control-center gnome-shell-extension-appindicator gnome-shell-extensions gvfs-backends task-auth-ad-sssd alt-tour apt cinnamon-session gnome-extensions-app gnome-shell-extension-arcmenu gnome-shell-extensions-system-monitor hasher update-kernel alterator-application-components apt-repo diag-domain-client gnome-initial-setup gnome-shell-extension-clipboard-indicator gnome3-minimal imsettings-cinnamon alterator-backend-packages apt-rsync eepm gnome-online-accounts gnome-shell-extension-dash-to-dock gpupdate packagekit alterator-gpupdate apt-scripts gdm gnome-session-classic gnome-shell-extension-dash-to-panel gvfs-backend-goa realmd alterator-update-kernel cinnamon gdm-data gnome-shell gnome-shell-extension-gtk4-desktop-icons-ng gvfs-backend-google simple-scan ВНИМАНИЕ: Будут удалены важные для работы системы пакеты Обычно этого делать не следует. Вы должны точно понимать возможные последствия! apt 0 будет обновлено, 0 новых установлено, 44 пакетов будет удалено и 532 не будет обновлено. Необходимо получить 0B архивов. После распаковки будет освобождено 92,6MB дискового пространства. E: Обнаружены проблемы, а параметр -y был использован без --force-yes $ echo $? 100 PS: выполнено без всякого страха что-то сломать на собственной рабочей системе.
Удаляй то, чего нет в настройках.
(Ответ для Evgeny Sinelnikov на комментарий #12) > как это делается для ключевых системных пакетов: > > $ cat /etc/apt/pkgpriorities Т.е. программа-минимум -- внести в этот список всё, что `apt-mark showmanual` на момент окончания установки системы, правильно?
(Ответ для Sergey V Turchin на комментарий #14) > (Ответ для Evgeny Sinelnikov на комментарий #12) > > как это делается для ключевых системных пакетов: > > > > $ cat /etc/apt/pkgpriorities > Т.е. программа-минимум -- внести в этот список всё, что `apt-mark > showmanual` на момент окончания установки системы, правильно? Это сто процентов через чур. Всего лишь не надо в Компоненты выносить тот сук, на котором сидишь. Базовая часть дистрибутива не должна быть доступна в компонентах. Компоненты - это те группы пакетов, которые можно выбрать при установке. И расширять их до масштабов Вселенной было неправильно во всех смыслах. Проделана огромная работа зря, которую теперь обидно выкидывать.
(In reply to Антон Мидюков from comment #15) > (Ответ для Sergey V Turchin на комментарий #14) > > (Ответ для Evgeny Sinelnikov на комментарий #12) > > > как это делается для ключевых системных пакетов: > > > > > > $ cat /etc/apt/pkgpriorities > > Т.е. программа-минимум -- внести в этот список всё, что `apt-mark > > showmanual` на момент окончания установки системы, правильно? > > Это сто процентов через чур. Всего лишь не надо в Компоненты выносить тот > сук, на котором сидишь. Базовая часть дистрибутива не должна быть доступна в > компонентах. Компоненты - это те группы пакетов, которые можно выбрать при > установке. И расширять их до масштабов Вселенной было неправильно во всех > смыслах. Проделана огромная работа зря, которую теперь обидно выкидывать. apt-get -y будет криво работать как раз с компонентами Всё что нужно - это аналогичное apt/synaptic взаимодействие с пользователем при установке компоненты. Отследить удаление пакетов, спросить нужно ли выполнять транзакцию. И ещё - в десктопных дистрибутивах это вообще неюзабельно, т.к. управление пакетами должно быть построено на packagekit, что бы не сломать ещё больше.
Нет, доступность или недоступность "базовой части дистрибутива... в компонентах" тут ни на что, ровным счётом, не влияет. "программа-минимум" - это один из вариантов.
(Ответ для Evgeny Sinelnikov на комментарий #17) > Нет, доступность или недоступность "базовой части дистрибутива... в > компонентах" тут ни на что, ровным счётом, не влияет. Влияет. Зачем давать возможность удалять компоненты, которые ломают систему?
packagekit - плюс-минус то же самое, только со неюзабельным интерфейсом. Пока apt-get доступен в консоли, packagekit - это ещё один вариант. Я изучу его код и наши правки в нем по-внимательней.
(Ответ для Anton Farygin на комментарий #16) > Отследить удаление пакетов, спросить нужно ли выполнять транзакцию. Например, Discover это умеет через библиотеку от PackageKit.
(Ответ для Anton Farygin на комментарий #16) > apt-get -y будет криво работать как раз с компонентами > Всё что нужно - это аналогичное apt/synaptic взаимодействие с пользователем > при установке компоненты. Если компонентов было бы немного и они не затрагивали базовую систему, то этого бага бы не появилось, так как этой проблемы бы не было. Вы думаете, что большинство пользователей остановит сообщение об удалении сотни пакетов?
(Ответ для Антон Мидюков на комментарий #18) > (Ответ для Evgeny Sinelnikov на комментарий #17) > > Нет, доступность или недоступность "базовой части дистрибутива... в > > компонентах" тут ни на что, ровным счётом, не влияет. > > Влияет. Зачем давать возможность удалять компоненты, которые ломают систему? С таким же успехом можно много чего не давать (rm -rf, apt-get-remove). Вопрос в том, какими методами и средствами осуществлять защиту от дурака. Позиция о том, что только пользователь, работающий в консоли, должен иметь возможность отстрелить себе ногу приводит к тому, что этому пользователю в графике годами оказываются недоступны никакие реально необходимые возможности. Издержки и риски нужно снимать тут же нет спора. Но... этот вопрос - не предмет этой задачи.
(Ответ для Антон Мидюков на комментарий #21) > (Ответ для Anton Farygin на комментарий #16) > > apt-get -y будет криво работать как раз с компонентами > > Всё что нужно - это аналогичное apt/synaptic взаимодействие с пользователем > > при установке компоненты. > > Если компонентов было бы немного и они не затрагивали базовую систему, то > этого бага бы не появилось, так как этой проблемы бы не было. > Вы думаете, что большинство пользователей остановит сообщение об удалении > сотни пакетов? (Ответ для Sergey V Turchin на комментарий #20) > (Ответ для Anton Farygin на комментарий #16) > > Отследить удаление пакетов, спросить нужно ли выполнять транзакцию. > Например, Discover это умеет через библиотеку от PackageKit. Я отвечу только один раз. Это уже неконструктивно. Что там может Discover через PackageKit я изучу. Проблему останавливать поезд, не давая что-то сделать пользователю, не вижу. Но даже это, всего лишь требование, его можно удовлетворить - главное не пытаться подменить требование и возможность местами.
(Ответ для Evgeny Sinelnikov на комментарий #23) > Это уже неконструктивно. Что именно? Пример, как не кинуть пользователя на сотню пакетов? > Проблему останавливать поезд, не давая что-то сделать пользователю, не вижу. Это уже на грани вредительства.
(Ответ для Evgeny Sinelnikov на комментарий #22) > (Ответ для Антон Мидюков на комментарий #18) > > (Ответ для Evgeny Sinelnikov на комментарий #17) > > > Нет, доступность или недоступность "базовой части дистрибутива... в > > > компонентах" тут ни на что, ровным счётом, не влияет. > > > > Влияет. Зачем давать возможность удалять компоненты, которые ломают систему? > > С таким же успехом можно много чего не давать (rm -rf, apt-get-remove). Я всего лишь хотел обратить внимание, что компоненты изначально преследовали задачу заменить те группы пакетов в инсталляторе, чтобы их можно было использовать после установки. Зачем было лезть в базовую систему, да ещё и позволять удалять пакеты, которые нужны для работы самих компонент? Нельзя было вовремя остановиться. > Вопрос в том, какими методами и средствами осуществлять защиту от дурака. Можно сначала создать проблему, а потом городить защиту от дурака, а можно её не создавать... > > Позиция о том, что только пользователь, работающий в консоли, должен иметь > возможность отстрелить себе ногу приводит к тому, что этому пользователю в > графике годами оказываются недоступны никакие реально необходимые > возможности. Издержки и риски нужно снимать тут же нет спора. Такой графический инструмент всегда был, называется synaptic. Я полагал, что компоненты должны быть достаточно крупными кусками системы, скрывающими от пользователя сложность устройства ОС (её пакетный состав). В которых легко ориентироваться и нельзя запутаться. В прочем, никто же не заставляет использовать текущую мегабазу. Можно сделать поменьше, чем и занимается cas@. И для него этой проблемы просто нет. Предлагаю последовать этому примеру. > > Но... этот вопрос - не предмет этой задачи. Почему не предмет? Не надо бороться со следствиями, нужно устранять причину.
(Ответ для Sergey V Turchin на комментарий #24) > (Ответ для Evgeny Sinelnikov на комментарий #23) > > Это уже неконструктивно. > Что именно? Пример, как не кинуть пользователя на сотню пакетов? В каком, конкретно, кейсе? Какое действие ты хочешь выполнить, при котором такая ситуация возникает? Конструктивно - это так: Вариант 1 (базовые компоненты). Проблема: Ты лезешь в базовые компоненты и удаляешь, например, ядро или что-то важное. Вариант решения: сделать базовые компоненты не удаляемыми, плюс добавить их в "настройки". Коллизия: обычный dist-upgrade может легко всё это обломать. Вариант 2 (не базовые компоненты): Проблема: попытка удаления любого пакета тянет за собой удаление любых других пакетов и это крайне сложно предугадать. Решение: добавить в настройки базовые компоненты. Тогда даже apt не сможет их снести. Коллизия: нужно проверять сайд-эффекты. > > Проблему останавливать поезд, не давая что-то сделать пользователю, не вижу. > Это уже на грани вредительства. rm -rf / - это то же тогда на грани вредительства. apt-get remove apt только настройками сдерживается. Я уже не говорю что бывает в реальности на зависимостях. Удаление непонятного пакетика не из базовых легко уносит пол KDE или GNOME. packagekit от этого не спасает.
(Ответ для Evgeny Sinelnikov на комментарий #26) > В каком, конкретно, кейсе? Какое действие ты хочешь выполнить, при котором > такая ситуация возникает? Этот вопрос неконструктивен. Очевидно же, что это абсолютно любая ситуация, при которой удаляются пакеты. Чем больше удаляется, тем хуже. > Конструктивно - это так: IMHO конструктивно -- это не прикидываться непонимающим масштаб проблемы.
(Ответ для Evgeny Sinelnikov на комментарий #26) > > > Проблему останавливать поезд, не давая что-то сделать пользователю, не вижу. > > Это уже на грани вредительства. > rm -rf / - это то же тогда на грани вредительства. Само собой. Только не видел, чтобы кто-то подобное делал преподнося как фичу. > apt-get remove apt только настройками сдерживается. Неправда. Попробуйте удалить apt в Discover.
(Ответ для Антон Мидюков на комментарий #25) > (Ответ для Evgeny Sinelnikov на комментарий #22) > > (Ответ для Антон Мидюков на комментарий #18) > > > (Ответ для Evgeny Sinelnikov на комментарий #17) > > > > Нет, доступность или недоступность "базовой части дистрибутива... в > > > > компонентах" тут ни на что, ровным счётом, не влияет. > > > > > > Влияет. Зачем давать возможность удалять компоненты, которые ломают систему? > > > > С таким же успехом можно много чего не давать (rm -rf, apt-get-remove). > > Я всего лишь хотел обратить внимание, что компоненты изначально преследовали > задачу заменить те группы пакетов в инсталляторе, чтобы их можно было > использовать после установки. Зачем было лезть в базовую систему, да ещё и > позволять удалять пакеты, которые нужны для работы самих компонент? Нельзя > было вовремя остановиться. Предложение сделать базовые пакеты не удаляемыми, по умолчанию, принимается. При этом стоит учесть, понятие "базовости" весьма условное - каждом продукте свой базовый набор. С учётом же того, что любой наш репозиторий - это роллинг, по факту, она (эта базовость) ещё и уплывает потихоньку. > > Вопрос в том, какими методами и средствами осуществлять защиту от дурака. > > Можно сначала создать проблему, а потом городить защиту от дурака, а можно > её не создавать... Проблема явно, вообще, не обозначена. Каждый во что горазд в своем контексте обсуждает. > > > > Позиция о том, что только пользователь, работающий в консоли, должен иметь > > возможность отстрелить себе ногу приводит к тому, что этому пользователю в > > графике годами оказываются недоступны никакие реально необходимые > > возможности. Издержки и риски нужно снимать тут же нет спора. > > Такой графический инструмент всегда был, называется synaptic. > Я полагал, что компоненты должны быть достаточно крупными кусками системы, > скрывающими от пользователя сложность устройства ОС (её пакетный состав). В > которых легко ориентироваться и нельзя запутаться. > В прочем, никто же не заставляет использовать текущую мегабазу. Можно > сделать поменьше, чем и занимается cas@. И для него этой проблемы просто > нет. Предлагаю последовать этому примеру. synaptic умер. Мы его сами убираем. Снова какой проблемы? Того, что базовые компоненты можно легко удалить. Принимается. Хотя... Кто-то разве пожаловался, что когда он удаляет что-то из базовой системы, у него всё не работает? Нет, никому такое в голову не придёт. А не дать пользователю отстрелить себе ногу у нас не предусмотрено. Или rm -rf / уже удален? а, это другое - понимать нужно. Сделать предупреждение при удалении базовых компонент - уже предложено. > > > > > Но... этот вопрос - не предмет этой задачи. > > Почему не предмет? Не надо бороться со следствиями, нужно устранять причину. Причину чего? Кейсы не обозначены. Про базовый набор я уже написал. Меня волнует более существенная тема - широкий набор коллизий в силу сильно связной архитектуры пакетной базы. Задача принята. Проблемы толком не обозначены, мнения высказаны. Предмет данной задачи: "Снесёт полсистемы не чихнув", обозначен невнятно, понимай, как хочешь. Как хотел, понял. Будет решение, будет продолжение.
(Ответ для Sergey V Turchin на комментарий #28) > (Ответ для Evgeny Sinelnikov на комментарий #26) > > apt-get remove apt только настройками сдерживается. > Неправда. Попробуйте удалить apt в Discover. Думаю apt тут не причём. $ pkcon remove apt Сопоставление [=========================] Проверка изменений [=========================] Завершено [=========================] Неисправимая ошибка: WARNING: You are trying to remove the following essential packages: apt
(Ответ для Evgeny Sinelnikov на комментарий #26) > Вариант решения: сделать базовые компоненты не удаляемыми, плюс добавить их > в "настройки". > Решение: добавить в настройки базовые компоненты. Тогда даже apt не сможет > их снести. Разве до сих пор не понятно, что эти два варианта одного и того же ничего не решают? Просто не будет ничего происходить при попытке хоть что-то поменять в составе пакетов.
(Ответ для Sergey V Turchin на комментарий #31) > (Ответ для Evgeny Sinelnikov на комментарий #26) > > Вариант решения: сделать базовые компоненты не удаляемыми, плюс добавить их > > в "настройки". > > Решение: добавить в настройки базовые компоненты. Тогда даже apt не сможет > > их снести. > Разве до сих пор не понятно, что эти два варианта одного и того же ничего не > решают? > Просто не будет ничего происходить при попытке хоть что-то поменять в > составе пакетов. Почему не решают? Какую задачу, вообще, предлагается решить? "Снесёт полсистемы не чихнув" "Если возникнет ситуация, при которой будет сненсено полсистемы, он даже не чихнёт." 1) Этим страдает apt в консоли, но чихнув. 2) Что-то наделали в packagekit - предлагается перейти на него. 3) Базовых компонент много, можно промахнуться. Что кому, при такой формулировке задачи кажется нужным? Нужно сделать, чтоб чихал? Замечательно. Сделаем. Нужно чтобы базовые компоненты просто так не удалялись. Есть варианты. Нужно не рассматривать базовую систему, не как базовую, потому что-то кто-то в консоли захочет руками что-то удалить? Ну, для этого нужно определить что такое минимальная система, сделать такую редакцию. Нужно, чтобы при удалении пакетов, процесс был контролируемым? Понятно. Нужно посмотреть packagekit с его нечеловеческими интерфейсами. Хорошо, посмотрим, что там лучше, чем в apt-get. _________________________ У всех свои разные цели, которые мы обсуждаем под одной шапкой. Ничего не упустил?
Вы зря крутитесь вокруг базовой системы. Снос, например, работающей конфигурации WEB сервера гораздо опаснее. И не забывайте, пожалуйста, что apt-get install -y на необновлённой системе тоже весьма и весьма опасен.
Не гораздо опаснее, конечно, а не менее опасен.
(Ответ для Anton Farygin на комментарий #33) > Вы зря крутитесь вокруг базовой системы. > Снос, например, работающей конфигурации WEB сервера гораздо опаснее. > > И не забывайте, пожалуйста, что apt-get install -y на необновлённой системе > тоже весьма и весьма опасен. Но ровно это же можно сделать и через Discover. Неужели нет? Суть интеграции с packagekit состоит, видимо, в добавлении в задачу на обновление установку пакетов выбранных компонент. После чего производится перезагрузка, обновление и установка компонент и перезагрузка. Только вот тот же Discover так не делает при установке приложений?
(Ответ для Anton Farygin на комментарий #34) > Не гораздо опаснее, конечно, а не менее опасен. Принято, меня именно этот вопрос и волновал, прежде всего. В принципе, для обработки информации пока достаточно.
(Ответ для Антон Мидюков на комментарий #35) > (Ответ для Anton Farygin на комментарий #33) > > Вы зря крутитесь вокруг базовой системы. > > Снос, например, работающей конфигурации WEB сервера гораздо опаснее. > > > > И не забывайте, пожалуйста, что apt-get install -y на необновлённой системе > > тоже весьма и весьма опасен. > > Но ровно это же можно сделать и через Discover. Неужели нет? > Суть интеграции с packagekit состоит, видимо, в добавлении в задачу на > обновление установку пакетов выбранных компонент. После чего производится > перезагрузка, обновление и установка компонент и перезагрузка. > Только вот тот же Discover так не делает при установке приложений? Если принять за аксиомы что: 1. Компоненты не являются инструментом для каждодневного использования. Они нужны при первоначальном конфигурировании ОС и в редких случаях в дальнейшем, когда требуется перепрофилирование ОС под новые задачи. 2. Компоненты являются надстройкой над базовой системой. У каждого дистрибутива они свои. Набор компонентов свой. Набор определяется целесообразностью конфигурирования каждого дистрибутива. Их не должно быть много. Не более трёх-четырёх десятков, чтобы их можно было тестировать и контролировать работоспособность. 3. Компоненты не являются заменой пакетного менеджера или менеджеров приложений (Discover и GNOME Software). Его задача позволять быстро добавлять нужную функциональность в дистрибутив или наоборот убирать. То можно поставить задачи: 1. Сделать свой набор компонент под каждый дистрибутив 2. Обеспечить их тестирование 3. Реализовать механизм, запрещающий использование компонент на не обновлённой системе. Интеграция с packagekit для этого не требуется.
(Ответ для Антон Мидюков на комментарий #37) > 1. Компоненты не являются инструментом для каждодневного использования. Они > нужны при первоначальном конфигурировании ОС и в редких случаях в Нет. Для этого их надо вернуть обратно в установщик. Если мы переносим это в систему, то оно должно быть готово для повседневного использования. > дальнейшем, когда требуется перепрофилирование ОС под новые задачи. Запрещать перепрофилировать не чаще чем раз в год? ;-)
(Ответ для Sergey V Turchin на комментарий #38) > оно должно быть готово для повседневного использования. Другими словами, если есть 365 человек, которые по очереди раз в год перепрофилируют систему, то ни у кого не должно ничего сломаться.
(Ответ для Sergey V Turchin на комментарий #38) > (Ответ для Антон Мидюков на комментарий #37) > > 1. Компоненты не являются инструментом для каждодневного использования. Они > > нужны при первоначальном конфигурировании ОС и в редких случаях в > Нет. Для этого их надо вернуть обратно в установщик. Если мы переносим это в > систему, то оно должно быть готово для повседневного использования. > Не всё, что в системе используется каждый день. Оно и готово для такого использования. Но никто каждый день использовать не будет. > > дальнейшем, когда требуется перепрофилирование ОС под новые задачи. > Запрещать перепрофилировать не чаще чем раз в год? ;-) Не нужно никаких запретов. Просто никто не будет это использовать каждый день, так как нет смысла это делать.
(Ответ для Sergey V Turchin на комментарий #39) > 365 человек у каждого своя система. Ещё можно умножить на кол-во компонент, чтоб каждая компонента проверялась на вшивость каждый день.
(Ответ для Антон Мидюков на комментарий #40) > Не всё, что в системе используется каждый день. Оно и готово для такого > использования. До 1-го взрыва, само собой. > > Запрещать перепрофилировать не чаще чем раз в год? ;-) > Не нужно никаких запретов. Я смайл поставил. > Просто никто не будет это использовать каждый > день, так как нет смысла это делать. Я переформулирую. Каждый будет это НЕ использовать каждый день после первой же пропажи в никуда хотя бы одного настроенного, работающего и находящегося в использовании пакета.
(Ответ для Sergey V Turchin на комментарий #39) > (Ответ для Sergey V Turchin на комментарий #38) > > оно должно быть готово для повседневного использования. > Другими словами, если есть 365 человек, которые по очереди раз в год > перепрофилируют систему, то ни у кого не должно ничего сломаться. Само собой разумеется. И для этого нужно: 1 Тестирование компонент (поэтому их априори не может быть несколько сотен для каждого дистрибутива). Компоненты это не всегда только про установку пакетов, это ещё и некий деплой может быть. 2 Запрет на использование на не обновлённой системе.
(Ответ для Антон Мидюков на комментарий #43) > 1 Тестирование компонент (поэтому их априори не может быть несколько сотен > для каждого дистрибутива). Тестирование каждой компоненты при тестировании каждого сборочного задания, только этого будет недостаточно, т.к. проблемы будут на конечных системах, а по нашим тестам всё хорошо. > 2 Запрет на использование на не обновлённой системе. Согласен.
(Ответ для Sergey V Turchin на комментарий #44) > (Ответ для Антон Мидюков на комментарий #43) > > 2 Запрет на использование на не обновлённой системе. > Согласен. Нет, так не пойдёт. Оно просто не формализуемо полноценно. И оно ни от чего не спасает. Что значит, что "система обновлена"? Что dist-upgrade ничего не предлагает? А если он полсистемы предлагает снести, то мы ему больше доверяем что ли? Это можно предлагать, но запрет - это очень странная идея. Она просто не предусмотрена. Чтобы её предусмотреть нужно иметь соответствующий критерий. Кстати, PackageKit тоже себя вести должен? В общем, предлагать обновление имеет смысл. Запускать его перед установкой каждый - выглядит немыслимо.
(Ответ для Evgeny Sinelnikov на комментарий #45) > (Ответ для Sergey V Turchin на комментарий #44) > > (Ответ для Антон Мидюков на комментарий #43) > > > 2 Запрет на использование на не обновлённой системе. > > Согласен. > > Нет, так не пойдёт. Да, этого мало. Нужен еще запрет на использование пакетного менеджера вообще. Только компоненты и обновлятор системы.
(Ответ для Evgeny Sinelnikov на комментарий #45) > А если он полсистемы предлагает снести, то мы ему больше доверяем что ли? Отказываемся и обращаемся к специалисту по решению проблемы.
А разработка своих компонент недопустима? Если допустима, то конфликты между компонентами как обрабатываются?
(Ответ для Evgeny Sinelnikov на комментарий #45) > (Ответ для Sergey V Turchin на комментарий #44) > > (Ответ для Антон Мидюков на комментарий #43) > > > 2 Запрет на использование на не обновлённой системе. > > Согласен. > > Нет, так не пойдёт. Оно просто не формализуемо полноценно. И оно ни от чего > не спасает. > > Что значит, что "система обновлена"? > Что dist-upgrade ничего не предлагает? > А если он полсистемы предлагает снести, то мы ему больше доверяем что ли? > > Это можно предлагать, но запрет - это очень странная идея. Она просто не > предусмотрена. > Чтобы её предусмотреть нужно иметь соответствующий критерий. > > Кстати, PackageKit тоже себя вести должен? В общем, предлагать обновление > имеет смысл. Запускать его перед установкой каждый - выглядит немыслимо. Не нужно ничего запускать. Нужно определять, что система не в актуальном состоянии, и выдавать предупреждение, что для установки и удаления компонент необходимо привести систему в актуальное состояние, возможность установки и удаления блокировать. Пользователь должен сам привести систему в актуальное состояние.
(Ответ для Антон Мидюков на комментарий #49) > Не нужно ничего запускать. Нужно определять, что система не в актуальном > состоянии, и выдавать предупреждение, что для установки и удаления компонент > необходимо привести систему в актуальное состояние, возможность установки и > удаления блокировать. Пользователь должен сам привести систему в актуальное > состояние. Ну, вот. Нужен критерий. Каким образом выяснить, "что система не в актуальном состоянии"?
(Ответ для Evgeny Sinelnikov на комментарий #50) > Каким образом выяснить, "что система не в актуальном состоянии"? Есть обновления и они не установлены.
(Ответ для Sergey V Turchin на комментарий #51) > (Ответ для Evgeny Sinelnikov на комментарий #50) > > Каким образом выяснить, "что система не в актуальном состоянии"? > Есть обновления и они не установлены. Ну, это интересно. Как это можно вычислить? Выполнить dist-upgrade в режиме dry-run. Есть какие-то другие методы? Выполнять это перед каждым действием - весьма сомнительное дело. Запоминать - кешировать? Если уметь вычислять действие до выполнения, то в рамках данной задачи достаточно просто определять при установке, что никакие пакеты не будут удалены. А при удалении? Когда по зависимостям оно приползёт. Как это сейчас определяется? Да никак, на глазок. Не думаю, что packagekit тут что-то даёт особенное. Посмотрим. Да, при установке бывают случаи "эксклюдов", когда одно удаляется, а другое - устанавливается. Кейсов много их все нужно рассматривать. Регулярный dist-upgrade проблему не решает. Но держать систему в актуальном состоянии смысл, конечно, имеет. Это надо прорабатывать в деталях. Когда будет проработано - напишу. Пока прорабатывается нужны промежуточные шаги, решающие проблему. И это никак не dist-upgrade.
Ещё добавить механизм, реализующий конфликты между компонентами. Вообще, что бюы говорить предметно - надо попробовать добавить новые компоненты и посмотреть как это работает. Где лежит репозиторий всех компонент, есть ли он такой (по аналогии с apt) ? Могут ли произвольные ментейнеры делать свои компоненты и как ?
(In reply to Evgeny Sinelnikov from comment #52) > Да, при установке бывают случаи "эксклюдов", когда одно удаляется, а другое > - устанавливается. По другому это называется конфликты. Одно заменяется другим. В сложных системах часто бывают случаи, когда два компонента друг с другом в одной машине не уживаются по каким-то причинам. Но наверное замена одного на другой должна быть не без вопросов (-y использовать нельзя, и именно об этом ошибка)
(Ответ для Anton Farygin на комментарий #54) > (In reply to Evgeny Sinelnikov from comment #52) > В сложных системах часто бывают случаи, когда два компонента друг с другом в > одной машине не уживаются по каким-то причинам. > Но наверное замена одного на другой должна быть не без вопросов (-y > использовать нельзя, и именно об этом ошибка) Ну, это всё производные вопросы. Нужно разбираться. Сейчас я открою исходники packagekit, выясню, что делает '-y' и выяснится, что оказывается всё можно, оно так и работает.
(Ответ для Evgeny Sinelnikov на комментарий #52) > > Есть обновления и они не установлены. > Ну, это интересно. Как это можно вычислить? > Выполнить dist-upgrade в режиме dry-run. Есть какие-то другие методы? На выбор: библиотеки packagekit или библиотеки apt. > Выполнять это перед каждым действием - весьма сомнительное дело. > Запоминать - кешировать? Да. > Если уметь вычислять действие до выполнения, то в рамках данной задачи > достаточно просто определять при установке, что никакие пакеты не будут > удалены. Да. Научитесь, плиз. > Да, при установке бывают случаи "эксклюдов", когда одно удаляется, а другое > - устанавливается. Может, "обсолетов", когда одно замещает другое? Это в исходниках apt-get точно есть. Для packagekit примеры искать в нём и в discover c gnome-software.
(Ответ для Evgeny Sinelnikov на комментарий #55) > Сейчас я открою исходники packagekit, выясню, что делает '-y' и выяснится, > что оказывается всё можно, оно так и работает. Выяснится, что без разговоров посылают на хрен в случае, где без '-y' задают вопрос.
(Ответ для Anton Farygin на комментарий #53) > Ещё добавить механизм, реализующий конфликты между компонентами. > > Вообще, что бюы говорить предметно - надо попробовать добавить новые > компоненты и посмотреть как это работает. > > Где лежит репозиторий всех компонент, есть ли он такой (по аналогии с apt) ? > > Могут ли произвольные ментейнеры делать свои компоненты и как ? https://www.altlinux.org/Alt-components "Базовый набор компонентов содержится в пакета alt-components-base": https://altlinux.space/alterator/alt-components-base
(In reply to Evgeny Sinelnikov from comment #58) > (Ответ для Anton Farygin на комментарий #53) > > Ещё добавить механизм, реализующий конфликты между компонентами. > > > > Вообще, что бюы говорить предметно - надо попробовать добавить новые > > компоненты и посмотреть как это работает. > > > > Где лежит репозиторий всех компонент, есть ли он такой (по аналогии с apt) ? > > > > Могут ли произвольные ментейнеры делать свои компоненты и как ? > > https://www.altlinux.org/Alt-components > "Базовый набор компонентов содержится в пакета alt-components-base": > https://altlinux.space/alterator/alt-components-base Т.е. - только включением в "базовый набор компонент" ? По ссылке вся работа с компонентами описана в графике, но на серверах графики нет (а если есть, то это критическая ошибка администратора и с ним надо поговорить). Можно добавить описание работы с компонентами в консоли в эту же ссылку ?
(Ответ для Anton Farygin на комментарий #59) > > Можно добавить описание работы с компонентами в консоли в эту же ссылку ? Добавила перекрёстные ссылки на страницы: https://www.altlinux.org/Alt-components https://www.altlinux.org/Alteratorctl
Ну и до кучи: всё, что нащёлкал пользователь в компонентах, должно обрабатываться в одну транзакцию установки/удаления, иначе даже никакой интерактив не поможет. Для проверки этого можно сделать компоненты mysql и mariadb и переключать одну на другую. Т.е. одну включить, другую выключить, применить, а потом наоборот.
(Ответ для Sergey V Turchin на комментарий #3) > либо тупо ничего не делать(видимо, это). Да. Сходу попробовал -- в Образовании он не осилил удалить компоненту Яндекс браузер при наличии установленного chromium.
alt-components-0.4.0-alt1 -> sisyphus: * Tue Jul 01 2025 Maria Alexeeva <alxvmr@altlinux> 0.4.0-alt1 - Implement integrity preservation (Closes: #52837) By default, the ban on deleting packages installed manually is enabled. If the edition is installed on the system, you can optionally prohibit the removal of packages related to the basic components. Even if the ban on manually deleting installed packages is lifted, manually deleted packages will be highlighted in the transaction application window - Add display progressbar during transaction (thx Andrey Alekseev). - Rename package: alterator-application-components to alt-components. * Tue Jun 17 2025 Kirill Sharov <sheriffkorov@altlinux> 0.3.1-alt1 - Fix incomplete package list in transaction. - Add preprocessing of transactions with error indication. - Add package and component count display after applying. - Add hiding of empty views of packages and components. - Merge views in one page separated by tabs after applying. - Change brush of selection for categories to green/red diag pattern. - Fix margin between views. - Add clear button to search line. - Disable package list in component content. - Add hide/display content panel (thx Maria Alexeeva). * Thu Jun 05 2025 Michael Chernigin <chernigin@altlinux> 0.3.0-alt1 - Add support for tags in components and editions. - New view mode menu in view menu. - Add icons to buttons in main window. - Show components which will be installed and uninstalled. - Keep sections and tags expanded after "Collapse all". * Fri May 23 2025 Michael Chernigin <chernigin@altlinux> 0.2.10-alt1 - Update tree item background color based on check state. - Add edition component count to status bar. - Add component count to section item display name. - Prepend description with a title. - Show categories and sections components count in the description. - Display description for categories. - Show categories content on the right. * Tue May 13 2025 Michael Chernigin <chernigin@altlinux> 0.2.9-alt1 - Show content of selected categories and sections instead of empty description. - Display apply diff in columns. * Tue May 06 2025 Michael Chernigin <chernigin@altlinux> 0.2.8-alt2 - Change URL to altlinux.space. * Mon May 05 2025 Michael Chernigin <chernigin@altlinux> 0.2.8-alt1 - Merge two dialogs shown during the apply process into one. - Go back to remove and install in separate apt transactions. This fixes some conflicts then trying to install and remove components at the same time. - Add ctrl+f shortcut to focus search box. - Fix duplicate error messages on apply. * Sun Apr 20 2025 Michael Chernigin <chernigin@altlinux> 0.2.7-alt1 - Remove and install packages in a single apt transaciton. - Show apt logs from backend on apply. - Don't allow to close wait dialog mid apply.
А почему в пакете, на котором висит этот баг, удаление любых пакетов происходит точно так же без каких-либо препятствий, как и раньше? Почему реализация защиты от удаления всего подряд происходит где-то уровнем выше? Это означает, что alterator-backend-packages не подходит для какого-либо использования где-то, кроме как в alt-components. Правильно?
(In reply to Sergey V Turchin from comment #64) > А почему в пакете, на котором висит этот баг, удаление любых пакетов > происходит точно так же без каких-либо препятствий, как и раньше? Вы имеете в виду, что конкретно? Какой конкретно кейс? С помощью какого фронта вы его получаете? Этот бекенд разрпботан, прежде всего, для alt-components и alteratorctl. Возможно, есть варианты использования через alt-packages. Этот вариант нужно проверить отдельно. > Почему > реализация защиты от удаления всего подряд происходит где-то уровнем выше? Это не так. Часть небезопасных методов еще осталось на беке, но фронты должны быть переведены на новые. > Это означает, что alterator-backend-packages не подходит для какого-либо > использования где-то, кроме как в alt-components. Правильно? Нет, неправильно. backend не дает возможности явно удалять пакеты, которые установлены apt'ом и помечены manual, если это явно не указано. Сверху проверяются дополнительно только базовые пакеты, указанные в редакции. Это опция. Обе проверки опциональные и должны быть включены, по умолчанию. Проверьте, включены ли они у вас при обновлении. Давайте разбирать конкретные кейсы. Возможно, что-то упустили. Обновление пока доехало только до сизифа.
(Ответ для Evgeny Sinelnikov на комментарий #65) > Вы имеете в виду, что конкретно? `apt-get remove -y` безопасным удалением быть не может. Только если где-то кто-то взял на себя обязанности apt. Почему эта функциональность не в бекенде управления пакетами? Почему каждый, кто хочет использовать alterator-backend-packages, должен реализовывать эту функциональность у себя?
(Ответ для Evgeny Sinelnikov на комментарий #65) > backend не дает возможности явно удалять пакеты, которые > установлены apt'ом и помечены manual Это баг. > , если это явно не указано. Т.е. я должен подготовить каждое удаление каждого пакета на каждой системе, прежде, чем это делать? Это баг. > Сверху проверяются дополнительно только базовые пакеты, указанные в редакции. Еще и городить редакции для _каждой_ конечной системы(они различаются назначением), установленной из одного и того же дистрибутива?!
(Ответ для Evgeny Sinelnikov на комментарий #65) > Этот бекенд разрпботан, прежде всего, для alt-components и alteratorctl. Не "прежде", а "только". С этого и надо начинать.
(Ответ для Evgeny Sinelnikov на комментарий #65) > > Это означает, что alterator-backend-packages не подходит для какого-либо > > использования где-то, кроме как в alt-components. Правильно? > Нет, неправильно. Вы говорите неправду. alteratorctl угробит систему даже не чихнув.
В общем, я понял. Реализовано при помощи кучи костылей и подпорок, которые каждый должен реализовать сам для каждой конкретной системы.
(In reply to Sergey V Turchin from comment #66) > (Ответ для Evgeny Sinelnikov на комментарий #65) > > Вы имеете в виду, что конкретно? > `apt-get remove -y` безопасным удалением быть не может. > Только если где-то кто-то взял на себя обязанности apt. Апту предварительно формируется список промаркированных пакетов, эти пакеты явно удалить не получится. За это отвечает бекенд. Для исключения бекенду явно передается список пакетов, которые могут быть убраны при явном запросе. Для этого в бекенде предусмотрены новые функции. Старые пока оставлены, но будут удалены или переработаны. > > Почему эта функциональность не в бекенде управления пакетами? Из актуальных методов нужно смотреть только на CheckApply и ApplyAsync. > Почему каждый, кто хочет использовать alterator-backend-packages, должен > реализовывать эту функциональность у себя? Какую? Логика базового набора пакетов редакции относится не к пакетам, а к компонентам. Сейчас модуль apt ничего не знает про компоненты и ничего вычислить не может.
(Ответ для Sergey V Turchin на комментарий #67) > (Ответ для Evgeny Sinelnikov на комментарий #65) > > backend не дает возможности явно удалять пакеты, которые > > установлены apt'ом и помечены manual > Это баг. > > > , если это явно не указано. > Т.е. я должен подготовить каждое удаление каждого пакета на каждой системе, > прежде, чем это делать? Это баг. > > > Сверху проверяются дополнительно только базовые пакеты, указанные в редакции. > Еще и городить редакции для _каждой_ конечной системы(они различаются > назначением), установленной из одного и того же дистрибутива?! Честно. Я не понимаю как вы что поняли, что вы не поняли и какие странные выводы получили. Просто не могу понять о чем идет речь. Скорее всего вы смотрите на старые методы. А доработка alteratorctl еще не завершена. Давайте сначала доведем доработки до таски в p11, документируем логику, укажем это явно или удалим устаревшие функциональные возможности, а потом зафиксируем критические замечания. На текущмй момент не все детали, видимо, завершены и отлажены. Неправильно было закрывать эту задачу.
(Ответ для Evgeny Sinelnikov на комментарий #72) > А доработка alteratorctl Доказываете, что логику каждый должен городить свою в своём пользователе бэкенда. > еще не завершена. Доработка alterator-backend-packages ещё не завершена. Он должен решать, можно ли удалить или нет, а не делать тупо `apt-get remove -y`.
Например, поинтересуйтесь у автора apt-shell, как организовать интерактивное взаимодейситве с ним, если совсем не хочется использовать packagekit.
(Ответ для Sergey V Turchin на комментарий #73) > (Ответ для Evgeny Sinelnikov на комментарий #72) > > А доработка alteratorctl > Доказываете, что логику каждый должен городить свою в своём пользователе > бэкенда. > > > еще не завершена. > Доработка alterator-backend-packages ещё не завершена. Он должен решать, > можно ли удалить или нет, а не делать тупо `apt-get remove -y`. Методы, на которые вы указываете, объявлены устаревшими. Pkgpriorities в них не используется. В новых методах используется. Там, где используется -y, pkgpriorities не даст выполнить удаление тех пакетов, которые установлены явно и явно же не указаны к удалению. Удалены неявно могут только те пакеты, которые могут быть удалены через autoremove. Бек не может работать в интерактивном режиме. В режиме apt-shell, все-равно работает фронт. Вы вменяете то, чего нет. Точнее, ссылаетесь на то, чем фронт более не пользуется. Я уже предложил дождаться чистки интерфейса, чтобы устарешие методы не смущали.
(Ответ для Evgeny Sinelnikov на комментарий #75) > дождаться чистки интерфейса, чтобы устарешие методы не смущали. Да, хорошо бы.
(Ответ для Evgeny Sinelnikov на комментарий #75) > Там, где используется -y, > pkgpriorities не даст выполнить удаление тех пакетов, которые установлены > явно и явно же не указаны к удалению. Удалены неявно могут только те пакеты, > которые могут быть удалены через autoremove. Значит, в большинстве случаев оно будет просто делать "ничего", как я предположил в comment#3 . > Бек не может работать в интерактивном режиме. Соболезную ему... P.S. Я уже предлагал. Сделайте для проверки 2 компоненты "Akonadi MySQL" и "Akonadi MariaDB" и попробуйте на рабочей станции К. Пакеты: akonadi-database-mysql для 1-й и akonadi-database-mariadb для 2-й.
