LINUX.ORG.RU

[NIH][gentoo][portage][sql]portage v3 - proof of concept

 , , ,


0

5

=========================================================================

.....................................УБЕДИТЕЛЬНАЯ ПРОСЬБА

перед тем как писать первое что пришло в голову осильте пожалуйста весь пост =========================================================================

Как-то давно я высказал мысль о том, что было бы неплохо запихнуть portage tree в базу.

Много воды утекло с тех пор. Я успел два раза сменить работу. Сейчас в моих задачах часто мелькает sql. Универовский курс и так был плох + я его еще и не слушал внимательно (ведь всего лишь зачет). И тут я вспомнил о своей идее..

Цели (в порядке убивания важности)

  • максимально возможно (в рамках задачи) изучить sql
  • подтянуть знание python/ruby (почему ruby, см ниже)
  • если удастся — «получить» новую версию package management system (PMS) в Gentoo (но в то же время это не самоцель) или хотя бы разродится GLEP`ом (желательно в статусе accepted) и [полу]рабочим кодом. 
  • все что есть в README.md на github`е
  • возможно что-то еще, что я забыл

За месяц в свободное время (+ частично забивая болт на работу) я успел налабать достаточно говно^Wкода, которий генерит такой же список, как и

emerge -pO world
Все бы ничего, но в сэт world автоматически включен сэт system. А сэты пока не главное, так что пришлось ограничится следующим
emerge -pO `cat /var/lib/portage/world`
Сейчас мое поделие дает такой же выхлоп, но в разы быстрее
vv@crusader ~/work/own/ruby/portage3/source/tools $ ./01_prepare_fast_storage.rb -r
Checking if '/dev/shm' path is present on target system.. OK
Checking if '/dev/shm' is a directory on target system.. OK
Checking if '/dev/shm' is writable on target system.. OK
Checking if '/dev/shm' has enough space on target system.. OK
Starting exctact portage snapshot.. Done
vv@crusader ~/work/own/ruby/portage3/source/tools $ ./02_generate_new_profiles.rb
cp: omitting directory `profiles/arch'
...  << SKIPPED
cp: omitting directory `profiles/default/linux/x86'
vv@crusader ~/work/own/ruby/portage3/source/tools $ ./03_patch_profiles_list.rb
vv@crusader ~/work/own/ruby/portage3/source/tools $ ./04_patch_package-mask.rb
vv@crusader ~/work/own/ruby/portage3/source/tools $ ./05_patch_ebuilds.rb
vv@crusader ~/work/own/ruby/portage3/source/tools $ ./06_create_db.rb
Everything is OK. Database was created at:
/dev/shm/portage3_data/test-20120206-223124.sqlite
vv@crusader ~/work/own/ruby/portage3/source/tools $ time ./07_fill_db.rb
././tables_population/26_ebuilds.rb:19: warning: already initialized constant VERSION
././tables_population/28_profile_masks.rb:21: warning: already initialized constant VERSION
././tables_population/29_users_keywords.rb:20: warning: already initialized constant VERSION
././tables_population/30_users_mask.rb:20: warning: already initialized constant VERSION
real    2m38.133s
user    2m4.067s
sys     0m32.847s
vv@crusader ~/work/own/ruby/portage3/source/tools $ mv /dev/shm/portage3_data/test-20120206-223124.sqlite /tmp/
vv@crusader ~/work/own/ruby/portage3/source/tools $ cd ../src/
vv@crusader ~/work/own/ruby/portage3/source/src $ time `./emerge_pO_world.rb -f /tmp/test-20120206-223124.sqlite > /tmp/p3_fin`
real    0m0.559s
user    0m0.200s
sys     0m0.020s
vv@crusader ~/work/own/ruby/portage3/source/src $ cat /usr/local/bin/et
#!/bin/sh
emerge -pO `cat /var/lib/portage/world` | grep ebuild | awk '{print $4}' | sort > /tmp/p2_fin
vv@crusader ~/work/own/ruby/portage3/source/src $ time `et`
real    0m13.956s
user    0m4.603s
sys     0m0.226s
vv@crusader ~/work/own/ruby/portage3/source/src $ diff /tmp/p2_fin /tmp/p3_fin
vv@crusader ~/work/own/ruby/portage3/source/src $

