LINUX.ORG.RU
ФорумTalks

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


0

0

хранить базу установленных пакетов в плоском текстовом файлике (тот который /var/lib/dpkg/status ), вместо того, чтобы не юзать ту же sqlite?

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

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

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

нет.

dv5ife ()

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

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

stassats ★★★★ ()

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

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

router ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от stassats

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

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

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

Gharik ()

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

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

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

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

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

zort ()
Ответ на: Re: вот dpkg - не суксь ли? от zort

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

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

zort ()

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

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

Nagwal ★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Nagwal

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

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

mutronix ★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от mutronix

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

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

Nagwal ★★★★ ()

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

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

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

Teak ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

zort ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

mutronix ★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

beastie ★★★★★ ()

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

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

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

ref ()

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

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

Orlangoor ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от ref

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

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

zort ()
Ответ на: Re: вот dpkg - не суксь ли? от Orlangoor

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

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

zort ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

ser_bur ★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от zort

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

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

Xellos ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

alex_custov ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от alex_custov

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

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

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

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

Teak ★★★★★ ()

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

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

romka ()
Ответ на: Re: вот dpkg - не суксь ли? от romka

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

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

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

Teak ★★★★★ ()

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

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

grinn ★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

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

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

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

alex_custov ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от alex_custov

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

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

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

Xellos ★★★★★ ()

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

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

Xellos ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

Teak ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

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

Xellos ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Xellos

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

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

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

Muromec ☆☆ ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

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

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

Teak ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Muromec

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

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

Xellos ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

Teak ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

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

> Это нужно.

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

tailgunner ★★★★★ ()

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

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

Dr_ZLO ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

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

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

Teak ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

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

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

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

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

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

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

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

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

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

Teak ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от Teak

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

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

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

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

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

Я и юзаю :)

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: вот dpkg - не суксь ли? от tailgunner

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

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

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