Bug 42414 - Просьба добавить пакет eepm в дистрибутив Альт Сервер
Summary: Просьба добавить пакет eepm в дистрибутив Альт Сервер
Status: NEW
Alias: None
Product: Альт Сервер
Classification: Distributions
Component: Установка (show other bugs)
Version: 10.0
Hardware: x86_64 Linux
: P5 normal
Assignee: jqt4@altlinux.org
QA Contact: qa-p8@altlinux.org
URL:
Keywords:
Depends on:
Blocks: 44001
  Show dependency tree
 
Reported: 2022-04-12 19:32 MSK by Vitaly Lipatov
Modified: 2022-12-17 12:25 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vitaly Lipatov 2022-04-12 19:32:56 MSK
Прошу добавить в Альт Сервер пакет eepm, как инструмент системного администратора.
Comment 1 Vitaly Lipatov 2022-04-12 19:33:38 MSK
Отсутствие проверялось на alt-server-10.0-x86_64.iso
Comment 2 Anton Farygin 2022-08-31 16:20:07 MSK
eepm это совсем не для серверного дистрибутива пакет. на мой взгляд он там вреден.
Comment 3 Anton Farygin 2022-08-31 16:20:55 MSK
штатный инструмент в альте для работы с пакетной базой - это apt + rpm

Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в дистрибутив eepm ?
Comment 4 Evgeny Sinelnikov 2022-09-13 22:53:35 MSK
В целом, eepm, действительно используется для целого ряда актуальных задач. Особого усложнения жизни никакой не вижу. А вот избыточный функционал, который не зафиксирован, наблюдается. Далее этот избыточный функционал начинает жить своей жизнью, а неявные требования относительно данного функционала рассматриваются, как необходимость.

Какие задачи на сервере предполагается решать с помощью eepm?
Я вижу задачу переупаковки пакетов для создания локального репозитория стороннего софта. Но это доустанавливаемый функционал, который может быть в образе, но не обязательно устанавливаемый по умолчанию.
Comment 5 Anton Farygin 2022-09-14 08:50:16 MSK
эта функция вообще может быть и не в образе, а в репозитории.

Жизнь с eepm усложняется тем, что вместо штатного инструмента используется внештатный.

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

Да и с перепаковкой сторонних пакетов тоже не всё так просто. Какие из перепаковываемых с помощью eepm пакетов нужны на сервере ?
Comment 6 Evgeny Sinelnikov 2022-12-16 03:07:43 MSK
Антон, аргументы понятны и я склонен согласится с тем, что целостность решения требуется исключения дубликатов по умолчанию.

Беда в том, что пользовательские проблемы, которые связаны с потребностями, штатные инструменты не решают или решают не полностью.

Может быть эти потребности и не нужно реализовывать "из коробки". Но "не из коробки" их потом не найдёшь, если не знаешь, что ищешь. "Проще добавить, чем документировать и реализовывать" дополнительные средства установки средств установки.

Виталий, а в чем связь с багой #44001? Что текущая бага той решает?
Comment 7 Vitaly Lipatov 2022-12-16 07:29:14 MSK
(Ответ для Evgeny Sinelnikov на комментарий #6)
...
> Виталий, а в чем связь с багой #44001? Что текущая бага той решает?
Связь в том, что какой смысл реализовывать поддержку обновления дистрибутива до следующей версии, если инструмент принципиально в этом дистрибутиве не поддерживается?

(Ответ для Anton Farygin на комментарий #3)
> штатный инструмент в альте для работы с пакетной базой - это apt + rpm
Это раньше так было.
 
> Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в
> дистрибутив eepm ?
Пользователи серверного дистрибутива это системные администраторы (ну по крайней мере если человек добрался до командной строки). И epm облегчает ему жизнь, потому что он может пользоваться привычным инструментом.



(Ответ для Evgeny Sinelnikov на комментарий #6)
> Антон, аргументы понятны и я склонен согласится с тем, что целостность
> решения требуется исключения дубликатов по умолчанию.
В epm задачи управления пакетами естественно сводятся к вызову rpm и apt, но давно ли иерархическая архитектура рассматривается как дублирование функциональности?
Потом, мне кажется, если и возникает вопрос про целостность решения и исключения дубликатов, то это лишь предлог. Я бы ещё понимал, если бы дело было в объёме. Но мы тут обсуждаем пакет на полмегабайта.

Наверное, можно подождать, пока epm появится у конкурентов в качестве удобного средства миграции с решений ALT. Ну да, можно.
Comment 8 Anton Farygin 2022-12-16 09:04:38 MSK
(Ответ для Evgeny Sinelnikov на комментарий #6)
> Антон, аргументы понятны и я склонен согласится с тем, что целостность
> решения требуется исключения дубликатов по умолчанию.
> 
> Беда в том, что пользовательские проблемы, которые связаны с потребностями,
> штатные инструменты не решают или решают не полностью.
> 
> Может быть эти потребности и не нужно реализовывать "из коробки". Но "не из
> коробки" их потом не найдёшь, если не знаешь, что ищешь. "Проще добавить,
> чем документировать и реализовывать" дополнительные средства установки
> средств установки.

Тогда инструмент должен решать только эти задачи, а не быть универсальной заменой всем другим пакетным менеджерам, да ещё и архитектурно кривой - качающей саму себя не из Sisyphus.
Comment 9 Anton Farygin 2022-12-16 09:07:41 MSK
(Ответ для Vitaly Lipatov на комментарий #7)
> (Ответ для Evgeny Sinelnikov на комментарий #6)
>  
> > Поясните пожалуйста, зачем вы хотите усложнить пользователю жизнь, добавив в
> > дистрибутив eepm ?
> Пользователи серверного дистрибутива это системные администраторы (ну по
> крайней мере если человек добрался до командной строки). И epm облегчает ему
> жизнь, потому что он может пользоваться привычным инструментом.

Привычным инструментом должен быть apt, а не eepm. И в этом у нас с тобой кардинальное расхождение.

А если копать глубже, то например в k10 сейчас по умолчанию обновление выполняется offline во время перезагрузки, и затащить в эту схему нештатную обёртку eepm вообще никак не представляется возможным.

А установка пакетов из внешних источников должна быть по умолчанию заблокирована и запрещена и мы обязательно это когда-то сделаем.
Comment 10 Vitaly Lipatov 2022-12-16 22:59:56 MSK
(Ответ для 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 может и на вершине сейчас, но вымрут.
Comment 11 Anton Farygin 2022-12-17 12:25:17 MSK
Про вымирание монстров и история учит - это всё конечно забавные рассуждения, но практика показывает обратное.

Что касается удобства инструмента - нет ничего более неудобного, чем инструмент, поведение которого не предсказуемо и зависит от того, что происходит в сети.

В этом контексте тот же самый flatpack выглядит намного более продуманным (с точки зрения сохранения целостности системы, установленной из дистрибутива).