Компания Etersoft hобъявлила (ttp://etersoft.ru/about/news/418-epm) о выпуске EPM 1.0 (http://wiki.etersoft.ru/Epm), универсального средства управления пакетами, которое предоставляет единый синтаксис для операций над пакетами в различных Linux-дистрибутивах. Интерфейс EPM напоминает rpm, apt и urpm. С момента первого анонса проекта на Девятой конференции разработчиков свободных программ в Обнинске функциональность EPM была обеспечена для таких дистрибутивов, как ALT Linux, Ubuntu, Debian, Mandriva, Fedora, openSUSE, ArchLinux и Slackware. Все связанные с EPM наработки открыты (http://git.etersoft.ru/projects/?p=korinf/eepm.git;a=summary) под лицензией GPLv2.
Одной из проблем, возникающих из-за многообразия дистрибутивов Linux, является необходимость использования в каждом классе дистрибутивов собственного набора команд для управления пакетами. EPM является надстройкой над существующими пакетными менеджерами и позволяет выполнять необходимые операции на любой платформе с помощью единого набора команд. Это позволит существенно упростить процедуру управления пакетами для тех, кто работает с множеством дистрибутивов: системных администраторов, разработчиков, тестировщиков.В отличие от таких проектов, как smart и PackageKit, в EPM реализовано несколько альтернативных команд для выполнения операций с пакетами, что позволяет упростить использование EPM людьми уже привыкшими к синтаксису apt, rpm и yum:
<center>
<table style="border: 1px solid rgb(176, 177, 144); border-collapse: collapse; background: none repeat scroll 0% 0% rgb(221, 225, 194);" cellpadding="2" cellspacing="0" width="90%" border="1"><tbody><tr>
<th> Описание операции
</th><th> Команда epm
</th><th> Альтернативная команда epm
</th><th> Команда Debian
</th><th> Команда ALT Linux
</th></tr>
<tr>
<td> Установка пакета по названию в систему
</td><td> epm -i (package)
</td><td> epm install (package) или epmi (package)
</td><td> apt-get install (package)
</td><td> apt-get install (package)
</td></tr>
<tr>
<td> Установка файла пакета в систему
</td><td> epm -i (package file)
</td><td> epm install (package file) или epmi (package file)
</td><td> dpkg -i (package file); apt-get -f install (package file)
</td><td> apt-get install (package file)
</td></tr>
<tr>
<td> Удаление пакета из системы
</td><td> epm -e (package)
</td><td> epm remove (package) или epme (package)
</td><td> apt-get remove (package) ; dpkg -P (package)
</td><td> apt-get remove (package)
</td></tr>
<tr>
<td> Поиск пакета в репозитории
</td><td> epm -s (text)
</td><td> epm search (text) или epms (text)
</td><td> apt-cache search (text)
</td><td> apt-cache search (text)
</td></tr>
<tr>
<td> Проверка наличия пакета в системе
</td><td> epm -q (package)
</td><td> epm installed (package)
</td><td> dpkg -l (package) (pipe) grep 'ii (package)
</td><td> rpm -qa (pipe) grep (package)
</td></tr>
<tr>
<td> Список установленных пакетов
</td><td> epm -qa
</td><td> epm packages или epm list или epmqa
</td><td> dpkg -l
</td><td> rpm -qa
</td></tr>
<tr>
<td> Принадлежность файла к (установленному) пакету
</td><td> epm -qf (file)
</td><td> epmqf (file)
</td><td> dpkg -S (file)
</td><td> rpm -qf (file) или rpmqf из etersoft-build-utils
</td></tr>
<tr>
<td> Список файлов в (установленном) пакете
</td><td> epm -ql (package)
</td><td>
</td><td> dpkg -L (package)
</td><td> rpm -ql (package)
</td></tr>
<tr>
<td> Вывести информацию о пакете
</td><td> epm -qi (package)
</td><td> epm info (package)
</td><td> apt-cache show (package)
</td><td> apt-cache show (package)
</td></tr>
<tr>
<td> Обновить дистрибутив
</td><td> epm upgrade
</td><td> epm dist-upgrade
</td><td> apt-get dist-upgrade
</td><td> apt-get dist-upgrade
</td></tr></tbody></table>
</center>URL: http://etersoft.ru/about/news/418-epm
Новость: http://www.opennet.me/opennews/art.shtml?num=35098
зачем?
Это первый вопрос, который обычно приходит бездарям, когда они встречают что-то новое и неизвестное.Ответ. Не знаете зачем - пользуйтесь тем, что знаете.
>>Не знаете зачем - пользуйтесь тем, что знаете.Обожаю ответы без ответов, вы наверняка и сами не знаете)) Но "зачем" мне тоже интересно
Пока что мы видим, что эта программа избавляет админа от необходимости помнить пару десятков команд (конечно, если он пользуется разными дистрами). Вопрос в том, что идет после этых команд? Обычный пакет для конкретной версии конкретного дистра?
Они просто упростили себе написание инсталляторов для разных дистров ))
> Они просто упростили себе написание инсталляторов для разных дистров ))Насколько понимаю, в том числе ради возможности дальнейшего развития http://wiki.etersoft.ru/Korinf -- сейчас требуется наполнение сборочных сред (чрутов/хостов) вручную.
PS: название не совсем честное -- это не менеджер, а минимальная надстройка-транслятор.
> PS: название не совсем честное -- это не менеджер, а минимальная надстройка-транслятор.Я думаю, что это название новости, чтобы «зацепило». Вообще мы обсуждали такое название: средство управления пакетами. Чуть получше, чем просто «пакетное средство» :)
Лет через 5 ждем универсальное средство по управлению универсальными средствами ))
> Я думаю, что это название новости, чтобы «зацепило».Ох и зацепило... :)
>> PS: название не совсем честное -- это не менеджер, а минимальная надстройка-транслятор.
> Я думаю, что это название новости, чтобы «зацепило». Вообще мы обсуждали такое
> название: средство управления пакетами.Название в любом случае неудачное. Уже есть достаточно
известный проект с таким именем.
>> PS: название не совсем честное -- это не менеджер, а минимальная надстройка-транслятор.
> Я думаю, что это название новости, чтобы «зацепило». Вообще мы обсуждали такое
> название: средство управления пакетами. Чуть получше, чем просто «пакетное средство»
> :)Вот подобные вещи, точнее вообще ВСЕ действия, я бы выделил в отдельные маленькие
перекрываемые пользователем функции.
apt-rpm|apt-dpkg)
#sudocmd apt-get check || exit
sudocmd apt-get update || exit
sudocmd apt-get -f install || exit
;;
apt-dpkg)
sudocmd apt-get update || exit
sudocmd apt-get -f install || exit
sudocmd apt-get autoremove
;;Штучки вроде apt-get autoremove и apt-get -f install, скажем так,
неоднозначны, как, собственно, и sudo. Их нужно отдать на откуп пользователю.
В BSD традиция такая: есть неизменяемый xxx.default.conf и есть
изменяемый xxx.conf, явно или неявно включающий xxx.default.conf,
для перекрытия его настроек.
Вообще то этот вопрос должен приходить в голову бездарям, которые собираются построить очередной не нужный велосипед. Конечно если у них хватит ума, они не станут этого делать.
> Вообще то этот вопрос должен приходить в голову бездарям, которые собираются построить очередной не нужный велосипед. Конечно если у них хватит ума, они не станут этого делать.Уже сколько здесь об этом говорилось, а бездари на этом все попадаются и попадаются.
Если вы не знаете разницы между изобретением велосипеда и его реализацией - вы лишь демонстрируете этим, что до осмысления индустрии ИТ вам как пешком до Луны.
Вы и относительно велосипедов вы совершенно уверены, что все созданные модели и модификации тоже по вашему абсолютно не нужны. И вас вполне устраивает велосипед с большим ведущим колесом без цепной передачи.
> И вас вполне устраивает велосипед с большим ведущим колесом без цепной передачи.Да, поэтому я не вижу причин делать ещё один такой-же велосипед. Ведь судя по вашей демагогии с уходами от ответа и переходом на личности, у этого велосипеда нет существенных отличий от всех остальных.
>> И вас вполне устраивает велосипед с большим ведущим колесом без цепной передачи.
>
> Да, поэтому я не вижу причин делать ещё один такой-же велосипед.По вашей логике получается что все другие велосипеды такие же, только потому, что они велосипеды.
Вы чувствуете уже, что попались, и не знаете теперь как выкрутиться.> Ведь судя по вашей демагогии с уходами от ответа и переходом на личности,
Если вас что-то не устраивает, это еще не факт что это была демагогия.
Зачем вам мой ответ, идите на сайт разработчиков и получите там все необходимые ответы.Просто вам не ответы нужны, а поводы к чему-то прицепиться.
> у этого велосипеда нет существенных отличий от всех остальных.
Значит в вашем понимании это так.
>> И вас вполне устраивает велосипед с большим ведущим колесом без цепной передачи.Это вроде тех ещё? :) http://bicycle.net.ua/good-to-know/istoriya-izobretenie-velo.../
> Да, поэтому я не вижу причин делать ещё один такой-же велосипед.
Дяденьки, не ругайтесь, а? Обсуждение обсуждения -- один из наиболее удачных способов бездарно угробить своё и чужое время, особенно если даже не пытаться услышать "собеседника" :(
>Обсуждение обсуждения -- один из наиболее удачных способов бездарно угробить своё и чужое времяНе согласен. "разработка EPM" - намного более удачный.
> Дяденьки, не ругайтесь, а? Обсуждение обсуждения -- один из наиболее удачных способов бездарно угробить своё и чужое время, особенно если даже не пытаться услышать "собеседника" :(Кто о чем, а Михаил о борьбе за мир. :)
Вам бы в Сирию - там миротворцы сейчас очень нужны.
А то опоздаете, и как в Югославии без вас разберутся.
Я знаю и rpm, и urpmi, и apt, и dpkg, и pkgtools, и yum, и emerge(всякие пакманы и прочий мусор - не знаю). И я таки спрашиваю. Зачем?
Для универсальности.
> Для универсальности.Эм... проблема в том что названия пакетов в разных дистрах могут быть разные. Попытка привести их к общему знаменателю требует какой-то далеко не самой тривиальной логики. А если оно просто обертка чтобы дергать разные пакетные менеджеры - не понятно нафига? Для группового администрирования разнородного зоопарка - все испортит озвученный факт.
Какая может быть универсальность, если все эти пакетные менеджеры разные? И у каждого есть свои плюсы и минусы. А надстройка над ними не принесёт никакого толку.
> Какая может быть универсальность, если все эти пакетные менеджеры разные? И у каждого есть свои плюсы и минусы. А надстройка над ними не принесёт никакого толку.А я вот другое не пойму, как вообще удалось сделать пакетные менеджеры?
Если все эти программы разные, и у каждой есть свои плюсы и минусы.Как их удается устанавливать с помощью одного какого-то пакетного менеджера?
И какой это приносит толк?
Узнать, как установить/удалить пакет можно в мане за несколько секунд. А вот сделать что-то серьёзное этот epm не позволяет, потому как надо всё-равно изучать особенности пакетного менеджера. Так спрашивается, нафига нужна такая универсальность?
> Узнать, как установить/удалить пакет можно в мане за несколько секундну это же относится и к EPMу. Причем достаточно будет почитать ман только для него, если случаи не сложные и не клинические
> А вот сделать что-то серьёзное этот epm не позволяет
вероятно, он еще дальше будет развиваться. Правда, непонятно, смогут ли они разное "серьезное" разных пакетных менеджеров объединить под одним знаменателем. Но возможно пока достаточно и общих штатных возможностей. Зато Вы можете писАть универсальные скрипты для сопровождения софта для большого зоопарка дистрибутивов. Правда, остается вопрос, который поднимали выше - про разное наименование пакетов в дистрибутивах
безусловно это очень ценные знания и обладать ими должен каждый
> ...всякие пакманы и прочий мусор - не знаю...Вот Вы сами и ответили на свой вопрос. Причем, проявив себя одновременно и как невежа (обозвав нужные кому-то программы мусором) и как невежда (сознавшись что не знаете половину того что заявлено в поддержке у EPM'а). Прям взяли и очертили круг - это не мусор (и я его знаю), а все остальное мусор. А я толком и не линуксоид (сейчас), но в свое время много работал с rpm, а остальные менеджеры знал только по названиям (т.е. они все для меня были "мусором" по Вашей терминологии). И мне не нужно было изучать этот "мусор" - "apt, dpkg ... zypper, mpkg, slackpkg", а если бы пришлось работать с чуждым для меня дистрибутивом, а потом со следующим - то мне, как простому любителю, было бы неинтересно изучать и их пакетные менеджеры - EPM бы в таком случае мне очень подошел для простого добавления/обновления/удаления пакета. Ну а Вам, как крутому профессионалу, знающему все тонкости dpkg, pkgtools,... , и желающему превратить простую установку обычного пакета в нечто очень сложное и уникальное именно для данного менеджера и дистрибутива этот EPM, конечно, не подойдет
> Это первый вопрос, который обычно приходит бездарям, когда они встречают что-то новое
> и неизвестное.А если бы тема была про Wayland, systemd, *kit, etc?
> А если бы тема была про Wayland, systemd, *kit, etc?Тогда бы пришла группа мальчиков-зайчиков петь о том, как это здорово -- как раз очередной повод вон состоялся.
>> А если бы тема была про Wayland, systemd, *kit, etc?
> Тогда бы пришла группа мальчиков-зайчиков петь о том, как это здорово --
> как раз очередной повод вон состоялся.Вы сами развели тут коментарню-гадюшник. Вырубите комментирование - пусть в форуме резвятся, с эсэсовцами-модераторами.
> Вырубите комментирование - пусть в форуме резвятся, с эсэсовцами-модераторами.Да и в новостях модераторы не в розовых бантиках.
Ок. Больше универсальных пакетных менеджеров хороших и разных
> Ок. Больше универсальных пакетных менеджеров хороших и разныхЭволюции нужен генный материал
"позволит существенно упростить процедуру управления пакетами для тех, кто работает с множеством дистрибутивов: системных администраторов, разработчиков, тестировщиков"Не благодари )
> зачем?Потому что гладиолус^W http://xkcd.com/927/
Чтобы освободить голову от этих ненужных (как считают авторы) знаний. А также сберечь мильоны человеко часов в масштабах планеты и потратить эти мильоны человеко часов на чтото возможно болеее полезное.
Для универсальности. Особенно удобно тем, кто пользуется несколькими дистрибутивами (самостоятельно, либо какой-нить "лес" на новом рабочем месте). Не будет необходимости заглядывать в man разных утилит для установки.Пусть даже будет чуть медлительнее оригиналов - главное чтобы грамотно управляла основной базой пакетов. А если современем "запилят" дополнительный функционал по управлению пакетами, то цены им не будет.
для пользователей самое то, для опытных и админов - выбор по желанию.
> Для универсальности.Чиво? Какая, к чертям, универсальность - #157, #96.
"позволяет выполнять необходимые операции на любой платформе с помощью единого набора команд" вы же читать умеете, наверное если писать научились? и не сводите все к детской шутке, а ты купи слона. не нравиться не ешь.
Ценность сомнительна.
Надстройка над надстройками.
Имхо, тем, кто работает с разными дистрибутивами, лучше один раз запомнить наборы команд.
По большому счету, вариантов немного: apt/yum/zypper.
Тем более, если человек хочет углублять свои знания, а не отгораживаться от дистрибутивов за надстройками.Один фиг, любая проблема и придется работать с родными утилитами.
Кроме того, есть шанс, что надстройка будет неправильно определять, в какой она системе.
Например, если в Alt Linux установить aptitude (он там есть), то puppet думает, что он в debian based системе.
И установка пакетов через puppet не работает.
http://docs.puppetlabs.com/references/latest/type.html#packageprovider
The specific backend to use for this package resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform. Available providers are:
> Ценность сомнительна.Даже если ценность конкретной инновации сомнительна, любая инновация сама по себе создает крайне полезный прецедент - чтобы существующие технологии не застаивались, не шли на поводу у ширпотребляющей аудитории, не _монолит_изировались, а оставались гибкими и модульными, и не обрастали толстым жиром второсортного функционала.
И вообще, чтобы никто не забывал о конкуренции.
> Имхо, тем, кто работает с разными дистрибутивами, лучше один раз запомнить наборы командзапомнить это конечно хорошо, но когда помимо основной работы в разношёрстной сети админишь временами, то иногда мозги закипают вспоминать каждый раз где что как называется.
Хотя, по мне так реализация у сабжа не совсем удачная, imho лучше было что-то вроде нескольких фронтендов от родной системы сделать, например aptitude-rh для эмуляции aptitude на редхатовских системах, yum-deb для обратного. Сложить это всё в один пакет, с документацией касательно отличий от оригинального интерфейса (всё равно такой транслятор не сможет всю функциональность передать, только подмножество).> Один фиг, любая проблема и придется работать с родными утилитами.
Это понятно, при проблемах и времени выделяешь больше, лишний раз маны почитать. А вот на рутину как раз не хочется заморачиваться, когда знаешь что оно и так и так пройдёт.
P.S. кстати, может кто подскажет, как под opensuse быстро с консоли найти инфу про пакет, как это например aptitude search/show делает, без того что-бы гуйный yast2 открывать?
нашёл zypper , не знал про него, спасибо.
Там надо просто давать по голове тем, кто устраивает зоопарк. Очень редко есть причны в продакшне сидеть на нескольких дистрибутивах, обычно это просто отражение помойки в головах IT-отдела
> Там надо просто давать по голове тем, кто устраивает зоопарк. Очень редко есть причны в продакшне сидеть на нескольких дистрибутивах, обычно это просто отражение помойки в головах IT-отделаПричина банальная - мы не решаем за наших клиентов где им хоститься и какую систему ставить. И ещё обычно ставим у себя виртуалку чтобы эмулировать хостинг клиента, против всяких детских неожиданностей.
> Причина банальная - мы не решаем за наших клиентов где им хоститься
> и какую систему ставить.Причина глупая, если вы предлагаете клиенту администрирование (см. контекст реплики, на которую вы ответили). Если системный администратор не умеет за клиента выбрать операционную систему на сопровождаемом сервере - нафейхуа он такой нужен?
Если же вы об установке какого-то вашего программного продукта - то о такой банальной причине уже писали выше, советуя puppet, cfengine, etc. (Добрый дяденька модератор снес мой комментарий). Ради тестирования продукта на N-м числе систем - бардак, увы, делать приходится.
ну спасибо, передам начальству как договора с клиентом оформлять, а то они и не знают :)
> Если системный администратор не умеет за клиента выбрать операционную систему
> на сопровождаемом сервереЯ не умею выбирать за клиента ОС, если взялся сопровождать уже летящий сервер с нетривиальным комплектом на борту. Другое дело, что в такое старался и не вляпываться -- а кратковременно выручать доводилось и с Solaris, и с AIX, и с BSD, и с прочими редхатами.
> (Добрый дяденька модератор снес мой комментарий)
Простите, но с него и пошёл знатный флейм. :( Может, восстановИте в конструктивной части?..
> Хотя, по мне так реализация у сабжа не совсем удачная, imho лучше
> было что-то вроде нескольких фронтендов от родной системы сделать, например aptitude-rh
> для эмуляции aptitude на редхатовских системах, yum-deb для обратного.Это бы чуточку помогло (за счёт таба), но чревато небольшим комбинаторным взрывом даже на имеющемся количестве кандидатов...
>> Хотя, по мне так реализация у сабжа не совсем удачная, imho лучше
>> было что-то вроде нескольких фронтендов от родной системы сделать, например aptitude-rh
>> для эмуляции aptitude на редхатовских системах, yum-deb для обратного.
> Это бы чуточку помогло (за счёт таба), но чревато небольшим комбинаторным взрывом
> даже на имеющемся количестве кандидатов...Он уже случился, если что. Линус открыл ящик Пандоры.
>> но чревато небольшим комбинаторным взрывом
>> даже на имеющемся количестве кандидатов...
> Он уже случился, если что. Линус открыл ящик Пандоры.И как оказалось, выходит куда интереснее one microsoft way. А configuration management уже даже я озадачился несколько лет как -- поскольку дело-то не в дистрибутивах, а в задачах: люди не штамповки и задачи у них разные, как бы ни пытались некоторые вендури всех в свои прокрустовы мерки уложить.
Просто на линуксе можно сделать и один дубовый редхат, и несколько десятков вариаций альта одним make. За то и ценим.
> Просто на линуксе можно сделать и один дубовый редхат, и несколько десятков
> вариаций альта одним make. За то и ценим.наверное во первых всеже не просто, а во вторых если можно обойтись одним мэйком в этом вашем альте, напуркуа тогда дистровотч знает еще 100500 дистров? это все болгеносы и они украли у вас идею мэйка? что с ними не так?
> наверное во первых всеже не простоС виндой такое ближе к невозможному, например.
> а во вторых если можно обойтись одним мэйком в этом вашем альте, напуркуа тогда
> дистровотч знает еще 100500 дистров?Ответ уже был в #91.
> что с ними не так?
Пока что-то не так разве что с теми, кто пытается судить совсем другой мир по привычному мирку. Попробуйте задуматься: бывает так, что не "крадут", а делятся -- поэтому можно просто взять то, что есть, и сделать то, что нужно или интересно.
Проблемы в этом совсем другом мире тоже заметно отличаются -- и они, разумеется, есть. Только не те, о которых расскажут у прянишниковых века сего.
>> наверное во первых всеже не просто
> С виндой такое ближе к невозможному, например.Я где-то упоминал о винде? или для вас ОС делятся только на линукс и винда? другого не воспринимаете? жаль, иногда стоит оглядеться вокруг..
>> а во вторых если можно обойтись одним мэйком в этом вашем альте, напуркуа тогда
>> дистровотч знает еще 100500 дистров?
> Ответ уже был в #91.Ответ простой простой на самом деле, ваш мейк узкоспециален и не подойдет для других 100500 применений.
>> что с ними не так?
> Пока что-то не так разве что с теми, кто пытается судить совсем
> другой мир по привычному мирку. Попробуйте задуматься: бывает так, что
> не "крадут", а делятся -- поэтому можно просто взять то, что
> есть, и сделать то, что нужно или интересно.Вы в точности описали себя со стороны. Не пытайтесь судить о человеке только потому что он где-то справедливо критикует линукс. К счастью кроме линукса и винды есть еще и более другие ОС.
> Проблемы в этом совсем другом мире тоже заметно отличаются -- и они,
> разумеется, есть. Только не те, о которых расскажут у прянишниковых
> века сего.Нет, проблема в вас, вы не способны понять, что есть те кто не юзает линукс и не знает кто такие прянишниковы. Черное/белое, враг/друг, линукс/винда... вот ваше ограниченное восприятие мира :(
>>> наверное во первых всеже не просто
>> С виндой такое ближе к невозможному, например.
> Я где-то упоминал о винде?Нет, её привел я в качестве контрпримера.
> Ответ простой простой на самом деле, ваш мейк узкоспециален и не подойдет
> для других 100500 применений.Так дело вообще не в make, а в ограниченности результата (как минимум рамками взятого за основу альта). Естественно, что для целого моря случаев этот результат не подходит даже весь скопом.
> Вы в точности описали себя со стороны.
Может быть -- в конце концов, каждый склонен особо замечать в других свои недостатки...
> Не пытайтесь судить о человеке только потому что он где-то справедливо критикует
> линукс.Не увидел критики, тем более справедливой, если речь о #88.
> К счастью кроме линукса и винды есть еще и более другие ОС.
Разумеется.
> Нет, проблема в вас, вы не способны понять, что есть те кто
> не юзает линукс и не знает кто такие прянишниковы.Есть и такие, почему же.
> у них разные, как бы ни пытались некоторые вендури всех в
> свои прокрустовы мерки уложить.Так уложили же - сейчас кроме UNIX и NT по-сути ничего нет. А раньше были и ОС от DEC, ОС от IBM. ;-)
да, у них у всех тут линукс головного мозга, а чуть что сразу винду приплетают, при том что в этом самом линуксе проблем чуть более чем до... много.
Для меня от линукса есть только одна польза он заставляет искать альтернативы. Кстате наши DB админы тоже линукс не уважают, поставили поигрались и как-то остались на соляре.
Дорогой друг, ты перечислил два UNIX'а в качестве возражения на фразу, что кроме UNIX/UNIX-подобных систем и NT ничего не осталось.> При том - AIX is NOT UNIX. Они юниксоподобный слегка, на уровне мира, но не более, чем.
;-) "IBM AIX UNIX on Power Systems including System p" - шапка сайта http://www-03.ibm.com/systems/power/software/aix/
У IBM есть система z/OS, которая не UNIX-подобная - http://www-03.ibm.com/systems/z/os/zos/ Но ней никто как на десктопе не работает.
> Solaris - Оракл его не выкинул, приколись!
;-) Solaris - это практически первосортный UNIX. У Sun'а, кстати, тоже была не UNIX-подобная система. Называлась ChorusOS, а отнюдь не Solaris. Ссылка на неё - http://docs.oracle.com/cd/E19048-01/chorus5/index.html
В общем, рекомендуется читать реплики, на которые отвечаешь.
...
> P.S. кстати, может кто подскажет, как под opensuse быстро с консоли найти
> инфу про пакет, как это например aptitude search/show делает, без того
> что-бы гуйный yast2 открывать?$ epm show package
:)
> P.S. кстати, может кто подскажет, как под opensuse быстро с консоли найти
> инфу про пакет, как это например aptitude search/show делает, без того
> что-бы гуйный yast2 открывать?rpm -qi? rpm -qip?
если кому-нибудь нужно, пусть живет, но жутко напоминает идеи Поттеринга... не приветствую их.
Интересно, какой use-case они предусматривали, разрабатывая это? Вот реально не понимаю области практического применения.
> Интересно, какой use-case они предусматривали, разрабатывая это? Вот реально не понимаю
> области практического применения.Зато xkcd давно понял сие в комиксе за номером 927 :)
rpm + apt + urpm = ЁпеРный эМ
Слегка интересно - они все команды реализовали или только минимальный набор, т.е. они по пути aptitud'а идут или по пути wajig?
если бы он умел ещё и прямо работать со всеми текущими типами пакетов...
в distr_info также видно что есть поддержка мопса и линукс хапэ >_<
http://imgs.xkcd.com/comics/standards.png
Гы, прикол. Ну, пусть будет. В дополнение к PackageKit и smart добавлю Zero Install и AppStream (который, насколько я знаю, не вышел).
А, нет, вышел: http://www.linuxcenter.ru/news/2012/10/04/13656/
Напомнило
http://imgs.xkcd.com/comics/standards.png
третьим будешь
> третьим будешьПятым, не меньше. Парад Капитанов объявляется открытым!
Пока анонимусы метают какашки в форумах, этерсофт делает полезные штуки.
>Пока анонимусы метают какашки в форумах, этерсофт делает полезные штуки.Возможно. Но сабж к ним не относится.
>>Пока анонимусы метают какашки в форумах, этерсофт делает полезные штуки.
> Возможно. Но сабж к ним не относится.Когда делал первый подход к разворачиванию коринфа -- мыслишка о чём-то подобном проскакивала. Согласен, это весьма узкоспециализированное применение.
> Когда делал первый подход к разворачиванию коринфа -- мыслишка о чём-то подобном
> проскакивала. Согласен, это весьма узкоспециализированное применение.У каждого, кто на компе не только сидит в вконтактике в течение более полугода, есть не одна такая "узкоспециализированная софтина". Вот только раньше считалось, что реальная софтина - это UNIX + shell + utils, а то, что ты для себя на коленке из них делаешь - обычные пользовательские скрипты. А теперь оказывается, что любой скрипт в котором есть case/esac - это уже повод для новости?
> более полугода, есть не одна такая "узкоспециализированная софтина". Вот только раньше...
> а то, что ты для себя на коленке из них делаешьВ том и проблема, что эти решения кого-то там на коленке для себя никак не снижают порог вхождения, не позволяют поделиться с другими.
Вам удобно писать $ sudo apt-get install package ?
Мне больше нравится написать
$ epmi package
и не думать судорожно, в какой я сейчас системе, и какой пакетный менеджер в этой версии (См. изменения пакетных менеджеров в Solaris, FreeBSD и т.п.)Я уж молчу про такую простую вещь, как определить, к какому пакету принадлежит файл.
> В том и проблема, что эти решения кого-то там на коленке для
> себя никак не снижают порог вхождения, не позволяют поделиться с другими.Установка/удаление пакетов в системе - это работа root'a. Если это локалхост, то его владелец (он же root) освоит свою утилиту за 5-10 мнут по мануалу и будет ею пользоваться. Если же давать доступ root'а к чужой системе человеку, для которого 5 минут на чтение мануала (или двухчасовые курсы для домохозяек на освоение 5-6 разных пакетных менеджеров) - это слишком высокий "порог вхождения", для вас нормально... ну ладно...
Пожалуйста, без личных обид, мне действительно очень жаль, но... мне кажется вы сейчас делаете очень нехорошую "чёрную рекламу" Ethersoft'у. И это печально:(
...
> (или двухчасовые курсы для домохозяек на освоение 5-6 разных пакетных менеджеров)
> - это слишком высокий "порог вхождения", для вас нормально... ну ладно...Не могу согласиться. 6 пакетных менеджеров за два часа? Видимо, у вас феноменальная память, если через 2 месяца после этого вы сможете с помощью pacman определить принадлежность файла к пакету или поискать пакет среди установленных. Я так не могу, я забываю через некоторое время все эти команды.
Потом, ну расскажите, где взять информацию о 6 пакетных менеджерах? Я вот создал когда-то страничку http://freesource.info/wiki/NachatyeProekty/UstanovkaPaketov...
и каждый раз до появления epm к ней обращался, когда мне нужно было сделать что-то сложнее yum install....
> Пожалуйста, без личных обид, мне действительно очень жаль, но... мне кажется вы
> сейчас делаете очень нехорошую "чёрную рекламу" Ethersoft'у. И это печально:(Мы всего лишь делимся нашей разработкой, аналогов которой нет, и которая нам оказалась очень полезной (в том числе для автоматизации управления пакетами в контейнерах).
> Вам удобно писать $ sudo apt-get install package ?
> Мне больше нравится написать
> $ epmi package
> и не думать судорожно, в какой я сейчас системе, и какой пакетный
> менеджер в этой версии (См. изменения пакетных менеджеров в Solaris, FreeBSD
> и т.п.)Думать (ВНЕЗАПНО!) - так придется. Как только вАлшебная комманда не обнаружит пакета, отличающегося чуток именем. Или понаставит то, что сам не ожидал (иные опции сборки пакета, меняющие функционал патчи, иначе побит пакет и т.п.).
Как должен был бы называться пакет c модулем xcache для PHP4? php4-xcache? php-xcache? Оба варианта "жили" в разных дистрибутивах в одно и то же время. И php-xcache мог быть версией для PHP5. А егойную админку обязательно туда включать - или можно вынести в отдельный пакет?
> Я уж молчу про такую простую вещь, как определить, к какому пакету
> принадлежит файл.Вот это уже походит на реальное достоинство. Но как-то негусто...
В качестве альтернативы - не разумнее стараться свести гетерогенный бардак к минимуму, а не замазывать его сомнительными удобствами?
Не спорю, можно перекрасить "лимонку" в лимон - чтобы выглядело похоже. Но уж лучше всегда твердо помнить что держишь в руках ;)
> Думать (ВНЕЗАПНО!) - так придется. Как только вАлшебная комманда не обнаружит
> пакета, отличающегося чуток именем. Или понаставит то, что сам неОна не волшебная. См. ниже.
> Как должен был бы называться пакет c модулем xcache для PHP4?
> php4-xcache? php-xcache? Оба варианта "жили" в разных дистрибутивах в$ epms xcache
Я и не знал раньше, как он называется, и знать не хочу. Надо — поищу и поставлю.> одно и то же время. И php-xcache мог быть версией
> для PHP5. А егойную админку обязательно туда включать - или
> можно вынести в отдельный пакет?Это всё не относится к управлению пакетами.
>> Я уж молчу про такую простую вещь, как определить, к какому пакету
>> принадлежит файл.
> Вот это уже походит на реальное достоинство. Но как-то негусто...Это один из примеров.
> В качестве альтернативы - не разумнее стараться свести гетерогенный бардак к минимуму,
> а не замазывать его сомнительными удобствами?Вы хотите упростить реальный мир?
Ну вот у нас вот так:
$ find -maxdepth 1
./Fedora
./Scientific
./SUSE
./MOPSLinux
./CentOS
./Gentoo
./LinuxXP
./PCLinux
./ArchLinux
./ASPLinux
./Ubuntu
./Special
./Slackware
./Mandriva
./ROSA
./SLED
./Debian
>> В качестве альтернативы - не разумнее стараться свести гетерогенный бардак к минимуму,
>> а не замазывать его сомнительными удобствами?
> Вы хотите упростить реальный мир?Нет, я хочу понять - зачем такой бардак нужен в реальных задачах. Тут назвали пока одну причину - тестирование разработанного программного продукта в разных системах. Увы, под такую задачу существуют более удобные инструменты - причем давно (puppet, cfengine, и т.п.).
> Ну вот у нас вот так:
Мне отсюда не видно, что полезного делается "у вас" этим зоопарком вообще. И какое отношение это имеет к реальному миру и реальным задачам - в частности.
>>> В качестве альтернативы - не разумнее стараться свести гетерогенный бардак к минимуму,
>>> а не замазывать его сомнительными удобствами?
>> Вы хотите упростить реальный мир?
> Нет, я хочу понять - зачем такой бардак нужен в реальных задачах.Ну это не особо имеет отношения к теме. Мы же не навязываемся. Если кому-то не нужно — мы только рады. Мы сами рады от бардака избавится, но когда мы говорим клиенту, что везде надо ставить ALT Linux, он говорит, что у него всё на Gentoo и его устраивает :)
> Тут назвали пока одну причину - тестирование разработанного программного продукта
> в разных системах. Увы, под такую задачу существуют более удобные
> инструменты - причем давно (puppet, cfengine, и т.п.).Ну представьте, что есть админ, и он для 10 разных клиентов админит 10 разных систем.
Я не очень разбираюсь, но подозреваю, что
а) puppet и cfengine не так легко развернуть
б) основная их задача вовсе не управление пакетами
в) на произвольной системе их не развернёшь, особенно на системе клиента
> Ну это не особо имеет отношения к теме. Мы же не навязываемся.
> Если кому-то не нужно — мы только рады. Мы сами рады
> от бардака избавится, но когда мы говорим клиенту, что везде надо
> ставить ALT Linux, он говорит, что у него всё на Gentoo и его устраивает :)Если администрируете сервер вы - выбор должен оставаться за вами. Вы же не даете в этом случае клиенту root-доступы? :)
> Ну представьте, что есть админ, и он для 10 разных клиентов админит 10 разных систем.
Да представляю-то влегкую. Только хороших слов для описания этого человека у меня не находится, если он не пытается избавиться от такого бардака...
> а) puppet и cfengine не так легко развернуть
Делать все правильно - поначалу непривычно и => сложно. Зато окупается потом во всех смыслах.
> б) основная их задача вовсе не управление пакетами
Ну да. Это само по себе весьма "промежуточная" задача. А реальная - "развернуть БД-сервер с такими-то настройками". Вот на такие задачи puppet и ориентирован, а "пакеты" - часть понятий, которыми он оперирует в скриптах при развертывании решений.
Работа с пакетами, в целом, получается достаточно системонезависимой. Ну, за исключением подводных камней с именами пакетов и т.п.
В общем, вот:
http://docs.puppetlabs.com/references/latest/type.html#package> в) на произвольной системе их не развернёшь, особенно на системе клиента
Да, если вы не администрируете сервер, а пришли решить конкретную задачу и ушли...
>> Ну это не особо имеет отношения к теме. Мы же не навязываемся.
>> Если кому-то не нужно — мы только рады. Мы сами рады
>> от бардака избавится, но когда мы говорим клиенту, что везде надо
>> ставить ALT Linux, он говорит, что у него всё на Gentoo и его устраивает :)
> Если администрируете сервер вы - выбор должен оставаться за вами.Что значит должен. Современные серверные системы могут быть настолько сложными, что администрируются разными командами специалистов.
Это еще в вашем любимом СССР освоили. Вы никогда не видели, как "администрируются" самолеты, чуть посложнее кукурузника. МИГ-и, например.
Или может скажет, что в современной хирургии каждого пациента должен оперировать один хирург.
Ничего вы не знаете о профессиональном администрировании.
> Вы же не даете в этом случае клиенту root-доступы? :)
Сразу видно, что вы не знаете, как в профессиональном администрировании распределяются права доступа без root.
>> Ну представьте, что есть админ, и он для 10 разных клиентов админит 10 разных систем.
> Да представляю-то влегкую. Только хороших слов для описания этого человека у меня не находится, если он не пытается избавиться от такого бардака...Ничего вы не представляете, у вас одни эмоции, а вместо знаний лишь зазубренные методики и стереотипы 10-летней давности, аккурат совпадающие по времени с вашем стажем в этой области.
>> а) puppet и cfengine не так легко развернуть
> Делать все правильно - поначалу непривычно и => сложно. Зато окупается потом во всех смыслах.Ну вот судя по вашим словам, в "компаниях с прибылью", в которых вы 10 лет работаете, правильно как раз и не делают. То есть это было правильно как раз 10 лет назад, когда серверные системы были гораздо проще.
За это время уже многое изменилось, а у вас все так и осталось. Так обычно и бывает в тех компаниях, где собираются люди, мечтающие вернуться в СССР.
> Ну да. Это само по себе весьма "промежуточная" задача. А реальная - "развернуть БД-сервер с такими-то настройками". Вот на такие задачи puppet и ориентирован, а "пакеты" - часть понятий, которыми он оперирует в скриптах при развертывании решений.
> Работа с пакетами, в целом, получается достаточно системонезависимой. Ну, за исключением подводных камней с именами пакетов и т.п.Ну да. А если кто-то взял, и решил задачу по-другому, вам это уже кажется неправильным, потому что непривычно для вас и вы понять ничего уже не можете.
> В общем, вот:
> http://docs.puppetlabs.com/references/latest/type.html#packageМогу с большой вероятностью предположить, судя по вашим предыдущим представлениям об "администрировании серверов" что если вам устроить реальное "собеседование" хотя бы по вашему любимому puppet, то вы его сольете в "99% случаев".
>> в) на произвольной системе их не развернёшь, особенно на системе клиента
>
> Да, если вы не администрируете сервер, а пришли решить конкретную задачу и ушли...Рассуждаете, как дилетант. "Пришли/ушли", "администрируете сервер". Что такое сервер в вашем понимании? Они ведь очень и очень разными бывают. А вы видимо видели только такие, которые стоят в ваших "компаниях", и думаете, что как-то по другому невозможно.
Коллеги, смесь зерна и плевел в итоге идёт как плевелы! :(
> Коллеги, смесь зерна и плевел в итоге идёт как плевелы! :(Просто я умею изъясняться с оппонентом на его собственном языке.
Пока он не начинает чувствовать абсурдность своего собственного мышления, основанного на крайностях. Двигаюсь от противного. Был такой математик по имени Противный, именем которого назвали этот метод.
Я пускаю встречный пал, а вы пытаетесь погасить пожар, дуя на пламя. Загоняете проблему вглубь, мешая людям высказываться на неприятные для вас темы в неприятной для вас форме.
> Я пускаю встречный пал, а вы пытаетесь погасить пожар, дуя на пламя.Естественно, потому как жилые дома рядом Вас не смущают.
> Загоняете проблему вглубь, мешая людям высказываться на неприятные для вас темы
> в неприятной для вас форме.Вашего оппонента в недавнем споре не стал пытаться переспорить или "отзеркалить" ровно потому, что предложение перебраться в почту и не мешать окружающим осталось AFAIK без ответа, а мозолить глаза многим ради выяснения позиций двоих всё-таки хуже.
>> Я пускаю встречный пал, а вы пытаетесь погасить пожар, дуя на пламя.
>
> Естественно, потому как жилые дома рядом Вас не смущают.Это вы уже решили углубиться в аналогии. Хотя идею вы поняли.
Но если хотите поупражняться - пожайлуйста. Только обоснуйте сначала, что там рядом именно жилые дома, может там просто куча мусора или просто сухая трава отжившая свое. Углубляясь в аналогии, полезно не забывать об исходном предмете.> Вашего оппонента в недавнем споре не стал пытаться переспорить или "отзеркалить" ровно потому, что предложение перебраться в почту и не мешать окружающим осталось AFAIK без ответа,
"А шо я буду с этого иметь", если я переберусь в почту? Форумы для того и существуют, чтобы люди обменивались мнениями публично, даже если речь идет о "позициях двоих".
> а мозолить глаза многим ради выяснения позиций двоих всё-таки хуже.
Кому-то может мозолит глаза, а для кого-то может очень познавательно и поучительно. Как это вы за всех решили. Вы на себя модераторские функции возложили, вот вы и думайте какой именно аудитории отдать предпочтение, а всем вы в любом случае не угодите. Сделаете одно - уйдут одни, останутся другие. Сделаете другое - уйдут другие, останутся первые. Ну естественно, я это для краткости утрировал - вариантов гораздо больше, чем два.
Только не рассказывайте мне сказки, что якобы это не интересует абсолютно никого. Я знаю, кому это интересно. А если захотите протолкнуть идею, что это может быть интересно исключительно подонкам и мерзавцам, у вас может получиться, как у того оппонента, который пытался отождествить свободу с наркоманией и проституцией. Так чо уж лучше сразу удаляйте от греха подальше.
Только я сейчас вижу, что вы снова печетесь не об общественных интересах, а о своих собственных. Я лицемерие очень хорошо чувствую.
> что там рядом именно жилые дома, может там просто куча мусораЛюди рядом плохо ли, хорошо ли обсуждают предложенный предмет обсуждения (EPM). Вон даже в результате критики доработки получились. Надеюсь, всё-таки заметили.
> "А шо я буду с этого иметь", если я переберусь в почту?
Обмен мнениями.
> Форумы для того и существуют, чтобы люди обменивались мнениями публично,
> даже если речь идет о "позициях двоих".Этот -- тематический. (краснея)
>> а мозолить глаза многим ради выяснения позиций двоих всё-таки хуже.
> Кому-то может мозолит глаза, а для кого-то может очень познавательно и поучительно.
> Как это вы за всех решили.За всех не берусь, а мне тут иной раз при аналогичном разведении офтопика пинков доставалось от разных и толковых притом людей, да и историю {talk,smoke}-room@altlinux знаю не в пересказе.
В частности, и я бы высказался насчёт "кармы" etc, но за мной попыток дотащить неприятные сведения снаружи до коллег-технарей из наших в общем-то благополучных слоновокостных замков и так уже немало числится здесь и не только. Меру тоже надо знать.
> Вы на себя модераторские функции возложили
http://www.opennet.me/openforum/vsluhforumID3/85432.html#285
> вот вы и думайте какой именно аудитории отдать предпочтение,
> а всем вы в любом случае не угодите.Последнее кристально ясно, а первое местами определяется правилами форума и не вижу, что бы к ним из правок по существу предложить. Разумеется, субъективного отношения тоже совсем избежать не получается.
> Только я сейчас вижу, что вы снова печетесь не об общественных интересах,
> а о своих собственных. Я лицемерие очень хорошо чувствую.Поскольку его за собой в данном случае не заметил -- будьте добры, поясните. Можно и почтой по ровно тем же соображениям SNR, можно здесь, если возжелаете гласности.
> Вашего оппонента в недавнем споре не стал пытаться переспорить или "отзеркалить" ровно
> потому, что предложение перебраться в почту осталось AFAIK без ответа [...]Прежде всего потому, что вы предварительно оскорбили окружающих. Публично. Не считаю правильным запихивать это "под ковер".
Во-вторых, какой тут нужен был ответ? Считаете, что уместнее отвечать в почту - ответьте в почту.
> Прежде всего потому, что вы предварительно оскорбили окружающих. Публично.Нет, и пояснил целеполагание в явном виде по Вашему требованию извинений (86759.html#167). Мало того, подобное оскорбление оскорбляемым я в любой день готов нанести лично при встрече, ибо считаю, что они его заслуживают.
> Считаете, что уместнее отвечать в почту - ответьте в почту.
Так я Вашей не знаю вроде как, по крайней мере не вижу после нескольких пертурбаций с обработкой префиксов !/!!. Или Вы моей тоже сейчас не видите? -- на shigorin gmail com или mike altlinux org должно добраться.
> Нет, и пояснил целеполагание в явном виде по Вашему требованию извинений (86759.html#167).Ну да, я и, как говорится, "все понял" (и не только я, см. напр. #169). Странно, что вас удивляет что кто-то решится о чем-то продолжать спорить в почте, если оппонент давным давно раскрасил мир в черное-белое и на иное чужое мнение ему явно плевать.
> Мало того, подобное оскорбление оскорбляемым я в любой день готов
> нанести лично при встрече, ибо считаю, что они его заслуживают.Вы видите в этом что-то героическое? С вами просто перестанут разговаривать.
Здесь же вы - лицо до некоторой степени официальное. Вот почему, собственно, ваша позиция выглядела несколько "странной" и почему с вами "возились" вообще...
> Так я Вашей не знаю вроде как, по крайней мере не вижу
> после нескольких пертурбаций с обработкой префиксов !/!!.Пардон, тут я виноват :) Думал "модераторам - виднее" (в профиле).
> Что значит должен.Посмотрите в словаре.
> Современные серверные системы могут быть настолько сложными, что администрируются разными командами специалистов.
С разными правами, как минимум... Вопщем, вы просвещайте дальше, пока модератор ваш треп снова не порезал... Можно про МиГи, можно о нейрохирургии... Чую профи :D
Вы часом операций на себе не пытались еще делать?
>> Вы же не даете в этом случае клиенту root-доступы? :)
> Сразу видно, что вы не знаете, как в профессиональном администрировании распределяются
> права доступа без root.Сформулирую для маленького: "эквиваленты root-доступа". Чтобы детинушко не перенапряг мозг, разжую больше: давать клиенту полноценный доступ с правами администратора - "не принято" (ц).
PS: Дальше совсем скушно. Это, наверно, тот же тролль, что о свободе пел?
>> Что значит должен.
>
> Посмотрите в словаре.То есть вы решили свести все к проблеме понимания слова, и отвлечь внимание от проблемы понимания ситуации.
>> Современные серверные системы могут быть настолько сложными, что администрируются разными командами специалистов.
>
> С разными правами, как минимум...Конечно. И что дальше?
> Вопщем, вы просвещайте дальше, пока модератор ваш треп снова не порезал...
Ну, вас порезали не меньше, что меня в принципе тоже устраивает.
> Можно про МиГи, можно о нейрохирургии... Чую профи :D
А в данном случае в чем суть вашего упрека.
> Вы часом операций на себе не пытались еще делать?
Какая здесь по-вашему связь?
>>> Вы же не даете в этом случае клиенту root-доступы? :)
>> Сразу видно, что вы не знаете, как в профессиональном администрировании распределяются
>> права доступа без root.
> Сформулирую для маленького: "эквиваленты root-доступа". Чтобы детинушко не перенапряг мозг, разжую больше: давать клиенту полноценный доступ с правами администратора - "не принято" (ц).Понятно, попытка слабость аргументации компенсировать избыточным эмоциональным окрасом.
То есть вы не знаете, как можно обойтись не только без root-доступа, но даже без его эквивалентов в случае совместного администрирования. Я же говорил, что не знаете, а вы лишь это подтвердили.
> PS: Дальше совсем скушно.
С учетом тех аргументов, которыми вам здесь удалось разродиться, дальше вы просто не решились что-то отвечать.
> Это, наверно, тот же тролль, что о свободе пел?
Про свободу говорил я, или вам показалось, что я это как-то пытался скрыть?
А значит надо полагать, вы тоже, как тот мой оппонент, считаете, что единственными проявлениями свободы являются проституция, наркомания и алкоголизм. Вы тоже думаете, что люди занимаются этим в результате их свободы, а не наоборот. Для вас тоже зависимость от спиртного является свободой.
Или почему мои высказывания о свободе вы посчитали троллингом?
больше универсальных пакетных менеджеров хороших и разных
Маленькая забавность, конечно, но пакетный менеджер EPM уже давно существует http://www.epmhome.org/
> Маленькая забавность, конечно, но пакетный менеджер EPM уже давно существуетВ Обнинске выяснили, что докладчик в курсе; сизифный пакет был назван уже eepm. :)
Зачем ??? еще один костыль ???
Я лично до сих пор не понимаю зачем altlinux недо-apt, а тут еще и это детище.
Как оно будет работать с source дистрибутивами или же rpm-base ?
В каждом дистрибутиве будут возникать отдельные проблемы и описание их решения для отдельного дистрибутива ? А если в дистрибутиве что то изменится ??? то как быть ?
> Я лично до сих пор не понимаю зачем altlinux недо-apt, а тут еще и это детище.http://docs.altlinux.org/archive/2.4/master/alt-docs-devel/c...
> Как оно будет работать с source дистрибутивами или же rpm-base ?
И всё-таки помогает сперва почитать описание. :)
поддержка генты и слаки есть? Иначе не тру.
"функциональность EPM была обеспечена для таких дистрибутивов, как ... и Slackware"
и правда, emerge даже есть, если не врут.
ТОчно чушь. emerge - он, в общем-то, довольно редко запускается с аргументами, поожими на то, что есть в бинарных дистрибутивах. Если они всё так "сынтегрировали"- то это чудище Франкенштейна получится
Прошелся по гентовскому хендбуку. Ничего нестандартного не увидел. Для стандартных вещей, нужных мне в большинстве случаев, все весьма похоже.'emerge --sync' ~ apt-get update
'emerge --update --deep -with-bdeps=y world' ~ apt-get upgrade
'emerge --search pdf' ~ apt-cache search pdf
'emerge gnumeric' ~ apt-get install gnumeric
'emerge --unmerge gnumeric ~ apt-get remove gnumeric
'emerge --depclean' ~ apt-get autoremove
Немного не в тему, но 'emerge --depclean' и 'apt-get autoremove', исходя из моего криворукого опыта, имеют немного разный уровень опасности для системы, а если в deb-дистрах использовать aptitude то 'autoremove' уже не нужен.
eix мне кажеться для поиска немного удобной, без параметров выведет все что есть в "портежах"
eix -I - список всех установленных (-Ic сокращенный список)
eix phrase - выведет список всего что содержит phrase (-c кратко)
eix-sync - обновление "портежей"к сожалению и ставить с emerge. хотя может можно дать и eix команду, но не смотрел, вроде только для поиска (просто удобнее, мне по-крайне мере).
ну в man'e понятное дело много чего %)
в любом случае связка eix-sync, emerge -uDN system world, etc-update/dispatch-conf, revdep-rebuild хорошо работает если не нужно mask/unmask делать %)
Чем это лучше apt?
apt - Debian-only. Надо спрашивать "чем это лучше RPM".
Думал, что тонко пошутил, а на самом деле облажался. Apt не Debian-only.
>Думал, что тонко пошутил, а на самом деле облажался. Apt не Debian-only.Да, таки облажался. apt работает как поверх dpkg, так и rpm. Кури маны, короче.
> apt - Debian-only.В этом месте по сценарию Шаттлворт идет с досады работать дворником а Шигорин уходит в монастырь.
Шаттлворт сначала стырит из федоры пакетный менеджер, а потом сделает инновационную надстройку над ним.
Что оттуда тырить? Yum? Себе оставьте.
>> Чем это лучше apt?Оно не лучше, оно выше. В смысле "над apt". :)
> apt - Debian-only.
Нет.
> Надо спрашивать "чем это лучше RPM".
Нет.
>Оно не лучше, оно выше. В смысле "над apt". :)Куда уж выше?
Облигаторная ссылка на XKCD: http://xkcd.com/927/
> Облигаторная ссылка на XKCD: http://xkcd.com/927/боян. даже если считать, что кроме этого треда эта ссылка нигде не попадалась
> боян.Вы ничего не понимаете. Это конкурс Капитанов!
Всем советую посмотреть исходники. Масса положительных впечатлений :)
Чего только стоит гвоздями прибитое использование sudo везде, "readlink -f" для определения полного пути или вот ЭТО из epm-addrepo:echo "You need manually add repo to /etc/apt/sources.list"
Профессионализм разработчиков виден сразу. Ну и что, что они не знают про перенаправление потоков ввода/вывода. Зато это ИННОВАЦИЯ и УДОБНО.
Сама программа ни о чем совершенно. Тупо проверка, какой дистрибутив установлен, и тупо вызов родного пакетного менеджера. Никакой это не новый "универсальный пакетный менеджер", простая обертка.
> echo "You need manually add repo to /etc/apt/sources.list"Гы. "Я чукотский вирус, но из-за плохого развития IT у меня на родине я не могу вам нанести вред. Пожалуйста сотрите файлы сами и перешлите меня дальше!" :)
> Чего только стоит гвоздями прибитое использование sudo вездеЭто не так.
> "readlink -f" для определения полного пути
Что не так?
или вот ЭТО из epm-addrepo:
> echo "You need manually add repo to /etc/apt/sources.list"Ваше предложение?
> Ну и что, что они не знают про
> перенаправление потоков ввода/вывода.Что не так?
> Тупо проверка, какой дистрибутив установлен, и
Ну да, примитивная така, на 8Кб кода :)
> тупо вызов родного пакетного менеджера.
Я так понимаю, вы отлично знаете как посмотреть список подключенных репозиториев:
apt-rpm)
docmd apt-repo list
;;
apt-dpkg)
print_apt_sources_list /etc/apt/sources.list /etc/apt/sources.list.d/*.list
;;
yum-rpm)
docmd yum repolist
;;
urpm-rpm)
docmd urpmq --list-url
;;
zypper-rpm)
docmd zypper sl -d
;;
emerge)
docmd layman -L
;;
pacman)
docmd cat /etc/pacman.conf
;;
slackpkg)
docmd cat /etc/slackpkg/mirrors> Никакой это не новый "универсальный пакетный менеджер", простая обертка.
А вы только заголовок новости прочитали? :)
Ого, сам разработчик пожаловал! Приятно, приятно.
>> Чего только стоит гвоздями прибитое использование sudo везде
>Это не так.В смысле "не так"? Я в исходниках везде вызов процедуры sudocmd видел, которая проверяет, является ли пользователь рутом, и вызывает sudo, если нет. Хотите сказать, мне померещилось?
>> "readlink -f" для определения полного пути
>Что не так?ЕМНИП, readlink не входит в стандарт. Если бы вы пилили еще и поддержку соляры, то, наткнувшись на отсутствие readlink'а в ней, вы бы сильно удивились.
>> echo "You need manually add repo to /etc/apt/sources.list"
>Ваше предложение?echo "$repa" >> /etc/apt/sources.list
inb4 не будет работать, если скрипт не от рута запущен и надо вызывать sudo: можно использовать tee:
echo "$repa" | sudo tee -a /etc/apt/sources.list > /dev/null
А вообще говоря, надо с корнем выдирать это ваше sudocmd отовсюду и делать, как нормальные люди. Если команда требует прав рута, то надо проверить это в самом начале и прекратить работу, если это не так. Тогда можно обойтись нормальным, вменяемым, очевидным первым вариантом.
Sudo, кстати, тоже ни в какой стандарт не входит, и даже в дебиане по умолчанию не установлен.
>> Ну и что, что они не знают про
>> перенаправление потоков ввода/вывода.
>Что не так?У нас все студенты уже на 2 курсе знают про перенаправление ввода/вывода.
>> Тупо проверка, какой дистрибутив установлен, и
>Ну да, примитивная така, на 8Кб кода :)Да хоть на 800Кб. Ее назначение от этого не меняется.
>> Никакой это не новый "универсальный пакетный менеджер", простая обертка.
>А вы только заголовок новости прочитали? :)Нет, я всю прочитал. Но встречают, как говорится, по шапке. После прочтения заголовка я ожидал что-то более интересное увидеть.
...
>>> Чего только стоит гвоздями прибитое использование sudo везде
>>Это не так.
> В смысле "не так"? Я в исходниках везде вызов процедуры sudocmd видел,
> которая проверяет, является ли пользователь рутом, и вызывает sudo, если нет.
> Хотите сказать, мне померещилось?То, что вы описали, не является «гвоздями прибитым использованием». Повышать привилегии с помощью sudo является нормальной практикой.
> ЕМНИП, readlink не входит в стандарт. Если бы вы пилили еще и
> поддержку соляры, то, наткнувшись на отсутствие readlink'а в ней, вы бы
> сильно удивились.Удивились и исправили бы код. Проблема-то в чём?
И, может быть, сразу предложите, чем заменить?>>> echo "You need manually add repo to /etc/apt/sources.list"
>>Ваше предложение?
> echo "$repa" >> /etc/apt/sources.list
> inb4 не будет работать, если скрипт не от рута запущен и надо
> вызывать sudo: можно использовать tee:
> echo "$repa" | sudo tee -a /etc/apt/sources.list > /dev/nullПока предложенный огород не выглядит проще вызова редактора для
/etc/apt/sources.list. Суть нашего "решения" была в том, чтобы просто напомнить,
где лежит список для данного ПМ.> А вообще говоря, надо с корнем выдирать это ваше sudocmd отовсюду и
> делать, как нормальные люди. Если команда требует прав рута, то надо
> проверить это в самом начале и прекратить работу, если это неПочему вы считаете нормальным, что команда должна прекращать работу? :)
> Sudo, кстати, тоже ни в какой стандарт не входит, и даже в
> дебиане по умолчанию не установлен.Ну это проблемы окружения. Не установлен, значит, не будет использоваться. Никто не настаивает.
>>> Ну и что, что они не знают про
>>> перенаправление потоков ввода/вывода.
>>Что не так?
> У нас все студенты уже на 2 курсе знают про перенаправление ввода/вывода.Я пытался спросить, что такое вы нашли в коде, что это вызвало такое восклицание. Что знают все студенты, в данном случае не важно ;)
> После прочтения заголовка я ожидал что-то более интересное увидеть.
Ну да, нового глянцевого велосипеда не нашлось.
> Повышать привилегии с помощью sudo является нормальной практикой.Скорее "задуманным предназначением sudo", но имей в виду http://www.opennet.me/openforum/vsluhforumID3/73378.html#19
>> А вообще говоря, надо с корнем выдирать это ваше sudocmd отовсюду и
>> делать, как нормальные люди. Если команда требует прав рута, то надо
>> проверить это в самом начале и прекратить работу, если это не
> Почему вы считаете нормальным, что команда должна прекращать работу? :)Скорее ограничить список выполняемого до непривилегированных операций, насколько понимаю предложение. А вообще неявное повышение привилегий -- то, что может быть удобно тебе (который понимает происходящее при запуске), но IMHO не лучший пример.
>То, что вы описали, не является «гвоздями прибитым использованием».Приехали. А как по-вашему это называется? Вызов sudo прямо и недвусмысленно прописан в коде, и я никаким образом не могу на это повлиять. Ну разве что вручную редактировать все скрипты. Эта ситуация и называется "hardcoded", или "прибитое гвоздями".
>Повышать привилегии с помощью sudo является нормальной практикой.
Нет, не является. Попробуйте выполнить что-нибудь из перечисленного от простого пользователя:
touch /foo
mkdir /bar
mount /dev/sda1 /mnt/whatever
Ну и т.п. Если кто-нибудь из них попробует повысить свои привилегии с помощью sudo, обязательно нам сообщите.
(Правильный ответ: они все скажут "Permission denied" и закончат работу с ненулевым кодом возврата).>Удивились и исправили бы код. Проблема-то в чём?
В недальновидности и в нерасширяемости. Хотя, если вы не планируете поддерживать ту же соляру, то бог с ним.
>Пока предложенный огород не выглядит проще вызова редактора для /etc/apt/sources.list
Конечно огород с tee не проще, потому что вы сами себе усложнили жизнь с sudo.
>Суть нашего "решения" была в том, чтобы просто напомнить, где лежит список для данного ПМ.
Действительно, "решение". В одном месте все само пытается запуститься, в другом месте просто "напоминание" выдается. Такая неоднородность еще хуже, я считаю.
>Почему вы считаете нормальным, что команда должна прекращать работу? :)
Потому что программа не может с текущими правами выполнить данную операцию, лол. Вы усложняете то, что можно и нужно оставить простым.
>Ну это проблемы окружения. Не установлен, значит, не будет использоваться. Никто не настаивает.
Ой. Значит, я все-таки что-то пропустил. Покажите, пожалуйста, как можно вообще отключить использование sudo в вашей программе.
>Я пытался спросить, что такое вы нашли в коде, что это вызвало такое восклицание
Вышеупомянутый казус с sources.list.
>Ну да, нового глянцевого велосипеда не нашлось.
Зато нашлось новое глянцевое сиденье для него.
> ...
>>>> Чего только стоит гвоздями прибитое использование sudo везде
>>>Это не так.
>> В смысле "не так"? Я в исходниках везде вызов процедуры sudocmd видел,
>> которая проверяет, является ли пользователь рутом, и вызывает sudo, если нет.
>> Хотите сказать, мне померещилось?
> То, что вы описали, не является «гвоздями прибитым использованием». Повышать
> привилегии с помощью sudo является нормальной практикой."Я бы этому дяде с большими ушами уши-то пооткрутил"(С)
Если уж и делать подобное, то исключительно по запросу пользователя вроде
# uncomment the following if you want to...
# : ${EPMSUDO:=/usr/bin/sudo}На соляре, например, это pfexec
>> А вообще говоря, надо с корнем выдирать это ваше sudocmd отовсюду и
>> делать, как нормальные люди. Если команда требует прав рута, то надо
>> проверить это в самом начале и прекратить работу, если это не
> Почему вы считаете нормальным, что команда должна прекращать работу? :)Кому надо, сделает себе alias iepm=/usr/bin/sudo /usr/bin/iepm
>> ...
>>>>> Чего только стоит гвоздями прибитое использование sudo везде...
> Если уж и делать подобное, то исключительно по запросу пользователя вроде
> # uncomment the following if you want to...
> # : ${EPMSUDO:=/usr/bin/sudo}...
> Кому надо, сделает себе alias iepm=/usr/bin/sudo /usr/bin/iepmОбъясните, почему вы считаете, что пользователь, имеющий права через sudo запускать команды управления пакетами, должен явно разрешать возможность выполнять эти команды через sudo?
Заметьте, что вы предлагаете запускать с привилегиями root всю команду epm, в то время как она сама повышает привилегии (в рамках ограничений, наложенных в /etc/sudoers) только в случае необходимости.
> Объясните, почему вы считаете, что пользователь, имеющий права через sudo запускать команды
> управления пакетами, должен явно разрешать возможность выполнять эти команды через sudo?Не понимаю вопроса
> Заметьте, что вы предлагаете запускать с привилегиями root всю команду epm
Принято
>> Объясните, почему вы считаете, что пользователь, имеющий права через sudo запускать команды
>> управления пакетами, должен явно разрешать возможность выполнять эти команды через sudo?
> Не понимаю вопросаЯ не понимаю боязни того, что epm выполняет некоторые команды через sudo, учитывая то, что право пользователя повышать привилегии через sudo появляется не просто так, а целенаправленно ему предоставлено.
Существует множество примеров в разных системах, когда у пользователя запрашивают разрешение на повышение привилегий при попытке выполнить действие, требующее админских привилегий.
Отмечу, что sudo в системе по умолчанию может быть настроен так, что он будет спрашивать пароль пользователя при вызове sudo команда. Пользователю выводится команда, предлагаемая к выполнению.
>>> Объясните, почему вы считаете, что пользователь, имеющий права через sudo запускать команды
>>> управления пакетами, должен явно разрешать возможность выполнять эти команды через sudo?
>> Не понимаю вопроса
> Я не понимаю боязни того, что epm выполняет некоторые команды через sudo,
> учитывая то, что право пользователя повышать привилегии через sudo появляется не
> просто так, а целенаправленно ему предоставлено.Не то, чтобы я был категорически против или чего-то там боялся.
Это скорее ворчание по поводу дизайна, возможно, напрасное, вам виднее.
На мой субъективный взгляд sudo внутри скрипта -- это просто лишний
код с неочевидными преимуществами. Я бы довольствовался алиасами
и выбросил бы лишний код из системы даже не смотря на то,
что они повышают привилегии для всех вариантов аргументов, а не
только там, где надо. Код этот лишний по двух причинам: 1) алиасы, как я сказал,
достаточны, 2) развешивая sudo только в тех местах, где нужно вы
закладываетесь на особенности конкретных версий конкретных реализаций.
Ну вот адаптирую я, к примеру, apt для работы с пакетами в
непривилегированном режиме в доме или уберу из yum-а лишние хотелки
root-а где попало, зачем будет нужен ваш sudocmd код? Но, повторюсь, это минорное
замечание, просто мнение, решать вам.P.S. Надеюсь, по поводу переменной конфига замечание не забыто.
На Солярисе не принято размахивать sudo и root-ом. Там есть гораздо более
кошерное средство pfexec и весьма развесистая и гибка система управления
привилегиями пользователей. Отдайте это на откуп пользователям.
...
> что они повышают привилегии для всех вариантов аргументов, а не
> только там, где надо. Код этот лишний по двух причинам: 1) алиасы,
> как я сказал,
> достаточны, 2) развешивая sudo только в тех местах, где нужно вы
> закладываетесь на особенности конкретных версий конкретных реализаций.Можно договориться, что эти особенности всё же не меняются годами.
> Ну вот адаптирую я, к примеру, apt для работы с пакетами в
> непривилегированном режиме в доме или уберу из yum-а лишние хотелки
> root-а где попало, зачем будет нужен ваш sudocmd код?Это сферический конь. Ну и не думаю, что при таких изменениях кто-то допустит потерю совместимости.
> P.S. Надеюсь, по поводу переменной конфига замечание не забыто.
> На Солярисе не принято размахивать sudo и root-ом. Там есть гораздо болееДа, я думаю как это сделать, не добавляя конфига.
>> Ну вот адаптирую я, к примеру, apt для работы с пакетами в
>> непривилегированном режиме в доме или уберу из yum-а лишние хотелки
>> root-а где попало, зачем будет нужен ваш sudocmd код?
> Это сферический конь.Пусть конь, но смысла в sudo внутри скрипта все равно ноль.
Пока он маленький - это не проблема.>> P.S. Надеюсь, по поводу переменной конфига замечание не забыто.
>> На Солярисе не принято размахивать sudo и root-ом. Там есть гораздо более
> Да, я думаю как это сделать, не добавляя конфига.Переменной окружения, очевидно. EPMSUDO?
>>> Ну вот адаптирую я, к примеру, apt для работы с пакетами в
>>> непривилегированном режиме в доме или уберу из yum-а лишние хотелки
>>> root-а где попало, зачем будет нужен ваш sudocmd код?
>> Это сферический конь.
> Пусть конь, но смысла в sudo внутри скрипта все равно ноль.
> Пока он маленький - это не проблема.То, что позже стало называться EPM, было мною начато исключительно ради того,
чтобы вызывать команды с использованием sudo. Поэтому sudo в EPM является одной из важных его особенностей.>>> P.S. Надеюсь, по поводу переменной конфига замечание не забыто.
>>> На Солярисе не принято размахивать sudo и root-ом. Там есть гораздо более...
> Переменной окружения, очевидно. EPMSUDO?Добавил EPMNOSUDO для тех, кто не любит sudo :)
slackpkg)
docmd cat /etc/slackpkg/mirrorsНе надо так делать. Надо так, поверьте на слово:
docmd grep -v "^#\|^$" /etc/slackpkg/mirrors
Slackware64-14.0epm --show-command-only remove bla-bla
$ sudo removepkg bla-blaно
$ epm --show-command-only install bla-bla
installpkgПропало su/sudo, пропали параметры.
# Has a distro file the specified word?
has()
{
[ -n "$DISTROFILE" ] || exit 1
grep "$*" "$DISTROFILE" >/dev/null 2>&1
}elif distro slackware-version ; then
DISTRIB_ID="Slackware"
if has 10.2 ; then DISTRIB_RELEASE="10.2"
elif has 11 ; then DISTRIB_RELEASE="11"
elif has 11.1 ; then DISTRIB_RELEASE="11.1"
elif has 12 ; then DISTRIB_RELEASE="12"
fiУверены, что сможете когда-нибудь получить DISTRIB_RELEASE="11.1"?
К слову, его такого и не было в природе.
Имелось в виду что-то вроде:
elif distro slackware-version ; then
DISTRIB_ID="Slackware"
if has 10.2 ; then DISTRIB_RELEASE="10.2"
elif has 11.0 ; then DISTRIB_RELEASE="11.0"
elif has 12.0 ; then DISTRIB_RELEASE="12.0"
elif has 12.1 ; then DISTRIB_RELEASE="12.1"
elif has 12.2 ; then DISTRIB_RELEASE="12.2"
elif has 13.0 ; then DISTRIB_RELEASE="13.0"
elif has 13.1 ; then DISTRIB_RELEASE="13.1"
elif has 13.37 ; then DISTRIB_RELEASE="13.37"
elif has 14.0 ; then DISTRIB_RELEASE="14.0"
fi
? Тогда было достаточно:
elif distro slackware-version ; then
DISTRIB_ID="Slackware"
DISTRIB_RELEASE="$(grep -Eo [0-9]+\.[0-9]+ /etc/slackware-version)"
Slackware64-14.0Где-то явные ошибки:
1)
$ epm --show-command-only -q bla-bla
$ ls -1 /var/log/packages/
$ bla-bla
./epm-sh-functions: line 93: bla-bla: команда не найдена2)
$ epm --show-command-only -e bla-bla
$ sudo removepkg bla-bla
Password:Сказано же --show-command-only, какой Password: ?
3)
$ epm --show-command-only -s bla-bla
$ slackpkg search bla-bla
./epm-sh-functions: line 93: slackpkg: команда не найденаНе самый лучший вариант для поиска пакета в репозитории требовать прав root-а.
4)
$ epm -qf /etc/slackware-version
Error: Do not known query command for slackpkgslackpkg file-search file_name
grep -R file_name /var/log/packages -- среди установленных
Для поиска file_name с полным путём, следует "откусить" лидирующий "/".5)
$ epm -ql kernel-headers
Error: Do not known query command for slackpkgСодержимое файла /var/log/packages/fill-package-name начиная с ^FILE LIST:$
6)
$ epm --show-command-only -qi kernel-headers
$ slackpkg info kernel-headers
./epm-sh-functions: line 93: slackpkg: команда не найдена# ./epm --show-command-only -qi kernel-headers
# slackpkg info kernel-headersПрав рута для этого многовато. В отношении установленного пакета:
Содержимое файла /var/log/packages/fill-package-name до ^FILE LIST:$Как-то так...
ps. Там, где реально не требуются права рута, зовите slackpkg по полному пути /usr/sbin/sklackpkg. В Slackware /sbin:/usr/sbin включены в PATH root-а и отсутствуют у обычного пользователя.
> ps. Там, где реально не требуются права рута, зовите slackpkg по полному
> пути /usr/sbin/sklackpkg. В Slackware /sbin:/usr/sbin включены в PATH root-а и отсутствуют
> у обычного пользователя.Спасибо большое за замечания и предложения, всё внёс почти.
Единственное, --show-command-only реализована была только для install,
и молча игнорировалась для других команд. Сейчас реализовал также для remove,
и дописал в справку, для каких случаев она реализована.
Замечание по поводу:
http://git.etersoft.ru/projects/?p=korinf/eepm.git;a=commitd...
Было бы лучше выдавать пользователю предупреждение (в stderr) о неиспользовании лидируещего слеша при поиске по полному имени файла. Но убирать его принудительно -- не очень здравая идея. Дело вот в чём.
Список файлов, установленных из пакета, ПМ Slackware хранит в файле /var/log/packages/полное-имя-пакета ниже строки "FILE LIST:", при этом имена файлов и каталогов хранятся без корневого "/". То есть, "/usr/sbin/slackpkg" хранится как "usr/bin/slackpkg".
Если принудительно будете отрезать стартовый слэш в своем скрипте, пользователь не сможет поискать по части пути, например, по /bin/нечто вполне найдётся usr/bin/нечто и ожидаемо не найдётся sbin/нечто; а если стартовый слеш отрЕзать, то sbin/нечто найдётся.Возможно, если на наличие стартового "/" завязана какая-то внешняя логика, есть смысл проверять наличие искомого файла со стартовым слешем по полному пути, а при его отсутствии оставлять стартовый "/" на месте.
Кроме того, можно воспользоваться и "/usr/sbin/slackpkg file-search $@", раз он уже задействован в прочих местах.
> Возможно, если на наличие стартового "/" завязана какая-то внешняя логика, есть смысл
> проверять наличие искомого файла со стартовым слешем по полному пути, а
> при его отсутствии оставлять стартовый "/" на месте.Всё так, но не могли бы вы проверить, как это работает на практике. Дело в том, что сюда путь передаётся уже после readlink -f, то есть абсолютный путь к файлу.
> Кроме того, можно воспользоваться и "/usr/sbin/slackpkg file-search $@", раз он уже задействован
> в прочих местах.Он же ищет по всем пакетам, не только установленным? К нему будет обращение, если файл не найдётся в установленных пакетах, либо если явно вызывать поиск файлов по всем пакетам.
Спасибо за участие.
>> Возможно, если на наличие стартового "/" завязана какая-то внешняя логика,
>> ...
> Всё так, но не могли бы вы проверить, как это работает на практике. Дело в том, что сюда путь передаётся уже после readlink -f, то есть абсолютный путь к файлу.Хм.
$ epm -qf /usr/sbin/slackpkg
$ grep -R usr/sbin/slackpkg /var/log/packages
/var/log/packages/slackpkg-2.82.0-noarch-8:usr/sbin/slackpkgНо:
$ epm -qf usr/sbin/slackpkg
$ grep -R /var/log/packages
...если правильно путаю, выдаст сущую ахинею (все строки всех файлов в /var/log/packages).
>> Кроме того, можно воспользоваться и "/usr/sbin/slackpkg file-search $@"
> Он же ищет по всем пакетам, не только установленным?Да, по всем пакетам из репозитория, установленным или нет. Ок, если "epm -qf файл" -- это поиск по файлам установленных пакетов, то вариант с slackpkg может подойти только в варианте
/usr/sbin/slackpkg file-search $@ | grep -v "[uninstalled]"Ещё пара интересных моментов:
epm -i package-file
что должно произойти, если пакет предыдущей версии установлен?Если выполнить в этой ситуации
installpkg package-name--version_new-arch-build.tgz
пакет будет установлен, в /var/log/packages/package-name-version-arch-build будет записано всё, что полагалось, совпавшие по именам файлы нового пакета заменят файлы старого, в базе пакетного менеджера будет две записи о пакете package-name:
/var/log/packages/package-name-version_old-arch-build
/var/log/packages/package-name-version_new-arch-build
что, вполне объяснимо, но не вполне соответствует действительности с точки зрения содержания ФС после установки.Если в подобной ситуации нужно обновление, то практичнее использовать для установки вместо "installpkg package-file"
upgradepkg --install-new package-file
поведение: если не установлен, то установить; если установлен, то обновить. Осторожно: upgradepkg проверяет версии НЕ на больше/меньше, а на равно; если версии (включая сборку и тэг) одинаковы, пакет пропускается, если разные -- замена ранее установленного пакета будет произведена, даже если его версия "больше".ps. slackpkg -- сценарий на bash, там есть что по(д)смотреть.
pps. Вообще говоря, можно рассматривать несколько уровней:
1) pkgtools -- installpkg/upgradepkg/removepkg + поиски по /var/log/packages. Первые два работают только с файлами пакетов; removepkg работает с именами пакетов (полными и родовыми), даже если к ним прицеплен путь и расширение. Об автоматических зависимостях, сетевых репозиториях, сборке из исходников речи нет. Основной пакетный менеджер дистрибутива.
2) slackpkg -- работает как с локальными файлами (пользуется pkgtools), так и с одним репозиторием (сетевым или локальным). Автоматические зависимости и сборку из исходников не поддерживает. Входит в дистрибутив.
3) slapt-get -- работает как с локальными файлами (пользуется pkgtools), так и с несколькими сетевыми репозиториями. Автоматические зависимости поддерживает, если предоставлены репозиторием. Сборка из исходников -- довеском slapt-src. Не входят в дистрибутив.
4) sbopkg -- сборка из исходников, как правило из slackbuilds.org, актуализация ранее собранного. Автозависимости в зачаточном состоянии (посредством сборочных очередей). Не входит в дистрибутив.
ppps. Если желание пообщаться на тему Slackware применительно к epm (и не только) всё ещё имеется, полагаю уместным переместиться из обсуждения собственно новости куда-то в более профильное место, как варианты:
slackware.su/forum
slackware.ru/forum
unixforum.org/index.php?showforum=19
linuxforum.ru/viewforum.php?id=53
или куда-либо по вашему усмотрению.
http://lists.altlinux.org/pipermail/sisyphus-cybertalk/2012-...
Тут есть это дебильное разделение на -dev и НЕ -dev пакеты?
Да ни черта там нет. Пачка скриптов тупых.
>Пачка скриптов тупыхИ что?
И ни черта больше, написали же.
> И ни черта больше, написали же.- Вы бы вышли замуж за радикала?
- За ради чего?!?!
Кстати, еще один повод кинуть какашку в разработчиков. Не решается проблема с разными наименованиями пакетов. В RH-based файлы для разработки уже включены в пакет, а в дебиане надо ставить отдельный dev. Что делать в случае, если мне на всех машинах нужны dev-пакеты?Более простой для понимания пример: если мне надо установить, допустим, апач на 100500 разных машин, то в дебианах надо ставить пакет apache2, а в RH-based надо ставить httpd, емнип. Опять же, что делать в таком случае?
> Кстати, еще один повод кинуть какашку в разработчиков.Разве что если на большее пороху не хватило...
> Не решается проблема с разными наименованиями пакетов.
В принципе можно попытаться решать и её при помощи http://www.altlinux.org/Packaging_Automation/DistroMap -- но тогда придётся либо на каждый чих в сеть бегать, либо держать статическую базу, либо делать компромисс в виде локального кэша (и периодически наступать на то, что он устарел либо сама база неполна).
> В RH-based файлы для разработки уже включены в пакет
Надо же -- значит, мне померещился glibc-devel...
> а в дебиане надо ставить отдельный dev.
Дебиан именно в этом плане от шляпы отличается более тонкой нарезкой (и большей строгостью), но не принципом.
> Что делать в случае, если мне на всех машинах нужны dev-пакеты?
Ставить на всех машинах dev-пакеты, если придумать более здравый способ решения конечной задачи не получается (т.е. если это сплошные станции разработчиков или сборочные серверы). Руками или автоматикой, это уже смотря по количеству и разнобою хостов/пакетов.
> Более простой для понимания пример: если мне надо установить, допустим,
> апач на 100500 разных машин, то в дебианах надо ставить пакет apache2, а
> в RH-based надо ставить httpd, емнип. Опять же, что делать в
> таком случае?Как вариант -- сделать свои метапакеты с одинаковым названием, положить в свои репозитории и ставить их. Делать же так, чтоб для каждой целевой платформы вытаскивали по зависимостям то, что нужно, по тем именам, которые там приняты.
Минус -- дополнительная морока с пакетами и репозиториями (включая добавление на каждом хосте), но после этого особой возни не должно добавляться. Болванку rpm-спека можно взять, например, здесь (это моя для удобства, под себя придётся чуть обчистить): http://fly.osdn.org.ua/~mike/RPM/SPECS/_minimal.spec
>> Не решается проблема с разными наименованиями пакетов.
> В принципе можно попытаться решать и её при помощиЧто тут можно *в принципе* "пытаться решить", когда пакеты предоставляют принципиально разный функционал?
Софт патчат, бъют на разные пакеты или собирают с разными ключами. Путями конфигурационный файлов отличаются, наконец. Как и структурой оных...
Названия - только айсберг внутренних различий. Зачем "унифицировать" - чтобы больнее нос потом разбить?
> Как вариант -- сделать свои метапакеты с одинаковым названием, положить в свои
> репозитории и ставить их. Делать же так, чтоб для каждой
> целевой платформы вытаскивали по зависимостям то, что нужно, по тем именам,
> которые там приняты.Не лучше просто выбрать один конкретный дистрибутив?
нет чтоб просто написать шелл-скрипт с набором алиасов на все пакетные менеджеры, имитирующим наиболее привычный
Оне именно это и пытались сделать. Не ндравится? Запили свой, с шахматами и поэтессами. Обязательно кто-нить разыщет там Фатальный Недостаток. И Потоку велосипедов несть и не будет числа и далее....
GPL? рукопожимаю.
интересно как оно с emerge дружит :-D
> интересно как оно с emerge дружит :-DПинает, как ещё.
> Одной из проблем, возникающих из-за многообразия дистрибутивов Linux, является необходимость использования в каждом классе дистрибутивов собственного набора команд для управления пакетами. EPM является надстройкой над существующими пакетными менеджерами (apt, rpm, dpkg, urpm, pkg_add, emerge, pacman, yum, zypper, mpkg, slackpkg) и позволяет выполнять необходимые операции на любой платформе с помощью единого набора команд.Здравые рассуждения.
> Код написан на Shell и предельно прост для расширения и дополнения.и для тормозов наверное тоже ?
Может стоило замахнуться на свой собственный "мотовелик" с брызковиками и катафотками, чем писать "поверхностную прокладку".
>> Код написан на Shell и предельно прост для расширения и дополнения.
> и для тормозов наверное тоже ?С какого перепугу? Шелл бывает очень даже быстр, если не форкаться на каждый чих и не мотать в нём глубокие циклы. А тут ни задач особых, ни тем более данных...
PS re #101: зачем бы?
> PS re #101: зачем бы?Что бы было :-)
А зачем "чехол" ? Неужели есть столько пользователей или "одминов", которые часто устанавливают программы на системах с разными пакетными менеджерами ?
И уж если кто-то постоянно этим занимается, то ему по барабану писатьли ему yum или zipper.
Не видно очевидного и безусловного профита от огораживани этого огорода.
Из статьи не понятна килерфича, приведи пример юзкейса, где эта штука КРАЙНЕ необходима.
> приведи пример юзкейса, где эта штука КРАЙНЕ необходима.#75; не то чтобы крайне, но довольно-таки: скрипты сложнее учить особенностям дистрибутивов, если они отрабатывают извне среды, а внутри можно хоть на /etc/*-release с /etc/*_version посмотреть, хоть бинарники подёргать -- есть они или нет.
Вообще целеполагания в описании недостаёт, оно тут вовсе не самоочевидное.
>>> Код написан на Shell и предельно прост для расширения и дополнения.
>> и для тормозов наверное тоже ?
> С какого перепугу? Шелл бывает очень даже быстр, если не форкаться
> на каждый чих и не мотать в нём глубокие циклы.
> А тут ни задач особых, ни тем более данных...
> PS re #101: зачем бы?Майки, ты имеешь дело с потребителями и критиканами. Которые понятия не имеют, что такое шелл-программинг, более того, они даже прочитать скрипт не способны, не то, что написать хоть что-то сколько-нибудь сложное и при этом не адово тормозящее. Ты с кем разговариваешь тут, папочка?
> Ты с кем разговариваешьПредположительно с людьми, сталкивавшимся в основном с второсортными шелл-скриптами. Примеры первосортных можно поискать у Кернигана с Пайком или же в альтовских пакетах control, libshell (навскидку).
Полезность этого чуда весьма сомнительна. Сидел на системе с rpm перешел на систему с dpkg надо быстро ставить epm а то как же я там без привычных мне команд. “сарказм”На мой взгляд, если уж вам приходится работать в системе, в которой управление пакетами устроено иначе, то изучения этих различий лично для вас, как для специалиста лишнем не будет.
Еще бы проект который будет делать симлинки положения важный директорий и конфигов например для RHEL дистрибутивов в стиле Debian и наоборот. “сарказм”
> Сидел на системе с rpm перешел на
> систему с dpkg надо быстро ставить epm а то как же
> я там без привычных мне команд. “сарказм”
> На мой взгляд, если уж вам приходится работать в системе, в которой
> управление пакетами устроено иначе, то изучения этих различий лично для вас,
> как для специалиста лишнем не будет.А теперь представьте, что вы 10 раз на день переходите с системы на систему :)
Потом делаете паузу в 2 месяца, а потом опять работаете с 10-ю системами.
Вот вам будет интересно вспоминать, как в ArchLinux или FreeeBSD список установленных пакетов посмотреть.
> А теперь представьте, что вы 10 раз на день переходите с системы на систему :)В конце концов - это надоест и возникнет мысль минимизировать необходимость этого сомнительного "счастья". Т.е. кол-ва систем.
> Вот вам будет интересно вспоминать, как в ArchLinux или FreeeBSD список установленных
> пакетов посмотреть.По сравнению с остальной спецификой системы - это капля в море.
А вот скажите: гарантирует-ли этот интерфейс, к примеру, одинаковое поведение системы управления пакетами в системе? В debian есть dpkg -r, есть dpkg -P. Везде есть аналоги purge и remove? Везде их разница понимается именно так, как в debian?
install (и remove, соответственно) - могут по-разному работать с зависямостями (ср. apt-get install vs aptitude install; apt-get remove vs apt-get autoremove)
Не получится, что "унифицировать" удастся в итоге только поиск пакета, содержащего файл; вывод списка пакетов и т.п. совсем куцый общий функционал?
>> А теперь представьте, что вы 10 раз на день переходите с системы на систему :)
> В конце концов - это надоест и возникнет мысль минимизировать необходимость этого
> сомнительного "счастья". Т.е. кол-ва систем.Это было первым порывом. Но, знаете, не всегда в задаче можно минимизировать количество систем. А ведь иногда хочется и президента минимизировать. Это не важно. Вот есть люди, для которых это данность. И как-то глупо, когда они делятся средством, помогающим им в работе, советовать им поменять работу, а не пытаться что-то унифицировать.
> А вот скажите: гарантирует-ли этот интерфейс, к примеру, одинаковое поведение системы управления
> пакетами в системе? В debian есть dpkg -r, есть dpkg
> -P. Везде есть аналоги purge и remove? Везде их
> разница понимается именно так, как в debian?Мне не нравится, как это реализовано в dpkg... Но вопрос хороший. Интерфейс реализован с мыслью обеспечить одинаковое поведение. В меру возможностей.
> install (и remove, соответственно) - могут по-разному работать с зависямостями (ср. apt-get
> install vs aptitude install; apt-get remove vs apt-get autoremove)Мне казалось, что autoclean и autoremove не имеют параметров.
В данном случае, действия по удалению пакетов (remove) и удалению ставших ненужными пакетов связи не имеют и должны быть представлены разными командами.В общем же я придерживаюсь мнения, что для операций удаления и установки пакета достаточно двух команд. В некоторых системах любят сделать «неполное удаление», «полное удаление», «автоматическое удаление». Но это частные тонкости на любителя, на самом деле.
> Не получится, что "унифицировать" удастся в итоге только поиск пакета, содержащего файл;
> вывод списка пакетов и т.п. совсем куцый общий функционал?Всё, что было потребно унифицировать, уже сделано. Можно посмотреть, что получилось.
> И как-то глупо, когда они делятся средством, помогающим им в работе, советовать им поменять
> работу, а не пытаться что-то унифицировать.Можно предложить им готовые инструменты, которые другие используют в аналогичных случаях. Примеры выше были.
> Мне не нравится, как это реализовано в dpkg... Но вопрос хороший. Интерфейс
> реализован с мыслью обеспечить одинаковое поведение. В меру возможностей.Засаду чую я...
> Мне казалось, что autoclean и autoremove не имеют параметров.
Да, это я пожалуй, зря. Но смысл был в том - как будут обрабатываться установленные по зависимостям пакеты в разных системах при remove.
> В данном случае, действия по удалению пакетов (remove) и удалению ставших ненужными
> пакетов связи не имеют и должны быть представлены разными командами.В apt-get/aptitude - эти действия довольно таки совмещены. Пакет становится ненужным, если установлен по зависимости, а remove оную как раз удаляет. Как-то так.
> Всё, что было потребно унифицировать, уже сделано. Можно посмотреть, что получилось.
Что выросло, то выросло... :)
>[оверквотинг удален]
>> пакетов посмотреть.
> По сравнению с остальной спецификой системы - это капля в море.
> А вот скажите: гарантирует-ли этот интерфейс, к примеру, одинаковое поведение системы управления
> пакетами в системе? В debian есть dpkg -r, есть dpkg
> -P. Везде есть аналоги purge и remove? Везде их
> разница понимается именно так, как в debian?
> install (и remove, соответственно) - могут по-разному работать с зависямостями (ср. apt-get
> install vs aptitude install; apt-get remove vs apt-get autoremove)
> Не получится, что "унифицировать" удастся в итоге только поиск пакета, содержащего файл;
> вывод списка пакетов и т.п. совсем куцый общий функционал?Большего и не требуется. Лично меня 19 лет устраивал функционал pkgadd/pkgrm в Solaris. До автоматизма руки помнили, смена версий ничерта не ломала. Ровно до тех пор, пока рукосуи из Оракля не решили, что Linux-way им нравится больше.
Админ либо админит и ему хватамбо по принципу Оккама минималистического интерфейса, либо он игрок в CS на локалхосте и тогда ему надо десятипальцевый управлятор софтом и системой.
В общем-то, какое вам дело до того, как люди развлекаются? У человека есть редкая железяка, которая до сих пор не сломалась. Ему нравится NetBSD, есть знания и навыки. Взял, да сделал для себя полезную вещь ради развлечения. Вам от этого хуже стало?Конечно, во времена тотального потребленчества и обновления вещей ради их обновления, такое действие просто жутко бросается в глаза быдлу и небыдлу. "Смотрите, вот дурак! Нет чтобы подзаработать бабла, да купить себе новую видяху в компьютер, он фигнёй страдает - ни денег для себя не заработал, ни наш линупс лучше не сделал." В наше время уметь что-то сделать своей головой и руками считается просто пошлостью.
> В наше время уметь что-то сделать своей головой и руками считается просто пошлостью.Почему же. Если ты можешь сделать что-то качественное, совремненое и на уровне - велкам. А какашки мы называем какашками, независимо от того где оно made in. Зло, зато честно.
Мда... Ну и кто доверится надстройке этой когда можно почитать нужный ман и сделать все так как надо ? Не ракето-строение однако. А ведь его еще должны запихивать сразу в дистр иначе новым пользователям оно нафиг не сдасться.
предпочитаю yum из за близких нопок на клавиатуре (да мне лень вводить много текста!!) проще форуму в консоль вписать
> проще форуму в консоль вписатьДа, с кнопками у вас явно проблемы :)
apple keyboard mb110 английская
> предпочитаю yum из за близких нопок на клавиатуреСпециально для вас: можно запускать не epm, а upm. Там ссылка сделана.
apt, rpm, dpkg, urpm, pkg_add, emerge, pacman, yum, zypper, mpkg, slackpkg !!!!
Пысеццц еще теперь и EPMМот наконец то придти к чему то одному ???
>> Мот наконец то придти к чему то одному ???и красивое эргономичное название! ну и производительность
Поправьте наконец это жёлтое название :(
это как желтая пресса,
только название пакетного менеджера
> это как желтая пресса,
> только название пакетного менеджерану да, сердце бы согрела система управления пакетами исходных текстов с каким-никаким завалящим AI, занимающимся синтезом пакета иного применения из соотносимых структур, эмулирующий в отладке цикл жизнедеятельности программы лет на 80 вперед, внося патчи прямо в нулевой релиз, облачная и локальная ehehe-OS:)
> Поправьте наконец это жёлтое название :(Компания Etersoft разработала очередной универсальный пакетный менеджер ?
я просто оставлю это здесьhttp://git.etersoft.ru/projects/?p=korinf/eepm.git;a=blob;f=...
> я просто оставлю это здесьЗачем? Ну добавление репозиториев — непростая задача, пока толком не реализована. Что же такого?
Какой по счету это "универсальный пакетный менеджер"?
> Какой по счету это "универсальный пакетный менеджер"?Первый, не пытающийся думать за штатный пакетный менеджер.
>> Какой по счету это "универсальный пакетный менеджер"?
> Первый, не пытающийся думать за штатный пакетный менеджер.да ну. помнится, ещё в третьих кедах (если не раньше) были подобные попытки. kpackage, что ли (ну, не силён я в кедах, но). оно там пыталось рисовать универсальное GUI для разных пакетных систем. ну, и закономерно сыграло в ящик.
>>> Какой по счету это "универсальный пакетный менеджер"?
>> Первый, не пытающийся думать за штатный пакетный менеджер.
> да ну. помнится, ещё в третьих кедах (если не раньше) были подобные
> попытки. kpackage, что ли (ну, не силён я в кедах, но).
> оно там пыталось рисовать универсальное GUI для разных пакетных систем. ну,
> и закономерно сыграло в ящик.Ну как же, вот PackageKit вполне процветает.
Есть большая разница между kpackage для кед, и консолькой командой на шелле. У них разное предназначение и разные ценители.
И в чём закономерность «в ящик», вы не прояснили.
> Ну как же, вот PackageKit вполне процветает.зацветает. плесенью. фи.
> Есть большая разница между kpackage для кед, и консолькой командой на шелле.
угу: у одного есть окошки, а у другого нет. разница огромная.
> И в чём закономерность «в ящик», вы не прояснили.
а это тут уже говорили. и спрашивали, кстати. подобный «унификатор» — примерно то же самое, что и небольшой набор алиасов, только с понтами. для действительно «прозрачного» унификатора надо заводить огромную базу соответствий пакетов. потому что какой толк в «унификации», для которой всё равно надо помнить, как называются нужные пакеты в некоем дистрибутиве? найти нужный пакет — вот это проблема. а глянуть ключи для очередного пакетного менеджера — ерунда, право слово. вот если бы я мог сказать, к примеру:
super-package-manager install sdl sdl-dev
и оно таки работало бы на слаке, дебиане, мандриве, генту, etc — поняло бы, что я хочу поставить, как это сделать в конктретной системе… вот это было бы круто и полезно. а очередная обёртка — это из разряда: «я админ, у меня есть крутой набор алиасов. назову его 'универсальный пакетный менеджер' и толкану в народ, вот круто-то будет!»
не то, чтобы совсем уж бесполезно, но как-то много шумихи вокруг совершенно обычной вещи.
...
> для действительно «прозрачного» унификатора надо заводить огромную базу соответствий
> пакетов. потому что какой толк в «унификации», для которой всё равно
> надо помнить, как называются нужные пакеты в некоем дистрибутиве? найти нужныйВы хотите сказать, что помните, как называются нужные пакеты в вашем любимом дистрибутиве? Я вот не помню, и в общем лучае пользуюсь поиском.
> пакет — вот это проблема. а глянуть ключи для очередного пакетного
> менеджера — ерунда, право слово. вот если бы я мог сказать,
> к примеру:
> super-package-manager install sdl sdl-dev
> и оно таки работало бы на слаке, дебиане, мандриве, генту, etc —Это будет в следующей мажорной версии.
...
> не то, чтобы совсем уж бесполезно, но как-то много шумихи вокруг совершенно
> обычной вещи.Ну шумиху подняли те, кто обсуждали, а не те, кто толкали :)
> Вы хотите сказать, что помните, как называются нужные пакеты в вашем любимом
> дистрибутиве? Я вот не помню, и в общем лучае пользуюсь поиском.мне достаточно очевидно, что для получения в системе SDL и её заголовков в *универсальном* менеджере достаточно сказать sdl и sdl-dev. вообще, «название» и «название-dev». на что менеджер должен или молча поставить, или вывалить мне вопрос: «хозяин, тут неоднозначность. не томи, уточни.»
> Это будет в следующей мажорной версии.было бы неплохо. успехов — без сарказма.
> Ну шумиху подняли те, кто обсуждали, а не те, кто толкали :)
«шумиха» — это уже сам по себе анонс. имо, со «следующей мажорной версии» и стоило анонсировать. ну, и предпринять какие-то меры, чтобы не анонсировали другие — хотя бы в виде предупреждения где-нибудь в ридми: «это экспериментальная и недопиленая штука, НЕ СОРИТЕ НА САЙТАХ НОВОСТЕЙ ПОКА». как-то так. мне кажется.
А как по мне, так делать универсальный пакетный менеджер, тоже самое, что делать супер программу из кучи эмуляторов, чтобы все программы из разных систем запускались в Linux одним нажатием клика. Это такая же плная шизофрения.
> А как по мне, так делать универсальный пакетный менеджер, тоже самое, чтоА если «делать» заменить на «сделать»?
> делать супер программу из кучи эмуляторов, чтобы все программы из разных
> систем запускались в Linux одним нажатием клика. Это такая же плная
> шизофрения.Вам не нравится Qubes OS?
http://www.computerra.ru/619160/
Разговор совсем о другом шёл.
Какой амбициозный ребенок родился! Папашу - rxsetup, не удалось задушить, пока он был маленький, и нате вам.
Кто там про галиматью на шеле ругался пару лет назад, ась?
Смайлик забыл, вот такой - ;)
достали надстройки над надстройками над надстройками...
Наши люди всегда славились разработкой костылей.
Кто больше всего в мире написал командеров? Догадайтесь-ка :)
Нормальная задумка. Если действительно работать с несколькими системами..
И в своих вспомогательных скриптах (которые обычно всё-равно существуют,
лучшие "для себя любимого").. станет гораздо удобнее.С использованием epm (или как там он теперь) мне надо будет ломать
голову самому.. что там в каком дистре мне надо в своём скрипте подкрутить
(например развёртыванию(deploy) очередного обновления... которое админю).Вообщем... я не понял нападок.. из серии "это дрянь, потому-что мне не надо".
Не надо не используй.. А приживётся - ну и отлично.
P.S. git тоже был вроде как "велосипед"... а теперь где его только нет..
>> мне надо в своём скрипте подкрутитьв смысле НЕ надо // опечаточка.. :)
пора вводить тэг «927».