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)

сразу вопрос, поддерживает ли твой подход все возможности указания зависимостей поддерживаемые в 3,4 EAPI?

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

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

qnikst ★★★★★
()

А разве sql уже нет? У мегабакса на сайте что-то упоминалось. Хотя раз такое дело завелось, видимо я глючу.

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

там только кеш в нем. а здесь все. планируется.

// прости но смахивает на «тред не читай & сразу отвечай»

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

все выражения вида (boolean var) dependency, где boolean var выражение из use, наличия/отсуствия установленных програм/ENV переменных и т.п. при этом выражение может быть составным.

qnikst ★★★★★
()

Очень нужно! Сам лишь недавно на gentoo, но тормозной Portage уже бесит.

fragment
()

ах да забил скастовать всех ярых (и не особо) гентушников (если в мою выборку попали любители других дистров - звиняйте)

bsdfun, Chaser_Andrey, deterok, dimqua, Gary, glibych, Gorthauer, init_6, jcd, kostik87, KRoN73, Lautre, Lighting, luke, MahMahoritos, megabaks, qnikst, rigiy, staseg, StrongDollar, Tanger, tazhate, vertexua, vurdalak, x0r, ymuv, ZenitharChampion, Zhbert, tark

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

Чорт, я же не гентушник. А то уже на горячую голову помогать хотел.

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

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

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

годный вопрос. лучшая идея которая приходила мне в голову такая: архивированные альтеры + time of last modification

ZuBB ★★★★★
() автор топика

В данном случае есть какие-то преимущества у SQL перед документо-ориентированными БД, вроде MongoDB?

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

мне сложно ответить на вопрос. возможно выборка по критериям?

я же скастовал спецов по sql`ям. пожет подскажут

ps: какие зависимости у монги?

ZuBB ★★★★★
() автор топика

Оффтоп, но тоже хотелось что-то сделать для генты. Некоторые области могут пересекаться или взаимодополняться. [Gentoo] Что заюзать для централизированного управления компами с Gentoo? Есть живые аналоги GEMS? Если таковых нет - может, напишем инструмент (подробности в теме)?

А теперь по теме: начинания хороши, но...

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

Обрати на скорость работы eix. Я бы хотел от менеджера пакетов сопоставимой скорости.

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

ты про мультикаст?

ага. предчувствую эпик срач.

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

Видел ваш тред. зафрендил еще тогда

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

Обрати на скорость работы eix. Я бы хотел от менеджера пакетов сопоставимой скорости.

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

-----

извини но я считаю что питон/ruby/etc не тормозы (или меркулиал такой уж плохой?). нужно просто руки..

и да, я уже слишком подсел на динамические языки

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

Как видите быстрее в ~27 раз.

Извини, я не хочу умалять твою работу, но всё же без поддержки "[RC]DEPENDS, use flags, overlays, буквенных слотов" это вовсе не показатель. Просто попытайся представить, сколько ты потратишь времени на высчитывание и разруливание зависимостей?

Chaser_Andrey ★★★★★
()

Это всё очень хорошо, но:

а тестером? а если у вас нестандартная arch — так вообще замечательно

Я пока в упор не вижу даже полуготового решения.

советов о том, какая база здесь будет лучше и быстрее в использовании

Тут, я считаю, выбирать надо, исходя из того, у какой БД меньший оверкилл, а не какая быстрее. BerkeleyDB, ЕМНИП, в Дженту по умолчанию, SQLite используют для кэшей.

Кстати, тут кто-то предлагал использовать(и даже использует) дерево в git. Выигрыш в скорости огромный, но кто бы развернул и поддерживал зеркало...

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

тут надо описание EAPI смотреть, во всяком случае пока не готовы use мои примеры не будут полноценными.

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

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

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

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

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

почитал сам. на оба вопроса ответ да

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

Я не знаю есть ли он. Найди команду создания RAM-диска (он сразу появится в media:/), скопируй туда /usr/portage, и сделай симлинк. Если действительно есть желание попробовать. Я вот не пробовал, но так как очень часто использую LiveCD, замечаю, что файловая система в памяти это действительно быстро, в том числе с маленькими файлами.

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

сейчас чтонить соображу

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

Тут, я считаю, выбирать надо, исходя из того, у какой БД меньший оверкилл, а не какая быстрее. BerkeleyDB, ЕМНИП, в Дженту по умолчанию, SQLite используют для кэшей.

повторяю опять. я не спец по sql и ты как я вижу тоже (мож ошибаюсь, но вряд ли)

дефолт мне не указ. я делаю новую тулзу. и хочу чтобы она была быстрая. в чом скулайт имеет оверкилл над берклидб?

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

в чом скулайт имеет оверкилл над берклидб?

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

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

Забавно.

В субботу наконец-то дошли руки поставить генту. Скорость работы портаджа по сравнению с аптом удручает. Ну что же удачи вам!

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