Планы по кросс-форматному пакетному API в LSB

Лучшая система управления пакетами - /dev/hands + /dev/brain. ./configure && make && checkinstall + installpkg тоже не помешают

Все остальное от лукавого, и не UNIX WAY ))

вот это - ДЕЛО!

apt is the best

>dpkg и yum стали нормой А с каких пор это синонимы?

фоннатег

это не синонимы. просто стандарты в том или ином дистрибутиве.

>dpkg и yum стали нормой

Это, видимо, ошибка --- apt и yum стали нормой. А то получается сравнение тёплого с мягким. Да и dpkg стало нормой только в Debian, где он и был нормой :) Рекурсия :)

>dpkg стало нормой только в Debian

Если учесть количество debian-based дистров, то dpkg ненамного менее распостранён, чем rpm.

emerge все равно никуда не денется. Как прикрутить поверх него API не представляю и не вижу необходимости, помоему все и так достаточно удобно. Только новые костыли сделают, которые опять же будут не во всех дистрибутивах.

Это здорово!!! Хорошая новость!!!

Мердок атец!

Если всё таки этот API засунут в LSB, и если в генте его (API) не прикрутят к emerge, то она (гента) не будет стандартизована LSB <какая-то версия>... :-P

>>значительно _упрастилась_

Исправьте что-ли...

