LINUX.ORG.RU

Etersoft выпускает EPM 1.0 — единое средство управления пакетами

 ,


0

1

Компания Etersoft объявляет о выпуске EPM 1.0 — единого средства управления пакетами. EPM предоставляет универсальный синтаксис для операций над пакетами в различных Linux-дистрибутивах. Интерфейс EPM напоминает rpm, apt и urpm и является одинаковым для всех систем.

До сих пор для управления пакетами приходилось использовать свой набор команд в каждом дистрибутиве. EPM позволяет решить проблему различия пакетных менеджеров и выполнять необходимые операции на любой платформе с помощью единого набора команд. Это позволит существенно упростить процедуру управления пакетами для тех, кто работает с множеством дистрибутивов: системных администраторов, разработчиков, тестировщиков.

Проект был анонсирован этим летом на Девятой конференции разработчиков свободных программ в Обнинске. С того момента функциональность EPM была полностью реализована для множества Linux-дистрибутивов: ALT Linux, Ubuntu, Debian, Mandriva, Fedora, openSUSE, Arch Linux, Slackware и других, совместимых с ними.

Проект EPM является полностью свободным и открытым. Узнать, как воспользоваться единым средством управления пакетами и получить исходники вы можете здесь.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: JB (всего исправлений: 3)
Ответ на: комментарий от queen3

Это позволит существенно упростить процедуру управления пакетами для тех, кто работает с множеством дистрибутивов: системных администраторов, разработчиков, тестировщиков.

serg10etomarkov
() автор топика
Ответ на: комментарий от serg10etomarkov

«Это позволит существенно упростить процедуру управления пакетами для тех, кто работает с множеством дистрибутивов: системных администраторов, разработчиков, тестировщиков.»

Администратор должен уметь работать с множеством дистрибутивов, чтобы решать множество проблем, а не только установкой пакетов заниматься. Разработикам пакетный менеджер вообще никак не поможет - сама программа все равно должна учитывать все особенности всех дистров, а сборка пакета - совсем не главная в создании программы часть. К тестировщикам ВООБЩЕ никак установка не относится - они тестируют функционал.

anonymous
()
Ответ на: комментарий от anonymous

Это и помогает ему не знать множество команд, и использовать однотипные. Я вообще, откровенно говоря, не понимаю, унификация пустой звук что ли и каждый должен знать все костыли всех велосипедов ?

serg10etomarkov
() автор топика
Ответ на: комментарий от serg10etomarkov

«унификация пустой звук что ли и каждый должен знать все костыли всех велосипедов ? »

Зачем, достаточно знать костыли своего велосипеда. Админам - да, надо знать все костыли. Почему бы тогда не помочь им и не сделать унифицированный линукс, в котором есть все особенности всех линуксов?

anonymous
()
Ответ на: комментарий от serg10etomarkov

Пакеты далеко не самая главная часть системы. А унификацию линуксов можно сделать только одним способом - убить все дистрибутивы, кроме избранного.

anonymous
()
Ответ на: комментарий от anonymous

Пока есть марк и шляпа сие под сомнением. Но боливар может и не вынести двоих :-)

serg10etomarkov
() автор топика
Ответ на: комментарий от anonymous

> Пакеты далеко не самая главная часть системы. А унификацию линуксов можно сделать только одним способом - убить все дистрибутивы, кроме избранного.

Например какого? Дополнено: http://www.opennet.ru/openforum/vsluhforumID3/86888.html#100

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

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

anonymous
()
Ответ на: комментарий от anonymous

Ну почему же невозможно? Если ты хочешь, чтобы было как с виндой, один бинарник актуален 10 лет, то ты просто не понимаешь способа распространения ПО в Linux. Linux начинался полностью открытым: хочешь выпустить новую версию дистрибутива - берёшь новые версии программ и собираешь их. В итоге в /usr/lib libpng переименуется с 1.2 на 1.5, libopenal с 0 на 1, libgst с 0.10 в 1.0, а libcurl с 3 на 4. Зависимости всех программ, даже не обновлявшихся 5 лет, изменятся. И это нормально, это защита от DLL Hell и нисколько не препятствует распространению программ: у них открытый код, они умеют пересобираться. А для закрытого ПО есть стандарт LSB, когда программа компилируется не с помощью make --prefix, а специальным образом, зато потом запускается тупо везде.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от serg10etomarkov

