42414 2022-04-12 19:32:56 +0300 Просьба добавить пакет eepm в дистрибутив Альт Сервер 2023-04-21 12:07:26 +0300 1 1 3 Distributions Альт Сервер Установка 10.0 x86_64 Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=39067 P5 normal --- 44001 1 lav jqt4 cas jqt4 jqt4 ldv rider sin qa-p8 oldest_to_newest 209427 0 lav 2022-04-12 19:32:56 +0300 Прошу добавить в Альт Сервер пакет eepm, как инструмент системного администратора. 209428 1 lav 2022-04-12 19:33:38 +0300 Отсутствие проверялось на alt-server-10.0-x86_64.iso 214313 2 rider 2022-08-31 16:20:07 +0300 eepm это совсем не для серверного дистрибутива пакет. на мой взгляд он там вреден. 214314 3 rider 2022-08-31 16:20:55 +0300 штатный инструмент в альте для работы с пакетной базой - это apt + rpm Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в дистрибутив eepm ? 214861 4 sin 2022-09-13 22:53:35 +0300 В целом, eepm, действительно используется для целого ряда актуальных задач. Особого усложнения жизни никакой не вижу. А вот избыточный функционал, который не зафиксирован, наблюдается. Далее этот избыточный функционал начинает жить своей жизнью, а неявные требования относительно данного функционала рассматриваются, как необходимость. Какие задачи на сервере предполагается решать с помощью eepm? Я вижу задачу переупаковки пакетов для создания локального репозитория стороннего софта. Но это доустанавливаемый функционал, который может быть в образе, но не обязательно устанавливаемый по умолчанию. 214868 5 rider 2022-09-14 08:50:16 +0300 эта функция вообще может быть и не в образе, а в репозитории. Жизнь с eepm усложняется тем, что вместо штатного инструмента используется внештатный. Т.е. - если бы в его задачи входила только перепаковка сторонних пакетов - это одна история, но т.к. он пытается эмулировать из себя пакетный менеджер - это совсем другая задача. Да и с перепаковкой сторонних пакетов тоже не всё так просто. Какие из перепаковываемых с помощью eepm пакетов нужны на сервере ? 219020 6 sin 2022-12-16 03:07:43 +0300 Антон, аргументы понятны и я склонен согласится с тем, что целостность решения требуется исключения дубликатов по умолчанию. Беда в том, что пользовательские проблемы, которые связаны с потребностями, штатные инструменты не решают или решают не полностью. Может быть эти потребности и не нужно реализовывать "из коробки". Но "не из коробки" их потом не найдёшь, если не знаешь, что ищешь. "Проще добавить, чем документировать и реализовывать" дополнительные средства установки средств установки. Виталий, а в чем связь с багой #44001? Что текущая бага той решает? 219021 7 lav 2022-12-16 07:29:14 +0300 (Ответ для Evgeny Sinelnikov на комментарий #6) ... > Виталий, а в чем связь с багой #44001? Что текущая бага той решает? Связь в том, что какой смысл реализовывать поддержку обновления дистрибутива до следующей версии, если инструмент принципиально в этом дистрибутиве не поддерживается? (Ответ для Anton Farygin на комментарий #3) > штатный инструмент в альте для работы с пакетной базой - это apt + rpm Это раньше так было. > Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в > дистрибутив eepm ? Пользователи серверного дистрибутива это системные администраторы (ну по крайней мере если человек добрался до командной строки). И epm облегчает ему жизнь, потому что он может пользоваться привычным инструментом. (Ответ для Evgeny Sinelnikov на комментарий #6) > Антон, аргументы понятны и я склонен согласится с тем, что целостность > решения требуется исключения дубликатов по умолчанию. В epm задачи управления пакетами естественно сводятся к вызову rpm и apt, но давно ли иерархическая архитектура рассматривается как дублирование функциональности? Потом, мне кажется, если и возникает вопрос про целостность решения и исключения дубликатов, то это лишь предлог. Я бы ещё понимал, если бы дело было в объёме. Но мы тут обсуждаем пакет на полмегабайта. Наверное, можно подождать, пока epm появится у конкурентов в качестве удобного средства миграции с решений ALT. Ну да, можно. 219029 8 rider 2022-12-16 09:04:38 +0300 (Ответ для Evgeny Sinelnikov на комментарий #6) > Антон, аргументы понятны и я склонен согласится с тем, что целостность > решения требуется исключения дубликатов по умолчанию. > > Беда в том, что пользовательские проблемы, которые связаны с потребностями, > штатные инструменты не решают или решают не полностью. > > Может быть эти потребности и не нужно реализовывать "из коробки". Но "не из > коробки" их потом не найдёшь, если не знаешь, что ищешь. "Проще добавить, > чем документировать и реализовывать" дополнительные средства установки > средств установки. Тогда инструмент должен решать только эти задачи, а не быть универсальной заменой всем другим пакетным менеджерам, да ещё и архитектурно кривой - качающей саму себя не из Sisyphus. 219030 9 rider 2022-12-16 09:07:41 +0300 (Ответ для Vitaly Lipatov на комментарий #7) > (Ответ для Evgeny Sinelnikov на комментарий #6) > > > Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в > > дистрибутив eepm ? > Пользователи серверного дистрибутива это системные администраторы (ну по > крайней мере если человек добрался до командной строки). И epm облегчает ему > жизнь, потому что он может пользоваться привычным инструментом. Привычным инструментом должен быть apt, а не eepm. И в этом у нас с тобой кардинальное расхождение. А если копать глубже, то например в k10 сейчас по умолчанию обновление выполняется offline во время перезагрузки, и затащить в эту схему нештатную обёртку eepm вообще никак не представляется возможным. А установка пакетов из внешних источников должна быть по умолчанию заблокирована и запрещена и мы обязательно это когда-то сделаем. 219121 10 lav 2022-12-16 22:59:56 +0300 (Ответ для Anton Farygin на комментарий #9) > (Ответ для Vitaly Lipatov на комментарий #7) > > (Ответ для Evgeny Sinelnikov на комментарий #6) > > > > > Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в > > > дистрибутив eepm ? > > Пользователи серверного дистрибутива это системные администраторы (ну по > > крайней мере если человек добрался до командной строки). И epm облегчает ему > > жизнь, потому что он может пользоваться привычным инструментом. > > Привычным инструментом должен быть apt, а не eepm. И в этом у нас с тобой > кардинальное расхождение. Это нужно рассказывать привыкшим к yum и dnf :) apt это всего лишь средство разрешения зависимостей при установке пакетов. С трудом решает одну частную задачу. А epm это повышение уровня абстракции. А расхождение у нас в том, кто решает какой инструмент должен быть привычным. Чтобы хоть как-то навязывать это пользователю, нужно предлагать удобный инструмент. А не приходить со словом «должен». > А если копать глубже, то например в k10 сейчас по умолчанию обновление > выполняется offline во время перезагрузки, и затащить в эту схему нештатную > обёртку eepm вообще никак не представляется возможным. Ну почему не представляется? Просто задачи такой не было. Мне вот представляется, что как раз с помощью epm и надо выполнять такое обновление. Не понимаю, почему нужно добавлять разные эпитеты типа нештатная, обёртка, костыли. Можно ещё «поделка от тупого автора». Но это всё никак не влияет на идею и решение. А epm появился в том числе и в силу ограниченности apt, который как прибит гвоздями к rpm когда-то, так и носит в этой реализации кучу проблем двадцатилетней давности. > А установка пакетов из внешних источников должна быть по умолчанию > заблокирована и запрещена и мы обязательно это когда-то сделаем. Как соавтор доклада на тему запрета выполнения скриптов в сторонних пакетах поддерживаю. Более того, именно к этому и продвигаюсь в epm, подготавливая почву к запрету установки неверифицированных пакетов. Но если обратным внешним источникам представляется репозиторий — то хочу напомнить, что история учит тому, что идея централизованного репозитория давно устарела и через какое-то время будет заменена на децентрализованные доверенные источники. Монстры типа Apple Store и Play Market может и на вершине сейчас, но вымрут. 219129 11 rider 2022-12-17 12:25:17 +0300 Про вымирание монстров и история учит - это всё конечно забавные рассуждения, но практика показывает обратное. Что касается удобства инструмента - нет ничего более неудобного, чем инструмент, поведение которого не предсказуемо и зависит от того, что происходит в сети. В этом контексте тот же самый flatpack выглядит намного более продуманным (с точки зрения сохранения целостности системы, установленной из дистрибутива). 224790 12 jqt4 2023-04-21 12:07:26 +0300 Пакет eepm был добавлен в Альт Сервер 10.1