Интересно, Shaman007 так проверяет, или специально закладки подобные лепит --- ни одной новости без ошибок. Кто-нибудь, подарите ему spell-checker [[;

> Лучшая система управления пакетами - /dev/hands + /dev/brain.

> ./configure && make && checkinstall

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

> apt is the best

Нет такого пакетного менеджера.

> emerge все равно никуда не денется. Как прикрутить поверх него API не представляю и не вижу необходимости, помоему все и так достаточно удобно. Только новые костыли сделают, которые опять же будут не во всех дистрибутивах.

Такой API нужен корпорациям для продвижения своих продуктов в массы Linux-юзеров, потому что это упростит установку проприетарного софта. Коммерческие софтостроители давно ориентируются на RedHat, Suse, Fedora, Ubuntu, Debian. Gentoo их не особо интересует, т.к. им известен цвет глаз основной массы пользователей Генты, которые софт покупать всё равно не будут. Так что поддержки вышеперечисленных вполне достаточно, чтобы обеспечить удобной инсталляцией большинство своих потенциальных клиентов.

>> apt is the best > Нет такого пакетного менеджера.

"Advanced Packaging Tool, or APT, is a package management system used by Debian GNU/Linux and its derivatives."

> "What the standard will do is enable the installer at specific points in the script to call out to the package system," Murdock says. "Instead of having to have specific knowledge about specific distributions, ISVs can simply rely on the LSB and the interfaces that the LSB will have present." All that ISVs will need to know is whether a distribution is LSB compliant or not.

Замечательно! Если сейчас всякое левое барахло с собственными инсталляторами отправляется в /usr/local, то по этому стандарту, оно спросит у менеджера пакетов пути и засрёт /usr. Винда forever!

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

>пучок вытекает..

:D

Только это и есть true. Система управления пакетами в слакваре самая лучшая, удобная и понятная. Но если думать непривычно, то, конечно, да, юзайте rpm.

Мне вот всё-таки интересно. Основных пакетных систем - 2 штуки: rpm и dpkg. Допустим, некая фирма портировала свой продукт под линукс, потратив на это некоторое количество средств и времени.

Вот у них уже есть продукт в бинарном виде. Они уже знают, от каких либ зависит их продукт (они ж его смогли собрать в итоге?).

Неужели после всей проделанной работы они не осилят простой процесс создания rpm/deb пакета?

Зачем для них изобретать ещё один велосипед?

> Замечательно! Если сейчас всякое левое барахло с собственными инсталляторами отправляется в /usr/local, то по этому стандарту, оно спросит у менеджера пакетов пути и засрёт /usr. Винда forever!

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

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

Истинно говорю вам - рано или поздно мы все придём к Патрегоугодному .tgz или гентушным ебмлдам.

А почему собственно другие софтины имеют право "засирать" /usr, а эта нет? Если она умеет прибрать за собой - то сколько угодно!

кхм... или арчевским .pkg.tar.gz

>Gentoo их не особо интересует, т.к. им известен цвет глаз основной массы пользователей Генты, которые софт покупать всё равно не будут.

т.е. по твоему софт покупают только красноглазики? да тебе в кащенку пора

> Замечательно! Если сейчас всякое левое барахло с собственными
> инсталляторами отправляется в /usr/local, то по этому стандарту, оно
> спросит у менеджера пакетов пути и засрёт /usr.

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

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

>Неужели так тяжело сделать мета-систему описания пакетов, которая из одного описания автоматически генерит пакеты под кучу дистрибутивов

alien ?

>Вот у них уже есть продукт в бинарном виде. Они уже знают, от каких либ зависит их продукт (они ж его смогли собрать в итоге?). >Неужели после всей проделанной работы они не осилят простой процесс создания rpm/deb пакета? >Зачем для них изобретать ещё один велосипед?

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

> А почему собственно другие софтины имеют право "засирать" /usr, а эта нет?

Другие софтины тоже не имеют права. Есть лишь одна софтина, которая имеет право это делать --- пакетный менеджер.

> Если она умеет прибрать за собой - то сколько угодно!

Вот именно, "если". Когда я ставлю любой пакет из дистрибутива, у меня не возникает никаких "если" --- всё ставится и удаляется одним и тем же пакетным менеджером, который уже много лет исправно пашет. А тут какая-то third party приблуда с кучей "если".

> alien ?

Я имел в виду несколько иное. Murdok в блоге (ссылка в статье) говорит о какой-то мифической "ecosystem" third party софта. В случае какого-то ублюдочного API, никакой "ecosystem" никогда не будет (см. Винды). Чтобы была "ecosystem", нужны взаимосвязанные third party репозитарии. Как пример --- third party софтине Foo нужен Adobe Flash (который тоже third party). То, что предлагает Murdok перестает работать так, как привыкли _пользователи_Linux_ и начинается геморрой, к которому привыкли _пользователи_Windows_.

В случае нормальной системы генерации пакетов (а может даже, сразу и репозитариев) из единого источника, есть репозитарий Foo, есть репозитарий Adobe, где есть Flash. Всё ставится _и_автоматически_обновляется_средствами_системы_. Задача, которую нужно решить --- добавление репозитария[ев] и установка в два клика, как описал Murdok: клик --- скачал файл на десктоп, клик --- поставил. При этом, затраты на пакетирование для third party --- минимальны.

ну и брЭд... нормальному человеку наплевать, чем пользоваться, yum-ом или apt-ом. нах ещё какой-то API сцаный?

> нормальному человеку наплевать, чем пользоваться, yum-ом или apt-ом. нах ещё какой-то API сцаный?

Это не для людей, это для разработчиков :)

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

>Gentoo их не особо интересует, т.к. им известен цвет глаз основной массы пользователей Генты, которые софт покупать всё равно не будут.

так им такой софт и не нужен, они "ждут ебилдов" :)

>В случае нормальной системы генерации пакетов (а может даже, сразу и репозитариев) из единого источника, есть репозитарий Foo, есть репозитарий Adobe, где есть Flash. Всё ставится _и_автоматически_обновляется_средствами_системы_

В таком случае понадобится система обмена информацией между репозитариями как минимум. Это обеспечить еще сложнее чем в совместимость пакетов из разных репозитариев в рамках одной системы. Просто перегенерация пакета из одной системы пакетирования в другую этого само собой не обеспечивает. ImHO для такой глобальной системы нужно ну как минимум уйти от системы _жестких_ зависимостей но по любому это не гарантирует что пакет из репозитария А встанет на систему, родным для которой является репозитарий Б. ImHO такое API это попытка "построить" репозитарии основных коммерческих "в шеренгу по 2". Как там поживает предыдущая попытка подобного "построения" всея и всех под названием "United Linux" ;) ?

