вот dpkg - не суксь ли?

>вот dpkg - не суксь ли?

нет.

Надо в Oracle хранить.

Кто мешает написать свой вариант?

> Надо в Oracle хранить.

На оракел риал-мазафакин кластерс для вящей надёжности.

суксь. и aptitude по тем же причинам. сам пользуюсь и плююсь.

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

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

в каких бинарных дистрибах с правильным пакетным менеджером(если он есть) есть аналог aptitude с навороченным expression based поиском, но только быстрый?

кстати вы уверены что dpkg и aptitude не индексируют этот список, храня на диске кеш ?

Ахха, а давайте тогда уж вообще ВСЮ конфигурационую информцию хранить в каком-нить сетевом реляционном субд. Весь /etc туда засунем, весь гномовский и кде-шный конфиг итд. Интырпрайз в каждый дом. Дабы можно было прозрачно все это масштабировать по всем направлениям, и централизовано всем управлять. Кайфу будет шописец, да и понты немерянные!!!!

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

А при чем здесь ноуты?? Вполне себе успешно стоит ubuntu на нем родимом. Никаких особых неудобств по сравнению с обычной машиной не замечено;)

Да-да, давайте сделаем так, чтобы базовая система зависела от sqlite, а лучше - от oracle. :) И чтоб руками хрен туда залезешь. :)

Невкайф ему ждать. :) Каждые три минуты новые пакеты что ли ставишь? :)

это всё (страх перед не возможностью залезть руками) потому что вам (линуксойдам) нанесена травма. когда винда полетела вы не могли поправить реестр из вне, отсюда ощущение отсутствия контроля... поэтому вы ломанулись к полной противоположности навороченных систем хранения данных - к текстовому формату. эта проблема решается просто - программа и библиотека которая редактирует эти данные пишется на с и портируется на всё что можно.(чтобы можно было починить откуда угодно) она должна работать в консольно-запросном, тексто-режимо-графическом (типа aptitude), и GUI режиме. к каждой записи прикрепляется ид того что ёё создало, что бы можно было удалить мусор от засоряющего говном софта. разделение на части (файлы) и RCS-подобный дифф мирджинг. версионность или снапшоты(инкрементный copy on write) и монтирование отдельных хранилищ(файлов).

> Да-да, давайте сделаем так, чтобы базовая система зависела от sqlite, а лучше - от oracle. :)

Ну, если бы оракл был свободным ПО...