Как видите быстрее в ~27 раз. Тестировал на __обычной__ генте, на ноуте 5-летней давности (Toshiba Satellite m100-221)

Что есть

  • source code на github`е, основная ветка сейчас — keywords2
  • желание пилить дальше (или участвовать/помогать)
  • пачка скриптов на руби, 2 sql файла и todo-файл (infos/issues)
  • новые нескучные обои^W^Wпрофили (см папку profiles_v2). Обьяснения ниже
  • новых профилей только 2: x86/linux/* & amd64/linux/*. Внимание: у меня stable х86 и тестил я только на нем. Возможно Вам удастся завести и на других arch`ах (без или с минимальными хаками кода и базы)
  • поддержка keywords (~/+) на всех уровнях
  • поддержка package.[un]mask (masked()/unmasked(-)) на всех уровнях
  • поддержка /etc/portage/package.{keywords,mask,unmask} в виде __файлов__

RUBY? WTF!!!

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

Я прекрасно понимаю, что не может быть и речи о попадании моего творения в «продакшен», пока все не будет переписано на питоне. После того, как сие (переписывание) случится, обязуюсь в рамках проекта дальше кодить на питоне.

PROFILES. 2 beers or not 2 beers

Сначала они мне показались слишком запутанными, разбросанными, с наследованием на каждом углу итп итд. Я решил упростить схему до следующего

${portage_home}/profiles/base/{hardware architecture}/{software platform/}/[({feature}/)?]/{release}/{target}/[({blah-blah}/)*]
где

  • hardware architecture - x86, amd64, sparc64 etc
  • software platform - linux, freebsd, winnt, (да-да; см. profiles/profiles.desc) etc
  • feature - default, ulibc (или как там ее), hardened etc
  • release - 10.0, 2008.0 etc
  • targer - server, desktop, developer etc
  • blah-blah - kde, gnome, etc

Но потом я начал понимать, что не все так радужно, как казалось. Пока оставил как есть. «to be continued» как говорится.

Чего хочу от ВАС

  • так как я в базах до этого был почти полный ноль то:
    • критики/советов/etc о том, как спроектирована база (portage.sqlite.sql)
    • критики/советов/etc о том, как упростить и сделать быстрее запросы в emerge_pO_world.rb
  • советов о том, какая база здесь будет лучше и быстрее в использовании.
    • sqlite. используется сейчас.
    • berkelydb. c 5й версии она торт
    • что-то типа такого. чтобы быстрее считать [RC]DEPEND`ы (подразумеваем дерево зависимостей)
    • здесь идут вашы варианты. но помните, что не каждый захочет для PMS тянуть в систему mysql/postgres/etc
  • быть разработчиком/контрибутором. есть желающие?
  • а тестером? а если у вас нестандартная arch — так вообще замечательно
  • осуществить/помочь с переходом на python

Чего нет

  • достаточно свободного времени
  • хорошей обработки ошибок. сейчас оно просто вываливается. Если ничего не работает, но и нет ошибок запускайте каждый скрипт по отдельности
  • нормальных debug сообщений
  • нормальной поддержки версий (см. портянку в 26_ebuilds.rb:155, а также в файле issues)
  • [RC]DEPENDS
  • use flags
  • overlays
  • буквенные слоты
  • ...
  • этот список можно продолжать очень долго

Что НЕ хочу от ВАС

  • «тред не читай & сразу отвечай»
  • советов о том, что gentoo/portage/sql/python/ruby/ ZuBB/etc не нужен
  • советов о том что любой кусок кода в папке tools говно. Возможно так и есть. Сейчас это не главное
  •  не создавайте ишки c feature requests/blue sky ideas на гитхабе. Пока видимые задачи/проблемы/баги явно в фаворе

Что будет дальше

  1. мердж всех веток в мастер
  2. я беру паузу на месяц-полтора. буду чередовать работу/отдых/катание на Буковеле по виходным/ДР`я в компании/etc
  3. если будет заинтересованность здесь, то сделаю небольшой cleanup кода и анонс в G+/Gentoo Forums(/еще гдето?)