> и какие же проблемы из этого вытекают?

Эти проблемы уже обсосаны 1e6 раз.

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

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

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

> понадобится система обмена информацией между репозитариями как минимум

М-м-м... Какой информацией? Допустим, у Adobe есть аптовый репозитарий для debian/ubuntu: http://adobe.com/debian, там раздается пакет adobe-flashplayer (adobe-flashplayer_9.0_i386.deb). Что мне, как разработчику Foo, еще нужно?

1. Собственный репозитарий http://foo.com/debian, где лежит пакет foo-fooprogram (foo-fooprogram_1.0_i386.deb) с зависимостью на adobe-flashplayer (>=9.0).

2. Некоторый механизм, который позволит пользователю скачать один файл, кликнуть на него, получить в списке репозитариев http://foo.com/debian и http://adobe.com/debian и установить пакет foo-fooprogram _средствами_стандартного_менеджера_пакетов_.

Какой еще информацией я должен обменяться с Adobe?

>Все остальное от лукавого, и не UNIX WAY ))

В каком месте это не unix way?

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

Что такое "родной репозитарий"? Из предыдущего примера: Adobe раздает Flash Player, по стандарту LSB об именовании пакетов, она должна предварять имена пакетов доменным имененм или именем, зарегистрированным в LANANA, например: adobe.com-flashplayer. Это референсное имя. Его будут прописывать в зависимостях. Этот пакет раздается с сайта Adobe в binary-only виде. Это значит, что нет сотни репозитариев с сотней разных сборок, значит нет конфликтов. Если еще в одном репозитарии заваляется пакет adobe.com-flashplayer, то это тот же самый пакет от Adobe.

Могут возникнуть "пересборки" пакетов, например исправления ошибок пакетирования от дистрибутивной команды. На этот случай есть всевозможные Provides:, Conflicts:, приоритеты репозитариев и прочие средства. Они, конечно, далеки от совершенства, но именно потому, что нет массового использования.

Всё можно конечно... Gentoo шная систему можно ко всему прикрутить... но блин, что тут не так... будут косяки и траблы.

>Вот именно, "если". Когда я ставлю любой пакет из дистрибутива, у меня не возникает никаких "если" --- всё ставится и удаляется одним и тем же пакетным менеджером, который уже много лет исправно пашет.

Не знаю чего вы тут фантазируете но yast отлично ставит левые rpmы и показывает их в своем менеджере и рулит ими.

>Из предыдущего примера: Adobe раздает Flash Player, по стандарту LSB об именовании пакетов, она должна предварять имена пакетов доменным имененм или именем, зарегистрированным в LANANA, например: adobe.com-flashplayer. Это референсное имя. Его будут прописывать в зависимостях. Этот пакет раздается с сайта Adobe в binary-only виде. Это значит, что нет сотни репозитариев с сотней разных сборок, значит нет конфликтов. Если еще в одном репозитарии заваляется пакет adobe.com-flashplayer, то это тот же самый пакет от Adobe.

Да статиком проще тогда будет собрать если чем разрешать зависимости из вендорского репозитария ;)

> с чего это вдруг ? будет ставиться туда куда и раньше хотело - в /usr/local ли в /opt ли или еще куда

VMWare, например, по-умолчанию хочет с префиксом /usr. Хорошо, что позволяется заменить на /usr/local. А по этому стандарту, VMWare спросит, "куда ставить бинари?", ей скажут: /usr/bin и вуаля! Хорошо, если админу системы дадут возможность настраивать то, что будет выдавать это API.

> просто теперь ты будешь видеть этот пакет в своем пакетном менеджере