сарказм, сарказмом, но те же пароли хранятся как в plain file /etc/{,master.}passwd, так и в Berkeley DB /etc/{,s}pwd.db -- в результате и скорость и `ридабельность' т.ч. дуализм рулит

Пароли в /etc/passwd не хранятся.

dpkg используется и в embedded девайсах, где бывает неприемлемо тащить еще sqlite.

и еще openembedded.org использует monotone для контроля версий пакетов, которая юзает sqlite. Так вот (сюрприз!) она еще потормозней portage будет.

Лучше хранить базу на выделенном SQL сервере (Oracle разумеется) под системой энтерпрайз уровня типа Solaris

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

а что все на реляцонных базах зациклились ? спецализированные хранилища рулят !

> Невкайф ему ждать. :) Каждые три минуты новые пакеты что ли ставишь? :)

Вот мне тоже интересно. Ну раз в 2 недели (максимум) что-то поставить, ну, обновиться раз в месяц... Это так напряжно?..

Точно! Берём сановскую или бимеровскую data storage, ну там десяток блоков, горячая замена, бесперебойная работа в течение суток... Чего мелочиться-то?

Зачем же на C? Можно на perl, apt и так perl использует :-)

>>Да-да, давайте сделаем так, чтобы базовая система зависела от sqlite, а лучше - от oracle. :) И чтоб руками хрен туда залезешь. :)
>>Невкайф ему ждать. :) Каждые три минуты новые пакеты что ли ставишь? :)

А зачем туда лезть руками ? :)

Вы, простите, зачем сравнили sqlite и оракл ? Может, давайте сравним kpaint и GIMP ? Тут речь идёт о том, что хранение списка пакетов в локальной БД позволит бысто считывать-записывать. Это просто надо протестировать ;)

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

Короче, товарищи революционеры, возьмите и сделайте свой дистр с этой прорывной технологией. А потом посмотрим, сколько народу станет им пользоваться и сколько вообще станут участвовать в его разработке (а не орать, что без этого никуда).

Иными словами, ещё раз предлагаю подумать, но уже на другую тему: почему этого никто не сделал? Думаете, это такая свежая мысль, которая никому даже в голову не приходила, да? :)

pacman в Арче хранит метаданные о пакетах в иерархии директорий, по файлу на _каждый_ пакет. Через месяц использования поиск пакетов занимает секунд так 10 на pentium d 3.4
Вот это - труЪ суксъ.
Имхо, пока из по-настоящему используемых систем управления пакетами (всякие openpkg в виду не имеются) лучше dpkg и apt нифига нет.

Я бы кстати предпочёл по файлу на пакет, по своим соображениям некоторым. Хотя и кэш не помешает. В этом смысле FreeBSD показывает хороший пример IMHO (с директориями в /var/db/pkg и кэшем pkgdb.db). В общем спасибо за наводку, посмотрю на ваш arch. :)

А 10 секунд - это вполне нормально. Куда торопиться-то в данном случае.

нет, не суксь.

>>Короче, товарищи революционеры, возьмите и сделайте свой дистр с этой прорывной технологией. А потом посмотрим, сколько народу станет им пользоваться и сколько вообще станут участвовать в его разработке (а не орать, что без этого никуда).

Имхо, орёте тут вы. Предложите лучше нам почитать доку о том, почему dpkg не использует локальные бд.

>>и что линух применяется не только на десктопах (куда и не такую фигню можно засунуть) во-вторых

это разве непреложное правило, что везде должен быть один и тот же dpkg ? Для десктопов можно собирать _альтернативную_ версию dpkg с ключём типа --enable-sqlite. И все проблемы.

>>Короче, товарищи революционеры, возьмите и сделайте свой дистр с этой прорывной технологией

Их и так уже достаточно.

>Для десктопов можно собирать _альтернативную_ версию dpkg с ключём типа --enable-sqlite.

Ещё нам не хватало двух несовместимых dpkg!

Блин, неужели непонятно, что менеджер пакетов должен быть простой и тупой, чтобы работал везде и на всём, на минимальной конфигурации!

> предлагаю подумать, но уже на другую тему: почему этого никто не сделал?

Сделали это давно... RPM хранит информацию о пакетах в BerkeleyDB. Если бы на момент его (RPM) разработки существовал SQLite - может быть, использовали бы SQLite.

rpm не пользуюсь, но вообще о нём мало хорошего говорят именно как о пакет-манагере (ничего здесь не говорю об осях, которые используют). Я просто хочу сказать, что КЭШ в bdb или sqlite (хотя зачем там скляйт? bdb самое оно) - это нормально, а вот основная инфа - ну, вкратце, это просто не unix way. Да-да, я фанатик. :)

> rpm не пользуюсь, но вообще о нём мало хорошего говорят именно как о пакет-манагере

В RedHat-дистрибутивах он занимает место dpkg, фичей у него побольше (главное - что он предназначен для вызова человеком, а не apt-get'ом :))

> зачем там скляйт? bdb самое оно

Ууу... С SQLite настолько приятнее работать, что это даже не смешно.

> а вот основная инфа - ну, вкратце, это просто не unix way

Может быть... я, хотя тоже фанатик, понимаю, что объем и характер информации в БД пакетного менеджера таков, что в нем не разобраться без самого пакетного менеджера. В этом случае полезность текстового формата вызывает сомнения :)

>В RedHat-дистрибутивах он занимает место dpkg, фичей у него побольше (главное - что он предназначен для вызова человеком, а не apt-get'ом :))

Он предназначен не для вызова, а для замены на dpkg :-)

> Он предназначен не для вызова, а для замены на dpkg :-)

Ты фоннатег, а RPM, между прочим, стандарт :-P

а реализовать хранение базы плагином?

>Да-да, давайте сделаем так, чтобы базовая система зависела от sqlite, а лучше - от oracle. :)

да лана. ubuntu-minimal от перла и питона зависит. от либы в 340k нифига особо не изменится.

а во всяких страиваемых девайсах можно юзать plain-text бэкенд. если в встраиваемых девайсах вообще нужен dpkg.

>И чтоб руками хрен туда залезешь. :)

залезть руками туда - нефиг делать: открыл python-shell и вспоминать sql-запросы.

> С SQLite настолько приятнее работать, что это даже не смешно.

Работать же не тебе, а пакет-манагеру. :) Хотя я тут посмотрел, по размеру libsqlite даже меньше, так что в общем согласен, можно и скляйт для кэша заюзать. Но только при условии, что это именно кэш (то есть чуть где timestamp выше - читаем соответствующие текстовые файлы заново). Если так - то ради бога.

Хотя я всё равно не понимаю, нафиг всё это надо. Ну вот не каждый день я пакеты ставлю, хоть убейте. :) И даже когда ставлю, основное время уходит на загрузку и распаковку, а никак ни на регистрацию пакетов.

О, давайте к dpkg ещё и плагинный интерфейс писать! Проще сразу всё на Oracle переделать.

> можно и скляйт для кэша заюзать. Но только при условии, что это именно кэш (то есть чуть где timestamp выше - читаем соответствующие текстовые файлы заново).

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

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

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

этому критерию вполне удовлетворяет sqlite, запущенный из командной строки :D

> И не зависеть при этом от дополнительных либ.

sqlite, упомянутый выше, не либа, а экзешник (небольшой), так что формально это требование тоже соблюдено :)

> Это нужно.

Конечно. Но большим объемом информации, которая хорошо представима в виде реляционной БД, удобнее манипулировать с помощью SQL, а не awk и sed (при всем уважении к этим инструментам).

очень, странно в федоре:
file /var/lib/rpm/* дает Berkeley DB
rpm -q --requires rpm показывает зависимость от libsqlite3
ldd /bin/rpm подтверждает libsqlite3
смотреть исходники лень и дорого, gprs

Ладно, перейдём уже к конкретным примерам. Вот смотри, допустим мы клепаем VDS. Имеем дисковый шаблон (файлы общие для всех виртуальных серверов) и локальные диски у каждого VDS. При этом мы хотим шаблон обновлять централизованно, но и хозяевам VDS оставить возможность ставить свои пакеты. Как мы это делаем в FreeBSD? Да элементарно, там каждый пакет - это просто директория в /var/db/pkg. Локальные пакеты спокойно уживаются с щаблонными. Есть кое-какие проблемы, но в целом всё хорошо (кстати, кэш таки есть в /var/db/pkg/pkgdb.db). Как мы это делаем в системе с базой пакетов в твоём скляйте? А никак, обламываемся да и всё.

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

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

> Да элементарно, там каждый пакет - это просто директория в /var/db/pkg. Локальные пакеты спокойно уживаются с щаблонными. Есть кое-какие проблемы, но в целом всё хорошо (кстати, кэш таки есть в /var/db/pkg/pkgdb.db). Как мы это делаем в системе с базой пакетов в твоём скляйте? А никак, обламываемся да и всё.

Ты говоришь о другом - о _формате пакетов_, а я и OP - о формате внутренней БД менеджера пакетов. Насчет формата пакетов во всех дистрибутивах почти консенсус - это практически архив какого-нибудь стандартного формат (в Debian - просто архив ar). Мне нравится формат pkgsrc - tar с текстовыми метаданными.

> Я просто чего сказать-то хочу. Чем проще, дубовее система, тем проще её кустомизировать под свои нужды.

Это так с одной стороны. С другой - "дубовая" система предоставляет меньше возможностей (apt-get vs RPM). С третьей стороны - БД лучше подходит для хранения большого объема структурированной информации, а это более быстрая разработка программы, ее упрощение, облегчение ее сопровождения/модификации, и да, большая скорость. Так что вопрос в балансе между разными затратами.

> Ну не знаю я системы, для которой критичным было бы время, которое она проводит в работе с пакетами. :)

Я знаю: это система, на которой тестируется сборка/инсталляция пакетов :) Никогда не стоит недооценивать удобств для рядовых кодеров, в конце концов, именно они делают всю работу.

А вообще, выбор-то сделан (в RPM) - используется именно БД. И лично мне жаль, что это не SQL БД, а убогая BDB.

> Ты говоришь о другом - о _формате пакетов_, а я и OP - о формате внутренней БД менеджера пакетов. Насчет формата пакетов во всех дистрибутивах почти консенсус - это практически архив какого-нибудь стандартного формат (в Debian - просто архив ar). Мне нравится формат pkgsrc - tar с текстовыми метаданными.

В каком месте я говорю о формате пакетов?! Ты мою мессагу читал? :) Формат пакетов для того, о чём я говорил, абсолютно эквипенисуален. Я как раз-таки говорил о том, как они регистрируются в системе.

> С другой - "дубовая" система предоставляет меньше возможностей (apt-get vs RPM).

Дык, юзай апт-гет поверх дубовой системы, кто ж против то. Лично я - за. :)

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

Всё это не очень актуально для пакетного манагера. Его надо разработать один раз и на века.

> Я знаю: это система, на которой тестируется сборка/инсталляция пакетов :)

Эээ, секундочку, так сборка или инсталяция? :) Для сборки абсолютно пофиг, как там они потом будут регистрироваться в системе. И вообще на фоне сборки лишние 10 секунд ничего не меняют.

> А вообще, выбор-то сделан (в RPM) - используется именно БД. И лично мне жаль, что это не SQL БД, а убогая BDB.

Тут я и не спорю.

> В каком месте я говорю о формате пакетов?! Ты мою мессагу читал? :)

Сэр! Так точно, сэр! Читал, сэр! Вот в этом месте, сэр: "там каждый пакет - это просто директория в /var/db/pkg. Локальные пакеты спокойно уживаются с щаблонными"!

>> С другой - "дубовая" система предоставляет меньше возможностей (apt-get vs RPM).

> Дык, юзай апт-гет поверх дубовой системы, кто ж против то.

Я и юзаю :)

>> Я знаю: это система, на которой тестируется сборка/инсталляция пакетов :)

> не очень актуально для пакетного манагера. Его надо разработать один раз и на века.

Можешь мне не верить, но это актуально для любой программы. Сколько времени заняла миграция на APT 0.6 ? Почему его не разработали раз и на века? :)

> Эээ, секундочку, так сборка или инсталяция? :)

Первое без второго не нужно. Сборка, потом инсталляция/апгрейд/деинсталляция в chroot'е, причем систему в chroot'е лучше инсталлировать с нуля - это если честно делать работу :) Там отнюдь не 10 секунд.

Плохо читал, ну да ладно, в общем я всё что хотел сказал...