Кушать подано! (С)

PS: пардоньте мой «французский». Это не мой родной язык

PS2: ах да mail: zv@sylvv AT почта «самой хорошей корпорации в мире» DOT ком

PS3: извините за длинный пост

★★★★★

Последнее исправление: ZuBB (всего исправлений: 7)
Ответ на: комментарий от ZuBB

вы наверно шутите

Да я сам не знаю. Просто подумал, может есть какие-то фишки у SQL которые тут удобны (какие-нибудь хитрые select-запросы), а то сейчас документы модно в noSQL совать.

quasimoto ★★★★
()
Ответ на: комментарий от theos

В Беркли не надо парсить сиквель стейтменты, например, но и возможностей заметно меньше

объясните попроще пожалуйста

Если большее - твой выбор скулайт

да, больше. в беркли 5й версии есть sql-like интерфейс. попробую потестить

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от Lighting

правильно.

кажись на гитхаб так никто и не ходил.. :(

Portage (1, 2)) is a package management software for Gentoo Linux. It stores all data in plain txt files (I know about sqlite cache)

I do not like when it takes minutes to do 'emerge -pvte world' Also there are dozens of places where files that imply portage work are stored. I would like to see that number reduced Possibly there are other things that I do not like in portage, but..

я начал всю эту затею потому что он медленно считает зависимости при установке пакетов

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey
real	0m1.363s
user	0m1.036s
sys	0m0.011s

ну что могу сказать. возможная реальная альтернатива. со своим особенным бинарным индексом

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от ZenitharChampion

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

Назови мне ФС, в которой это не так.

x3al ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

но тогда нету смысла пилить мою приблуду. достаточно чтобы portage юзал eix как бэкэнд

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от ZenitharChampion

слелал следуещее

  • смаунтил рамдиск.
  • скопировал /usr/portage на рамдиск.
  • переименовал /usr/portage
  • сделал симлинк
  • запустил «time emerge -pO `cat /var/lib/portage/world`»

получит результат больше чем на обычном хдд. как понимать хз. в чом может быть дело?

real    0m47.850s
user    0m30.090s
sys     0m6.201s
ZuBB ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey

тебя ни капельки не смущает фраза?

со своим особенным бинарным индексом

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от ZuBB

я начал всю эту затею потому что он медленно считает зависимости при установке пакетов

Разве SQLite кэш не эту же проблему решает?

Вообще, текущая архитектура основана на том, что всегда можно запилить / поправить ebuild на простом скриптовом языке (bash), положить его в дерево и он сразу начнёт работать. Если переносить дерево в реляционную базу, то придётся решать такие проблемы:

  • Реализовывать парсер bash который будет понимать общепринятые ebuild-ы и делать INSERT в базу на основе разобранной информации.
  • Т.к. ebuild может содержать произвольные куски bash-кода, которые могут делать что угодно, в базу придётся помещать также эти скриптовые функции (как текст).
  • Сама по себе структура базы будет не простой, как я понимаю.
  • Выборка будет быстрее, но sync станет медленнее - после получения изменённых файлов (как текста) нужно на них запускать парсер который будет что-то в базе обновлять.

От самих ebuld-ов отказаться нельзя, понятное дело (а то это будет уже другой дистрибутив).

quasimoto ★★★★
()
Ответ на: комментарий от quasimoto