Это не всё, что мне нужно. Например, я сохраняю в бэкапе список установленных пакетов. На случай, если винт отправится навестить предков. Сейчас, полноценное восстановление системы --- дело минут. При наличии псевдопакетов, которые неоткуда ставить --- п...ц a la Windows. 58 программулин, устанавливаем врукопашную.

> (возможно даже сносить и апдейтить через него)

А как оно будет взаимодействовать с пакетным менеджером при апдейте, если нет пакетов? Пример: есть софтина A-1.0 и B-1.0, зависящая от A-1.0. Выпущена версия A-2.0, про которую известно, что она конфликтует с B-1.0. Мне нельзя обновлять A до 2.0, пока не выйдет очередная версия B, не конфликтующая с A-2.0. Сейчас это в зависимостях можно прописать и никаких более телодвижений и API не нужно --- менеджер пакетов сам разберется.

> оно научится удовлетворять свои зависимости через этот пакетный менеджер

А удовлетворять чужие зависимости?

> главное чтоб родные файлы не затирало

Это отдельная песня.

>Другие софтины тоже не имеют права. Есть лишь одна софтина, которая имеет право это делать --- пакетный менеджер.

Так оно и будет через него ставиться! Или я чего-то не понял?

>yast отлично ставит левые rpmы и показывает их в своем менеджере и рулит ими.

А что будет если в зависимостях версия glibc в "левом RPM" не совпадёт с вашей текущей установленой ;) ?

> yast отлично ставит левые rpmы и показывает их в своем менеджере и рулит ими.

Речь о том, что не будет RPM'ов, вместо RPM'а --- инсталлер (как привыкли в Винде) и API (как в Винде --- можно спросить где Program Files, куда ярлыки для десктопа сваливать). И yast'у будет нечем рулить. Точнее, будет --- через API установочным скриптом будет создаваться запись о пакете, которого нет и никогда не было. Т.е. yast превратится в API для Control Panel->Add/Remove Programs, правда чуть более навороченное.

>Речь о том, что не будет RPM'ов, вместо RPM'а --- инсталлер (как привыкли в Винде) и API (как в Винде --- можно спросить где Program Files, куда ярлыки для десктопа сваливать). И yast'у будет нечем рулить. Точнее, будет --- через API установочным скриптом будет создаваться запись о пакете, которого нет и никогда не было. Т.е. yast превратится в API для Control Panel->Add/Remove Programs, правда чуть более навороченное.

Да такой "инсталлер" можно прямо сейчас из alien + собственно пакета (в любом, понимаемом) и скриптовой обвязки написать ;) толку только от него будет ровно как от alien-а ;)

>А по этому стандарту, VMWare спросит, "куда ставить бинари?", ей скажут: /usr/bin и вуаля!

Ты какой-то странный. Во первых с чего ты взял что он скажет /usr/bin а не /usr/local/bin? Во вторых если твой дистрибутив все время так говорит - какие претензии к стистеме? Так сделали дистрибутив.

> При наличии псевдопакетов, которые неоткуда ставить --- п...ц a la Windows. 58 программулин, устанавливаем врукопашную.

А что скинуть на отдельный носитель доставляемый недистровые пакеты религия не позволяет? То есть свой addon cd сделать? ДЕшево быстро просто и сердито. Если захочется можно даже в формате репозитария зафигачить.

>Сейчас это в зависимостях можно прописать и никаких более телодвижений и API не нужно --- менеджер пакетов сам разберется.

Так все и останется. Не понимаю с чего паника.

>yast превратится в API для Control Panel->Add/Remove Programs, правда чуть более навороченное

Не "чуть более навороченное", а умеющее управлять софтом и зависимостями, запускать pre- и postinstall скрипты, то есть такое API, какое и должно быть, и нечего его сравнивать с виндовым недоразумением.

>Не понимаю с чего паника.

Из религиозных соображений. Хотят сделать "как в винде", понимаете ли.