Ну так и стараются сделать это, хотя бы в части управления пакетами

Городя сверху еще один велосипед? Зачетная идея, надо запатентовать.

По сабжу: я не админ, но по любому не нужно. Унификация - нужна, единый менеджер пакетов нужен, стандартизация самих пакетов нужна, возможно даже стандартизация версий библиотек нужна, хотя идея весьма сомнительная и нереализуемая. Но сабж точно не нужен.

another ★★★★★
()
Ответ на: комментарий от serg10etomarkov

man унификация Впрочем если нет мана то подойдет и БСЭ :-)

Читать научись, что тебе пишут, мануальщик ты наш.

another ★★★★★
()
Ответ на: комментарий от another

В том, что ты просто не знаешь что такое унификация. Это не одинаково сделанные пакетные менеджеры в данном случае, а возможность с ними работать одинаковыми командами. Примерно как от какого узла не требует чтобы он полностью совпадал с аналогичным, но чтобы он имел те же устройства сопряжения. На пальцах - гайку можно хоть из ниобия сделать с алмазными инкрустациями, но завинчиваться она должна стандартным гайковертом

serg10etomarkov
() автор топика
Ответ на: комментарий от serg10etomarkov

Про гайки: где я утверждал обратное? Или отрицал то, что написано?

Это не одинаково сделанные пакетные менеджеры в данном случае

То есть единый пакетный менеджер это не унификация? Ты мало того, что не читаешь, что пишут тебе, так еще и не удосуживаешься прочесть свой собственный бред^Wтекст?

Прочитай еще раз про то, что такое унификация, что такое линукс, и что такое пакетный менеджер. Времени до следующего бана тебе должно хватить на это.

Надеюсь хоть следующая реинкарнация твоя будет более вменяемой.

another ★★★★★
()
Ответ на: комментарий от serg10etomarkov

«а возможность с ними работать одинаковыми командами»

Написать простенький скрипт-обертку было бы гораздо проще, чем городить очередного монстра.

anonymous
()
Ответ на: комментарий от serg10etomarkov

Ты сферического коня в вакууме обсуждаешь или унификацию на примере сабжа ? :-)

Унификация на примере сабжа - отстой, который не нужен. Об этом я в первом посте и написал. Единый пакетный менеджер - нужен, ибо это правильная унификация. Будешь отрицать?

another ★★★★★
()
Ответ на: комментарий от serg10etomarkov

ЗЫ Представь что по твоей «унификации» на всех компах стоит одна унифицированная видеокарта ? Намек понял ? :-)

Вообще было бы неплохо. Хоть дрова к ней вылизали бы до блеска.

another ★★★★★
()
Ответ на: комментарий от serg10etomarkov

«Унификация позволяет повысить серийность операций и выпуска изделий и, как следствие, удешевить производство, сократить время на его подготовку. С другой стороны, унификация ведет к увеличению габаритов, массы, снижению КПД и т. п. вследствие не всегда оптимальных значений используемых параметров и изделий.»

anonymous
()
Ответ на: комментарий от another

Унификация в данном случае :-) теперь уже видеокарты, это унификация сигналов Точно также как унификация команд в EPM

serg10etomarkov
() автор топика
Ответ на: комментарий от anonymous

И что, отменим всю промышленность и будем выпускать только суперэксклюзив ? Сколько будет стоить твой комп, и самое главное, что ты с таким экслюзивом будешь делать ? :-)

serg10etomarkov
() автор топика
Ответ на: комментарий от another

Я не спорю, но как нельзя выпустить только одну видеокарту, так нельзя в сообществе тянитолкаев сделать единый пакетный менеджер. Отсюда только один выход - унификация сигналов (команд)

serg10etomarkov
() автор топика
Ответ на: комментарий от serg10etomarkov

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

anonymous
()
Ответ на: комментарий от anonymous

Отсюда один выход - унифицировать шину, а не заставлять процессор работать со шиной каждой карты подряд
Тперь представь одмина в роли проца, а различные пакетные менеджеры в виде разных карт, ну и epm в виде унифицированных шин, создатели которых явно не были глупее аналитиков с лора :-)