Разве SQLite кэш не эту же проблему решает?

у меня он включен. он ничего не решает (или я плохо настроил (с gentoo wiki))

Реализовывать парсер bash который будет понимать общепринятые ebuild-ы и делать INSERT в базу на основе разобранной информации.

часть уже реализована https://github.com/zvasyl/portage3/tree/keywords2/source/tools/tables_population

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

да. возможно будет так 'ebuild -> zip - data blob field в базе'

Сама по себе структура базы будет не простой, как я понимаю.

а кто говорил что будет просто? также озвучте критерии простоты

Выборка будет быстрее, но sync станет медленнее - после получения изменённых файлов (как текста) нужно на них запускать парсер который будет что-то в базе обновлять.

да медленнее. но вопрос на сколько. сейчас все (в том числе и дерево) всасывается за 2m38.133s. правда из tmpfs. у меня нет пруфов ,но думаю не более чем на 10%

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от quasimoto

Сама по себе структура базы будет не простой, как я понимаю.

а кто говорил что будет просто? также озвучте критерии простоты

и ради интереса посмотрите на базу. имо там сейчас нет ничего сложного

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от ZuBB

когда программа будет успешно обрабатывать все хотя бы для какого-либо оверлея это будет proof-of-concept, т.к. пока она не покрывает большую часть возможностей emerge. В любом случае если всё получится, то будет весьма не плохо.

qnikst ★★★★★
()
Ответ на: комментарий от ZuBB

также озвучте критерии простоты

Дерево в FS, синхронизация дерева git-ом, что-то для ускорения расчёта зависимостей (с пересчётом после каждой синхронизации). Это последнее «что-то» может быть и переносом информации дерева в базу, лишь бы не особо бросалось в глаза (всё-таки portage наследует идеологию портов - дерево plain text-овых рецептов про то как что ставить), т.е. не улучшало что-то одно за счёт проседания в другом.

сейчас все (в том числе и дерево) всасывается за 2m38.133s.

git pull, например, накладывает (и большие тоже) разницы на порядок быстрее. Тут надо как-то уметь синхронизировать базу частями (изменился один ebuild - парсим один файл, делаем один INSERT).

quasimoto ★★★★
()
Ответ на: комментарий от ZenitharChampion

ext2 на моём Flash-диске очень медленно работает с маленькими файлами.

А на вопрос ответить?

x3al ★★★★★
()
Ответ на: комментарий от quasimoto

Тут надо как-то уметь синхронизировать базу частями (изменился один ebuild - парсим один файл, делаем один INSERT)

уже есть.

насчет остального - нужно подумать

ZuBB ★★★★★
() автор топика
Ответ на: комментарий от ZuBB

Благодарю за приглашение. Касательно выноса портежей в оперативку - portage=>tmpfs. Как видим не шибко раскочегаривает и больше походит на погрешность в замерах. Получить еще небольшое ускорение процесса расчёта зависимостей можно, научив portage работать со SQLite (автор подборки инструкций, если не ошибаюсь, megabaks). Дополнительно можно попробовать переключить работу портежей с использованием сил трехголового питона. Есть и другой вариант ускорения вместо OVERLAY_CACHE_METHOD='sqlite' использовать 'parse'. Но это все не совсем то. Сильно быстрее не станет. В портежах до сих пор не используется реальная МНОГОПОТОЧНОСТЬ. А это точно дало бы ускорение в разы. Хотя уже сейчас можно ускорить процессы распаковки - запаковки, которые используют параллельные алгоритмы (эти архиваторы устанавливаются элементарно как любая другая программа и заменяют собой однопоточные). Но запускать два процесса установки пакетов, которые не согласуют между собой зоны ответственности черевато сбоем компиляции.

Что касается вопросов неверующих есть ли лучше системы управления пакетами? - читаем и спорим тут. До сих пор адекватных аналогов у портежей нет.

