Представлен (http://permalink.gmane.org/gmane.comp.db.postgresql.announce...) PGXN Client 1.0 (http://pgxnclient.projects.postgresql.org/), первый релиз клиентского приложения, предназначенного для автоматизации поиска, загрузки, сборки, установки и удаления дополнений для СУБД PostgreSQL, представленных в архиве PGXN (http://pgxn.org/) (PostgreSQL Extension Network). Например, для установки определённого дополнения на сервер достаточно выполнить "pgxn install дополнение", а для загрузки дополнения только для одной БД - "pgxn load -d БД дополнение".
В рамках проекта PGXN развивается напоминающий CPAN архив для распространения дополнений к СУБД PostgreSQL, включая реализацию инфраструктуры для загрузки и распространения дополнений, подготовку централизованного индекса и API для доступа к мета-данным, создание системы поиска дополнений и набора утилит для тестирования дополнений. В настоящий момент в архиве представлено 57 дополнений и 105 релизов.
Среди полезных дополнений:...URL: http://permalink.gmane.org/gmane.comp.db.postgresql.announce...
Новость: http://www.opennet.me/opennews/art.shtml?num=32407
Мне одному кажется, что от этой штуки припахивает технологиями генты?
От этой штуки попахивает технологиями СПО. "Однажды лебедь раком щуку...."
> От этой штуки попахивает технологиями СПО. "Однажды лебедь раком щуку...."Однажды лебедь раком щуку? Больше похоже на технологии Apple :)
> От этой штуки попахивает технологиями СПО.Вы про NIH-синдром?)
> От этой штуки попахивает технологиями СПО.Поставить нужное расширение за одну команду, вместо того, чтобы полдня искать его по интернету (просматривая кучу баннеров и долго ожидая начала скачивания), а потом еще полдня искать кряк к нему.
> "Однажды лебедь раком щуку...."
Это к яблочникам, они по этой части мастера.
CTAN (1992) и CPAN (1995) появился когда генты ещё небыло.
Блин не хватало возни с CPAN, PEAR, Ruby Gem, теперь ещё это.
А в чем проблемы-то?
> А в чем проблемы-то?Слишком удобно. Гемора мало. С точки зрения вин-админов - не Ъ.
> А в чем проблемы-то?В том что есть вот у меня системный манагер пакетов. Нет, надо еще в пяти местах свои самопальные припереть, как в винде.
Это проблемы Вашего дистрибутива и его майнтейнеров.В Debian например есть почти автоматический скрипт делающий из модуля CPAN пакет, есть уже готовые такие пакеты поддерживаемые в рамках репозитория пакетов Debian. То же самое будет и с PGXN.
> В том что есть вот у меня системный манагер пакетов.Вот ты и запили ОС-независимый плагин под свой ситемный манагер пакетов и протолкни в репо дистра ;)
> В том что есть вот у меня системный манагер пакетов.Так прям разработчики плагинов для постгреса/руби/перла/теха/похапе/etc и побежали упаковывать свои модули в десятки форматов пакетов и проталкивать их в штатные репы 100500 дистров, ага.
Гораздо проще, если у каждого проекта будет свой репозитарий со своим внутренним форматом, а у каждого заинтересованного дистра - скрипты-конверторы в свой родной формат пакетов.
Надоели уже все эти самопальные подобия нормального пакетного менеджера.
> Надоели уже все эти самопальные подобия нормального пакетного менеджера.Который из них ты называешь "нормальным"?
apt-get OR aptitude OR yum OR yast OR emerge OR pacman? и почему именно этот?Есть СУБД (как и любые большие приложения), которая по сути ОС-независимая, у нее система плагинов. Плагины ставятся специфическим для приложения (СУБД) способом, но не зависят от ОС.
Вопрос - нахрена производителям БД-плагинов заколупывать установку плагинов под КАЖДУЮ поддерживаемую ОС если можно сделать одну сборку для всех?
>Который из них ты называешь "нормальным"?
>apt-get OR aptitude OR yum OR yast OR emerge OR pacman? и почему именно этот?slackpkg же. Патамучто Слака. :)
Можно было бы emerde (emerge для слаки), да он как свое название.
> Есть СУБД (как и любые большие приложения), которая по сути ОС-независимая,Угу. Поэтому надо еще и операционку свою припереть. А то вдруг моя операционка неправильная. Ну пакетный менеджер же может быть неправильным. Значит и операционка целиком - тоже.
Под critical приложения ставят СУБД и под нее подбирают наиболее подходящую ОС. Вряд ли это для вас секрет ;)
критикал приложения обычно в критикал бизнесе, в остальном все вольные художники. Нет ничего плохого втом, что скажем, СУБД поработала на фряхе, а потом переехала на центос или наоборот, поскольку таргет платформа вырвалась в илдеры по ряду ключевых параметров (тут каждому своё). И вот выясняется, что при перезде "отвалился" сервис, хотя в остальном ожидаемый профит получен. В идеальном вакууме, в идеальной сферической системе, очевидно должен быть протокол управления зависимостями програмных модулей от ядра до софта самого последнего уровня. Как только софт оторвался от бинарного компилера, всё, он "живёт" в своей среде, и ему наплевать, например, на то что на целевой платформе парсер XML (к примеру) не "той" версии. И вроде всё работает, да как то не так... Что уж говорить про критикал СУБД на критикал платформах.высказался, извиняйте, что сильно отвлёк.
> критикал приложения обычно в критикал бизнесе, в остальном все вольные художники. Нет
> ничего плохого втом, что скажем, СУБД поработала на фряхе, а потом
> переехала на центос или наоборот, поскольку таргет платформа вырвалась в илдеры
> по ряду ключевых параметров (тут каждому своё). И вот выясняется, что
> при перезде "отвалился" сервис, хотя в остальном ожидаемый профит получен.Это косяк архитектора и project manager, что не проверили рабоче-способность софта на таргет платформе И не учли эту проблему при risk-management И перенесли продакшен не взирая на подобную возможность.
У нас все проще. Стоимость проекта намного больше лицензий на ОС и СУБД, потому не особо запариваясь покупается RHEL и Oracle. опять же есть тренированные шаманы (админы) и по RHEL и по Oracle (DBA). Так что перенос на что-то альтернативное типа PostgreSQL или FreeBSD конечно возможен, но только в том случае, если связка RHEL+Oracle по какой то причине не может обеспечить требуемый функционал.
PS цена PostgreSQL & FreeBSD отнють не ноль - нужно переучивать людей и нужно какое то время на понимание как система ведет себя под нагрузкой и как ее заводить. Почему то IT-шники это забывают ;)
> Надоели уже все эти самопальные подобия нормального пакетного менеджера.Репозитарии с автоматизированной установкой, с точки зрения интеграции со штатным пакетным менеджером, гораздо проще и удобнее, чем раскиданные по сайтам разработчиков тарболы произвольной структурой с километровыми и откровенно наркоманскими INSTALL.
Вон в дебиане уже давно работают автоматические преобразователи пакетов CPAN и CTAN в deb.