Мысль вслух
Мысль не новая и возможно даже обсуждалась здесь, так что пррошу сразу не пинать.
Насколько мне известно разработчики gentoo сразу начинают плеваться видя вместе слова "база данных и дерево портежей" и правильно делают: от портежей на файлах никуба не деться бо текствый редактор наше все. Но почему не поддерживать копию дерева в базах параллельно с деревом на файлах и обновлять его при синках, а оверлей оставить как есть, чтобы пользователь мог ковыряться. И вообще можно сделать это отключаемой опцией. Или portage написан так, что в нем невозможно отделить точки обращения к дереву? было бы странно.
А то слишком(читай неприлично) долго подсчет зависимостей скрипит винтом. Это конечно не сравнимо со временем сборки, но хочется "emerge -p..; убедился что все норм; запустил; ушел спать :)" да и в экспериментах с юзами пригодится: не будет так раздражать, все-таки "самый быстрый дистрибутив".
ЗЫ если я неправ или придумал велосипед, пожалуйста покажите где.
- Для комментирования войдите или зарегистрируйтесь
думаю, что примерно в этих
думаю, что примерно в этих темах всё уже высказали :)
http://www.gentoo.ru/node/15568
http://www.gentoo.ru/node/15400
http://www.gentoo.ru/node/4212
Ближе всех ИМХО вторая ссылка
Ближе всех ИМХО вторая ссылка но и там я отражения своего велосипеда не нашел
повторяя своими словами, сам
повторяя своими словами, сам не особо разбираюсь.
1). Логика зависимостей в ebuild'ах зачастую нетривиальна и записать её в терминах базы данных достаточно не простая задача, для которой даже не понятно окупится ли она.
2). alexxy что-то писал про проект записи в мета-данных файла, ускоряющих процесс, в темах это описано подробнее
3). от себя: база то всё равно будет в тех же файлах храниться и подниматься при обращении к emerge и будет опять то же самое "скрипение винтом" при поднятии всех индексов :)
Вот кстати да, реальная
Вот кстати да, реальная трабла портажа. Уж оч долго зависимости считает, хотя по сути дела вся операция - пробежаться по дереву, я так понимаю он в этот момент все ебилды парсит? Я так понимаю там никакого настоящего индексирования нету?
Если не хотите чтобы скрипел
Если не хотите чтобы скрипел винтом - придумайте какой-нибудь фееричный кэш, скажем в оперативку. Тут люди вроде даже выносили /usr/portage в tmpfs при загрузке машины, прирост был(по их словам). А насчет нетривиальности зависимостей - это да. Чего стоит только довольная странная(на мой взгляд) логика build dependencies, runtime dependencies, которые определяются не пойми как(переменную BDEPEND в ебилдах не вспоминайте, утверждают что это зло). Так что единственный вариант тут - какая-нить база знаний... Но чо-то при этот словосочетании мне становится как-то реально сцыкатно o_O
Нейтральность - высшее достижение сознания!
А нелинейность возникает в
А нелинейность возникает в следствии того что у пакетов есть USE-флаги, eclass тоже от чего-то зависят и в самих ebuild'дах бывают используют утилитки. но для того чтоб сойти с ума достаточно одних USE. К тому-же portage таки использует некоторый вид DB для метаданных(заглядываем в /var/cache/edb/).
зря утверждают, это очень даже добро. а нужно это при кросскомпиляции или сборке систему в "другой корень" - когда на текущей машине собирают пакеты в другой корневой каталог - зачем там нужны сборочные зависимости?
P.S. базы знаний тут не причём, а вот продвинутая математика и теория графов - очень даже к месту.
Ну как бы если зависисмости
Ну как бы если зависисмости считаются долго то добавить FEATURES=metadata-transfer в make.conf
Если подключено много оверлеев то опять же понятно почему долго считаются зависимости =) Оверлеии не содержат метаданных. Они содержат только ебилды. Отсюда вывод метаданные надо нагенерировать. Сделать это можно для тех оверлеев которые это поддерживают (это например science kde-testing x11 и еще некоторые).
Как это сделать? ну тут тоже вес просто. Ставим eix-0.16 и выше =) и читаме его ман. Он может запустить нужный хук после синхронизации оверлеев в eix-sync
хук выглядит следующим образом
egencache --repo=kde --update --jobs=2
ну kde тут имя оверлея --jobs количество потоков =)
___________________________________________
Working on Gentoo for iPAQ hx4700 and Openmoko Neo Freerunner :-)
Если у вас компьютер с Windows, есть два выхода: выбросить компьютер в форточку или выбросить форточки с компьютера
Добавил еще давно, не сказать
Добавил еще давно, не сказать что оно стало заметно быстрей =/
Все очень просто. Реляционка
Все очень просто. Реляционка принесет в портеж больше проблем. Выигрыш же она может дать только при соблюдении двух условий -
a) грамотной нормализации (что требует больших трудозатрат при сопровождении портежа и всевозможных его оверлеев)
б) грамотной индексации.
По сути предлагается разложить башевский скрипт ебилда на реляционные таблицы, чтобы затем, по некоему хитрому запросу собрать этот же пресловутый ебилд.. Вобщем... попробуйте это реализовать сами и поймете от чего плюются разработчики. Что касается индексации, то она вполне возможна и без использования реляционной субд, eix тому пример. Вероятно к этому все и сведется. Однако чудес на свете не бываюет. Представьте себе сколько займет времени построение индексов зависимостей по всему дереву (а ведь многим придется делать это каждый день).
Я догадываюсь отчегоо плюются
Я догадываюсь отчегоо плюются разработчики и согласен с ними, поэтому не предлагаю никуда девать исходное дерево на файлах, достаточно всего лишь дополнительно его проиндексировать.
Построение индексов можно запилить инкрементально вместе с синками.
Не забывайте, что eix
Не забывайте, что eix индексирует только пакеты, а не связи между ними
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Предполагается совершенно
Предполагается совершенно новая тулза с блекджеком... Или считается что при просчете зависимостей от нее не будет никакого профита?
Вы определитесь, что именно
Вы определитесь, что именно Вы хотите хранить в базе. Файлы - смысла нет, зависимости - слишком тяжело создать структуру бд.
То есть я пральна понимаю,
То есть я пральна понимаю, что решение проблемы никто не смог придумать на данный момент?
да, вменяемого решения нет.
да, вменяемого решения нет. была когдато такая фенечка - хранение в sqlite кэша метаданных, но толку было чуть, а мороки, особенно при косяках с системой, было сильно больше...
У вас дерево портежей на
У вас дерево портежей на отдельном разделе? Если нет, то сделайте раздел метров 500 с reiserfs на нём и туда перенесите дерево портежей. Не мерил, но на глаз прирост производительности заметный...
Если проблема всё равно будет очень мучить, попробуйте использовать paludis.
Всё нижесказаное - моё лично мнение
Portage - система выстраданая и отлаженая. "Заточена" она "под гибкость". На мой взляд - весьма удачно.
Все попытки отказаться от "файловой" структуры в пользу "базы данных" без изменения всей идеологии Gentoo приведут в тот же тупик, из которого уже найден выход: ebuild.
Да, не "ракетная скорость" подготовки системы к работе. В отличие от большинства "бинарных пакетников". Зато есть то, чего ТАК не хватает "ракетостроителям": возможность точно настроить систему под точно выверенные требования.
Нет, я не утверждаю, что это "идеал". Это - особенность инструмента. Глупо ждать от молотка остроты скальпеля, не так ли?
emerge Your world
Gentoogle
ппц... мне одному кажеццо,
ппц... мне одному кажеццо, что в желании автора проглядывается виндовый реестр? ))) чем сложнее система, тем проще она падает! Взгляните на виндовс - мегасложная система на самом деле и тока благодаря этому такая неуклюжая, нестабильная и небыстрая. 90% проблем в виндовс из-за реестра, а это ничто иное как база данных. Не губите созданную простоту! лучше обновляйтесь с умом ;-)
Ну лично я тоже за ебилды ибо
Ну лично я тоже за ебилды ибо это просто и понятно. Но нужно как-то этот вопрос оптимизировать таки. Кстати вопрос к профи, а как в Палудисе с этим?
AFAIK так же. корость которой
AFAIK так же. корость которой кичатся пользователи палудиса на деле ничего не значит.
Мне вот непонятно вообще
Мне вот непонятно вообще зачем это?
Нужна скорость разворачивания системы - так какая разница сколько тогда считаются зависимости, всё равно компилится оно дольше.
еще раз задумался об этом
еще раз задумался об этом вопросе, когда винт вчера при просчёте системы затрещал как ненормальный... думаю, что ему не долго осталось... дык, я взял и смонтировал tmpfs в /usr/portage на 500 метров с увеличенным количеством айнодов, синхронизировался, и полетел... тишина )))) скорость раза в полтора больше... в общем советую... кому количество оперативы позволяет, то можно и на вермя сборки в /var/tmp/portage tmpfs на пару гигов монтировать. скорость сборки не увеличится, зато винт молчит и чистить каталог после неудачной сборки не нада ;-)
особенность использования
особенность использования linux стостоит в том что "тем у кого много оперативы" ядро всё само закэширует.
после первого прохода да,
после первого прохода да, второй существенно быстрее, но я дважды редко одну команду набираю ;-)
не, ну сборка у меня уже
не, ну сборка у меня уже давно в tmpfs.
стоит ли заморачиваться на счёт перемещения туда портэджей?
ну, а что?.. у меня уже есть
ну, а что?.. у меня уже есть скриптик, который монтирует tmpfs на время сборки и отмонтирует по окончании... можно такой же написать для портежей... подмонтировал, обновил, пошёл обновляться, отмонтировал... ведь по сути чаще раза в неделю эта операция не особо нужна. попробовать стоит хотя бы потому, что зависимости считаются немного быстрее и винт вообще молчит ))) хотя есть наверное и небольшое ограничение, инет должен быть постоянно, иначе пересобрать ничего не получится, но и тут можно на всякий бэкапить портежи в tgz, которые при отсутствии коннекта будут распаковываться автоматически =) в общем это кому как...
После 2 лет работы с Генту
После 2 лет работы с Генту крепко запомнил правило: работает не - трож!
Но! портаж + флаги + зависимости (+ возможно еще кое-что) так и просится в базу.
И мне кажется что лучше самому попробывать и убедить потом всех или самому убедится в противоположном
Топикстартеру:
как на счет такого предложения: создать какую нить групу на гугл.групс подключить народ, который этим интересуется (начать отсюда) и попробывать чтонибуть да и написать.
Или ждать готового ввиду этого
Но мне лично больше по душе вариант базы; ношусь с ним уже ~3 месяца
вот, это уже совсем другое
вот, это уже совсем другое дело! могу лиш пожелать удачи.
Но
Перед тем как заморачиваться я бы рекомендовал тебе составить для себя (и согласовать/убедиться в приемлемости для разработчиков Gentoo/portage) критерии годности решения (и перспективности дальнейшей разработки/доработки).
:wq
--
Live free or die
Для девелопера методы
Для девелопера методы повседневной работи измениться в корне не должны, концепция должна остаться такой же, иначе вся эта затея "не стоит свеч", Конечно будут некоторые изменения, но они должни быть (и остаться после разработки) минорными.
На счет разработки/доработки не знаю что сказать (GLEP не читал), но поскольку концепция должна остаться такой же, это не должно стать проблемой