А вообще сама идея скомпоновать из идей дженты красивого, быстрого и гибкого зверя мне по душе. Изучаю материалы в этом направлении, насколько позволяет время. Но это огромная пропасть работы. В принципе вырисовывается несколько направлений: гибкое управление пакетами, автоматическая генерация установочных правил для системы управления пакетами из голых исходников, шустрая загрузка системы или любой ее логической части, быстрый сишный менеджер окон (аки E17, к примеру, но хочется с удобной настройкой) и... нужна реально скоростная и надежная файловая система... Ну ка в любой фс попробуйте скопировать кучу мелких файлов или просто их распаковать из тарбола... Что будет быстрее? Только не нужно кивать на SSD, когда работаешь с огромными базами - никаких финансов на них не напасешься. Пользуют даже накопители на магнитных лентах до сих пор.

Развиваться есть куда, даже дженте. Готов посильно помогать, если будет желание продолжить это направление.

glibych ★★
()

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

Pinkbyte ★★★★★
()

Хорошая затея, хотя я не вижу объективных причин использования скриптовых языков для разработки. На выходных гляну, как оно в работе.

x0r ★★★★★
()
Ответ на: комментарий от ZuBB

мне нравится тот факт, что нарисована схема БД, все остальное не одобряю.

Я имперец: только paludis, только С++, только postgres. И все это только на время подготовки переворота и прихода к власти OS cosmos.

StrongDollar
()

Дочитал тред до середины. Дальше стало лень читать срач.
Что хочу сказать:
1) Лично мне Lua нравится куда больше Ruby (и тем паче Python) и идея переписать на нем портаж висит давно. проблема в том, что его постигнет судьба всех «альтернативных»...
2) Использование SQL (да и noSQL тоже) только потому, что автору хочется попрактиковаться — простите, но идиотизм. Ровно как и использование интерпретируемых языков (ну, кроме luajit, ибо он даже сям даёт фору порою).
Бинарный кеш (да даже и полуплейн, но грамотно организованный (см. git)) может принести намного больший профит нежели SQL.
3) как «гентудев без плашки» уверенно зявляю: работа по выдумыванию как оптимизировать портаж идут уже давно и zmedico и lxnay положили уже не мало нервов. Читайте рассылку, чтоле...
4) за скорость *подсчёта зависимостей* отвечает как раз кеш, а не место нахождения самих ебилдов.
5) для быстрого шуршания самими ебилдами был придуман портаж в сквошфс. И профит даёт в разы больший, чем у автора (на пару с скулайтным кешем). А с переходом портажа на гит — всё станет ещё «шоколаднее»
6) а как автор предлагает вести разработку ебилдов в портаже и копировать ебилды оттуда? извращаться с sql вместо обычных cp/edit/mv?


К слову, советую автору посмотреть на Entropy (за авторством lxnay). Оно тоже на питоне, не исплользует sql но при этом даже частично пользуя кеш портажа (плейновый) работает опять же быстрее поделки автора...

Но, тем не менее, автор — молодец, хоть и направил силы не туда.

//wbr

Skim
()
Ответ на: комментарий от Chaser_Andrey

Чёрт побери, это Gentoo! И одно из её качеств - это
скорость! Так вот... ну зачем писать пакетный менеджер
на интерпретируемых языках, если ты хочешь от него
довольно нетривиальной обработки немалых объемов
данных за минимальное время? А ещё добавь сюда
время загрузки самого интерпретатора, модулей и т.д.

paludis - c++ поделие. Работает еще медленнее. Есть поверье, что самый быстрый пакетный менеджер - pkgcore (сам не пробовал).

sf ★★★
()
9 ноября 2012 г.

что-то типа такого. чтобы быстрее считать [RC]DEPEND`ы (подразумеваем дерево зависимостей)

Это крутая штука и будет работать очень быстро. Но ты не знаешь главного нюанса...

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

да

package management system (PMS)

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