Прошу добавить в Альт Сервер пакет eepm, как инструмент системного администратора.
Отсутствие проверялось на alt-server-10.0-x86_64.iso
eepm это совсем не для серверного дистрибутива пакет. на мой взгляд он там вреден.
штатный инструмент в альте для работы с пакетной базой - это apt + rpm Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в дистрибутив eepm ?
В целом, eepm, действительно используется для целого ряда актуальных задач. Особого усложнения жизни никакой не вижу. А вот избыточный функционал, который не зафиксирован, наблюдается. Далее этот избыточный функционал начинает жить своей жизнью, а неявные требования относительно данного функционала рассматриваются, как необходимость. Какие задачи на сервере предполагается решать с помощью eepm? Я вижу задачу переупаковки пакетов для создания локального репозитория стороннего софта. Но это доустанавливаемый функционал, который может быть в образе, но не обязательно устанавливаемый по умолчанию.
эта функция вообще может быть и не в образе, а в репозитории. Жизнь с eepm усложняется тем, что вместо штатного инструмента используется внештатный. Т.е. - если бы в его задачи входила только перепаковка сторонних пакетов - это одна история, но т.к. он пытается эмулировать из себя пакетный менеджер - это совсем другая задача. Да и с перепаковкой сторонних пакетов тоже не всё так просто. Какие из перепаковываемых с помощью eepm пакетов нужны на сервере ?
Антон, аргументы понятны и я склонен согласится с тем, что целостность решения требуется исключения дубликатов по умолчанию. Беда в том, что пользовательские проблемы, которые связаны с потребностями, штатные инструменты не решают или решают не полностью. Может быть эти потребности и не нужно реализовывать "из коробки". Но "не из коробки" их потом не найдёшь, если не знаешь, что ищешь. "Проще добавить, чем документировать и реализовывать" дополнительные средства установки средств установки. Виталий, а в чем связь с багой #44001? Что текущая бага той решает?
(Ответ для Evgeny Sinelnikov на комментарий #6) ... > Виталий, а в чем связь с багой #44001? Что текущая бага той решает? Связь в том, что какой смысл реализовывать поддержку обновления дистрибутива до следующей версии, если инструмент принципиально в этом дистрибутиве не поддерживается? (Ответ для Anton Farygin на комментарий #3) > штатный инструмент в альте для работы с пакетной базой - это apt + rpm Это раньше так было. > Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в > дистрибутив eepm ? Пользователи серверного дистрибутива это системные администраторы (ну по крайней мере если человек добрался до командной строки). И epm облегчает ему жизнь, потому что он может пользоваться привычным инструментом. (Ответ для Evgeny Sinelnikov на комментарий #6) > Антон, аргументы понятны и я склонен согласится с тем, что целостность > решения требуется исключения дубликатов по умолчанию. В epm задачи управления пакетами естественно сводятся к вызову rpm и apt, но давно ли иерархическая архитектура рассматривается как дублирование функциональности? Потом, мне кажется, если и возникает вопрос про целостность решения и исключения дубликатов, то это лишь предлог. Я бы ещё понимал, если бы дело было в объёме. Но мы тут обсуждаем пакет на полмегабайта. Наверное, можно подождать, пока epm появится у конкурентов в качестве удобного средства миграции с решений ALT. Ну да, можно.
(Ответ для Evgeny Sinelnikov на комментарий #6) > Антон, аргументы понятны и я склонен согласится с тем, что целостность > решения требуется исключения дубликатов по умолчанию. > > Беда в том, что пользовательские проблемы, которые связаны с потребностями, > штатные инструменты не решают или решают не полностью. > > Может быть эти потребности и не нужно реализовывать "из коробки". Но "не из > коробки" их потом не найдёшь, если не знаешь, что ищешь. "Проще добавить, > чем документировать и реализовывать" дополнительные средства установки > средств установки. Тогда инструмент должен решать только эти задачи, а не быть универсальной заменой всем другим пакетным менеджерам, да ещё и архитектурно кривой - качающей саму себя не из Sisyphus.
(Ответ для Vitaly Lipatov на комментарий #7) > (Ответ для Evgeny Sinelnikov на комментарий #6) > > > Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в > > дистрибутив eepm ? > Пользователи серверного дистрибутива это системные администраторы (ну по > крайней мере если человек добрался до командной строки). И epm облегчает ему > жизнь, потому что он может пользоваться привычным инструментом. Привычным инструментом должен быть apt, а не eepm. И в этом у нас с тобой кардинальное расхождение. А если копать глубже, то например в k10 сейчас по умолчанию обновление выполняется offline во время перезагрузки, и затащить в эту схему нештатную обёртку eepm вообще никак не представляется возможным. А установка пакетов из внешних источников должна быть по умолчанию заблокирована и запрещена и мы обязательно это когда-то сделаем.
(Ответ для 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 может и на вершине сейчас, но вымрут.
Про вымирание монстров и история учит - это всё конечно забавные рассуждения, но практика показывает обратное. Что касается удобства инструмента - нет ничего более неудобного, чем инструмент, поведение которого не предсказуемо и зависит от того, что происходит в сети. В этом контексте тот же самый flatpack выглядит намного более продуманным (с точки зрения сохранения целостности системы, установленной из дистрибутива).
Пакет eepm был добавлен в Альт Сервер 10.1