serg10etomarkov
() автор топика
Ответ на: комментарий от serg10etomarkov

«а различные пакетные менеджеры в виде разных карт»

Где ты видел разные пакетные менеджеры в одной конторе? Никто не будет разводить зоопарк дистрибутивов. К тому же, чтобы твоя волшебная картина сработала, нужно как минимум условие, чтобы везде стояли только современные версии дистров с этим EPM. То есть ты предлагаешь снести работающие дистры и поставить новые. Тогда тем более проще везде поставить один дистрибутив с одним пакетным менеджером.

anonymous
()
Ответ на: комментарий от anonymous

Я предлагаю не ставить один дистр (ты представляешь себе что такое привести зоопарк к единому виду, не говоря уже о том, что это зачастую это просто невозможно) а ставить всего лишь одну обертку, что можно сделать без всяких усилий и трахания на любом компе с любым дистром. Что проще - заменить весь зоопарк или поставить на весь зоопарк одну прогу ?

serg10etomarkov
() автор топика
Ответ на: комментарий от anonymous

Где ты видел разные пакетные менеджеры в одной конторе? Никто не будет разводить зоопарк дистрибутивов

Ну, я как-то развел. Не от хорошей жизни: со старым «железом» (особенно одна видяха постаралась) дружить соглашались не все дистрибутивы, а поскольку миграция на линукс началась не с самых проблемных машин... Итог: на двух компах до сих пор пока крутится мандрива 2008, на двух - суся и на одной - кубунта. И сколько раз я машинально набирал не те команды для установки или обновления пакетов... :(

PVOzerski ★★★
()
Ответ на: комментарий от PVOzerski

«Не от хорошей жизни: со старым „железом“

„Итог: на двух компах до сих пор пока крутится мандрива 2008, на двух - суся и на одной - кубунта“

Ну и как тебя спасет эта софтина? Ее все равно делают под новые дистрибутивы, тебе все так же придется сносить то, что стоит, и ставить другой дистр линукса.

anonymous
()
Ответ на: комментарий от serg10etomarkov

«или поставить на весь зоопарк одну прогу »

И как ты это сделаешь? Hell библиотек тебе все равно не даст поставить ее на достаточно старый дистр

anonymous
()
Ответ на: комментарий от ZenitharChampion

Можно подробнее, как именно собирать закрытое ПО так, чтобы запускалось везде? Причём хотелось бы без статической сборки по крайней мере для API - т.е. glibc - слинкована динамически, opengl - динамически или через dlopen, то же самое для mysqld, аудио и вообще любой либы, дающей доступ к возможностям системы. Boost и oglplus не добавляют новых возможностей и лишь облегчают использование API, их согласен и статически.

Ещё есть lsb-tools и какая-то эталонная реализация libc, в которой есть только функции, входящие в стандарт lsb. Как это развернуть и использовать для сборки, могут ли всплыть неожиданные проблемы с qmake/cmake, с компиляторами вроде clang?

Что использовать для написания утилитных скриптов по стандарту LSB?

И наконец, как сделать себе такую среду сборки наверняка (чтобы потом могли пользоваться, скажем, студенты, не видевшие линукса до сих пор), и не потратить на изучение и исследование разных деталей полгода-год?

quiet_readonly ★★★★
()
Ответ на: комментарий от serg10etomarkov

Упростить не значит избавить от проблем. Leaking abstraction.

queen3 ★★★★★
()
Ответ на: комментарий от anonymous

Ну и как тебя спасет эта софтина?

А еще не смотрел. По мне бы куда лучше, если бы кто-нибудь научил zypper или хотя бы apt работать с «чужими» служебными файлами репозиториев. Тогда бы можно было юзать привычный менеджер в нескольких разных дистрах. А то де-факто даже совместимость yum с zypper в последних федорах сломана.

PVOzerski ★★★
()
Ответ на: комментарий от quiet_readonly

Ты сам вполне ответил на свой вопрос. Также компилировать нужно не с теми библиотеками, версии которых актуальны на момент выпуска дистрибутива, а с теми, которые прописаны в стандарте LSB. http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene... http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-gene... Минимум зависимостей (как ты сказал), GCC 4.1 (обратная совместимость позволит запускать этот бинарник в GCC 4.2-4.7, но не наоборот) либо libgcc и libstdc++ в каталог с программой (если размер не критичен, но критичны новые функции процессора или C++-11).

Как сделать такую систему сборки. Не знаю. Подозреваю что скачав CentOS 5 и компилируя всё в нём, но проверить ещё не успел. Я компилирую в Debian 5. Проблемы с cmake решаю скачиванием бинарников cmake с сайта программы (они как раз такие, которые запускаются тупо везде). То, что не прописано в LSB (например libphysfs для Neverball) кладу в архив с готовыми бинарниками.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Да, кстати, прямо в эти секунды я канпелирую cmake (я же не знал что ты про него спросишь), потому что новая программа попросила новый cmake. Канпеляция пакета раз за разом не удавалась (No left space on device), и только когда я освободил 1,4 Гб компиляция прошла успешно. Проще было скачать бинарники для i386, чем канпелировать RPM.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от serg10etomarkov

Дома у меня тоже мало места осталось. Не могу обновить OpenOffice до LibreOffice в Gentoo, сколько бы места ни освободил. 8 Гб ему не хватает. Хорошо что именно для этого пакета есть вариант использовать бинарник с libreoffice.org.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

«Также компилировать нужно…»

Вот-вот, ключевое слово «нужно». Зачем разработчикам что-то делать для очередного неподдерживаемого велосипеда?

anonymous
()
Ответ на: комментарий от ZenitharChampion

я вообще их не собираю, хотя и слака, ни фокс, ни офисы ни, тем более, всякие хромы

serg10etomarkov
() автор топика
Ответ на: комментарий от anonymous

> «канпелирую cmake »

> Что-что ты с ним делаешь?!

Это отсылка к «Пришло время переустанавливать шиндовс», а именно «тупые линуксоиды, одержимые канпеляцией ведра».

> «Также компилировать нужно…»

> Вот-вот, ключевое слово «нужно». Зачем разработчикам что-то делать для очередного неподдерживаемого велосипеда?

Чтобы получать свою прибыль, конечно же. Никогда не задумывался, почему продукты Adobe (Flash, AIR и Reader), Ahead (Nero), Autodesk (Maya), Oracle (Java, VirtualBox), Humble Bundle, Loki Software, Linux Game Publishing, Desura (игры), CodeWeavers (CrossOver), Cedega, NVIDIA, ATi/AMD (Драйверы, медиабиблиотеки, тулкиты CUDA/OpenCL) запускаются одинаково хорошо как в последних популярных дистрибутивах Linux, так и в малопопулярных и старых?

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Ты точно cmake собирал, а не что то другое ?
До
df -BM /
Файловая система 1M-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/root 18423M 7608M 10629M 42% /

После
df -BM /
Файловая система 1M-блоков Использовано Доступно Использовано% Cмонтировано в
/dev/root 18423M 7793M 10444M 43% /

serg10etomarkov
() автор топика
Ответ на: комментарий от serg10etomarkov

Когда сборка пакета RPM завершается успешно, отработанный исходный код удаляется. Может и у тебя удалился? У меня раз за рабом была ошибка «компиляция прервана, закончилось свободное место», когда я попытался скомпилировать с 500 Мб свободного места, потом с 700, потом с 900. Когда освободил 1,4 Гб, сборка удалась. Конечно же после сборки было свободно тоже 1,4 Гб, но во время вылезало системное уведомление «Заканчивается свободное место».

ZenitharChampion ★★★★★
()
Ответ на: комментарий от ZenitharChampion

все на месте
ну не может пакет сорцов в 4 метра отжирать полтора гига, особенно если учесть что больше половины в нем доки

serg10etomarkov
() автор топика
Ответ на: комментарий от ZenitharChampion

«Чтобы получать свою прибыль, конечно же. »

Какую прибыль можно получить с красноглазых студентов? А с Энтерпрайзом все проще, промышленных линуксов раз-два и обчелся, тем более нет смысла делать пакеты под все дистрибутивы.

anonymous
()
Ответ на: комментарий от quiet_readonly

Можно подробнее, как именно собирать закрытое ПО так, чтобы запускалось везде?

Если интересует то, как это делается в Etersoft, то стоит посмотреть на Korinf. Это подход «собираем под каждую систему, но автоматически».

vitlav
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.