Emerge vs. RPM

Вот почему emerge по сравнению с rpm так долго просчитывает зависимости?
Точнее, почему каждый раз заново? Включение cache.sqlite.database не дает ни малейшего прироста производительности. Выходит разработчик Paludis был прав, говоря что portage/emerge это “лапша из процедурного быдлокода на bash и python”?

возможно для кодера с точки зрения чистоты кода и так ,но,есть моментик с которым друие пакетманагеры включая РПМ не сталкиваются, отрабатывая каждый раз,ибо основаны на системе бинарных репов с медленно меняющимися списком ,а не сырцовых …,ситуация актуальности версий пакетов и их депенденсов,заметьте не только прямых(как делается в РПМ и других иже с ним),но и обратных, входящих в набор на конкретной машине,может меняться по нескольку раз за сутки,и что,всё это держать в синхроне рилтайм? гораздо проще,и логичнее сделать просчёт как раз тогда когда он и необходим т.е. по получении команды на обновление или синхронизацию…,да и скорость просчёта на самом деле не настолько актуальна,учитывая частоту запросов на обновки на среднестатистической машине…сдаётся мне что Вы пытаетесь сравнивать мягкое с горячим,другими словами несколько некорректное сравнение…ни на что не претендую,просто ИМХО
P.S. ну и кроме того и этот момент,впрочем как почти всё в генте тоже можно регулировать в определённых пределах задавая портэжу/эмежу глубину просчётов прямых и обратных зависимостей,механизм есть и он работает,и даже частенько может помочь с решением циклических блкировок автоматизировав львиную долю ручного "разруливания " и,насколько помню,в кальке глубина по дефолту весьма большая,что значительно облегчает жизнь неподготовленным пользователям,кстати…
P.P.S. стоит внимательно почитать ман портежа и выяснить как и когда стоит увеличивать глубину,когда можно уменьшить или вовсе отключить просчёт обратных депенденсов уменьшив соответственно и время затрачиваемое на просчёт…

ситуация актуальности версий пакетов и их депенденсов,заметьте не только прямых(как делается в РПМ и других иже с ним),но и обратных, входящих в набор на конкретной машине,может меняться по нескольку раз за сутки […] гораздо проще,и логичнее сделать просчёт как раз тогда когда он и необходим т.е. по получении команды на обновление или синхронизацию…

… или на удаление, или на установку, то есть на любой чих. Так действительно проще? Или все-таки проще каким-то образом кэшировать уже рассчитанное дерево зависимостей и пересчитывать его только тогда, когда это действительно необходимо (при обновлении world)? А ведь у нас еще и сетcustom, к обновлению пакетов из которого могут быть совсем другие требования…

Я конечно разбираюсь и мануалы тоже читаю, но почему-то ни одном мануале мне никогда не попадались разборы концептуальных вопросов. Да и странно было бы ожидать подобного от короткой сопроводительной инструкции (которой мануал и является). Как и странно ожидать от новичка, что он сразу во все въедет))

сразу во всё вьехать это наврядли конечно ) ,попробуйте в консоли наберите man emerge и гдето в районе 1235 строки весьма подробно развернутых описаний функций этой утилиты обнаружите раздел bactracing это как раз о глубине просчёта прямых и главное обратных зависимостей с УЧЁТОМ юз-флагов, и примерно такие же маны по всем утилитам входящим в сам портэж и по нему самому и всё прямо у Вас в машине,не в сети… ну и есть ещё хендбук где основное,и не только,показано на примерах использования…новичкам переходящим в генту-базед из других линукс-платформ не сталкивавшихся с таким понятием вовсе это вызывает главные трудности и непонимания…если бы Вы занимались разработкой софта или хотябы попробовали упаковать пакет для красношляпы или дэбы то уже имели бы представление о юзах (то биш,ключах компиллятора по сути,задающих вариант сборки бинарного пакета из сорцов задающих наличие и поддержку в конечном бинарнике тех или иных функций)…если более доступно,то весь функционал конкретного пакета или его часть будет представлена в конечном бинарнике решает разраб или майнтэйнер,размещающий и ведущий поддержку пакета в репозитории,а конечный пользователь “кушает что ему дали”, так обстоит дело в бинарных репозиториях основных платформ и их клонов,а вот в генту всё иначе,как в бсд, и что включить/выключить из доступных вариантов функционала пакета решает юзер,исходя из своих соображений или требований,отсюда возникает весьма сложная головоломка из основных пакетов и зависимых от них других пакетов и библиотек,ведь если включить в пакете один из двух взаимоисключающих ключей (например +gtk?-qt) то потребуются
один из двух наборов зависимостей … а так как зависить от одной либы могут несколько независимых пакетов то и производится весь просчёт и при установке и при удалении и при обновлении и при смене юз-флага для какого либо одного пакета,чтобы ничего случайно не было из системы выкинуто нужного какому либо приложению(а это уже обратная зависимость),и рассчёты на самом деле весьма сложные,и если в систему привносится что либо в обход пакетного менеджера (в данном случае портежа) то поломка всего дерева будет гарантирована ,а последствия могут быть самыми разными от мелких глюков гуя до полного краха системы…генту и всё что на её базе славится высокой скоростью работы,стабильностью при марафонских аптаймах,и возможностью тончайшей настройки всего и вся под конкретное железо и требования,за это пришлось заплатить сложностью иерархии зависимостей и жёстким контролем целостности этой иерархии в конечной системе пользователя… вот поэтому и ,ДА,проще каждый раз проверять и перепроверять перед какими либо действиями( “семь раз отмерь-один раз отреж”,или такой подход не верен по Вашему),чем содержать отдельную систему отслеживания и архивирования всех изменений ошибки в которой будут неизбежно возникать и накапливаться с течением времени и приведут к невозможности функционирования… это конечно не полно и не абсолютно точно я тут описал,а весьма популяризованно, но думаю понять поможет почему сделано всё так как сделано,и как это всё работает в общих чертах и главное что даёт в первую очередь, ведь профит при таком подходе намного превышает мелкое неудобство связанное с ожиданием подсчёта перед внесением изменений в состав системы…а вникнуть дальше самому,человеку грамотному и не ленивому умом,не составит большого труда

Я продрался через ваш ответ :slight_smile: Да, тут много всего, но давайте на простом примере - как работает Calculate Console - Обновление системы.

  1. Есть сертификат с паролем (задал для теста).
  2. По крону запускается emerge -uDN -pv @world или что-то подобное.
  3. Рассчитывает, есть обновления => значок в трее, клик по значку, и… что происходит дальше? А дальше ввод пароля и снова запуск того же расчета зависимостей, т. к. предыдущий прогон был практически вхолостую.
    Понятно, что это Gentoo тут как бы и не причем, так и дистрибутив тоже не Gentoo)) Это вовсе не кажется разумным!
    Может и частный случай, но не единственный…

полагаю пункт два и вызывает у вас недоумение?а всё просто,для чего было "изобретать велосипед"когда в системе уже имеется нужный механизм сравнения наличия изменений в оверлее учитывающий кроме основных ещё и зависимые и обратнозависимые…гораздо рациональнее использовать готовое решение,прекрасно справляющееся с поставленной и весьма непростой задачей … проще тогда уже будет написать свой пакетный менеджер,но тогда не останется сил и времени на разработку и приведение в удобоваримый вид собственно самих утилит ради которых всё и затеяно,и не зря же затеяно…хотя возможно в будущем и до своего пм доживём,с гуём и интегрированным в сами утилиты,кто знает…а пока утилиты пользуются возможностями портэжа для собственных нужд ,и Вашего,в частности,удобства,заметьте… :wink: да и полный просчёт не делается а лиш оверлея калкулэйт насколько помню,и происходит в фоне не вылазя нигде наружу,на вид…,а уже полный просчёт из всех подключенных оверлеев(и чем их больше тем дольше будет просчёт) делает емерж отрабатывая свои штатные действия…вы уже имеете дело с гит-моделью дерева портэжа ,не так давно этот рассчёт занимал несколько больше времени иногда раза в два,и особо никто не жаловался и недоумевал почему долго,дебри из версий и юзов всё таки дебри и портэжу приходится через них продираться,соглашусь что инструмент этот далёк от совершенства но он позволяет собирать каждому свою близкую к совершенству систему…но претензии по его несовершенству или непонятности почему именно так, а не просто,это уже к дэвам генты )))

В фоне? :wink: Этот “фоновый” процесс полностью отжирает одно ядро процессора! Вот компиляцию я настроил действительно в фоне, идет она долго (webkitgtk собирался больше 4х часов), зато действительно незаметно.

дебри из версий и юзов всё таки дебри и портэжу приходится через них продираться

У меня сейчас около 1000 пакетов в системе, ну пусть на каждый будет по 10 use-флагов - это много для расчета? Ну блин, не на калькуляторе же считается))

но претензии по его несовершенству или непонятности почему именно так, а не просто,это уже к дэвам генты )))

Понятное дело. Что вообще хорошего можно написать на питоне, уж лучше бы взяли старый добрый Perl что ли… Я как нибудь соберусь и все-таки попробую подключить Paludis.

Есть разные варианты кэширования просчитанного обновления. Если “заморозить” просчитанные портежами зависимости, то они будут нагружать память пока пользователь не согласиться установить обновление. Поэтому такой вариант даже не рассматривался. Какое-то время было реализовано кэширование с сохранением лога просчёта зависимостей с последующей установкой попакетно уже без просчёта. Но в этом случае может быть некорректное замещение версий пакетов из слотов. Поэтому в случае если версии пакетов удалялись зависимости просчитывались по новой. К релизу 17.6 планировали включить новый механизм просчёта, но не успели. Идея заключается в следующем. Состояние наличия обновлений будут определять утилиты сравнивая текущие версии пакетов. Для этого не понадобится скачивать портежи и просчитывать зависимости, это будет выполняться пользователем при запуске обновления. Изменённые пользователем маски пакетов будут запоминаться чтобы не происходило лжесрабатывание.
Так же можно снизить трафик опционально перестав выкачивать все портежи. Это так же даст небольшой прирост в просчете зависимостей, но ценой перехода на использование только бинарных пакетов.

Так же можно снизить трафик опционально перестав выкачивать все портежи. Это так же даст небольшой прирост в просчете зависимостей, но ценой перехода на использование только бинарных пакетов.
Александр,а если таки организовать, как я предлагал как то,только с учётом уже особенностей структуры оверлеев,…пусть в оверлее кальки и системе будет некий “нулевой пакет” в котором будет только инфа по наличию обновления(дате обновки) ,ну,в качестве маркера,и утилиты с машины пользователя будут обращаться только к нему,для проверки обновок,а уже при наличии обновок в ГЛАВНОМ оверлее кальки включится уже всё как сейчас…сильно сдаётся что подавляющее большинство текущих пользователей кальки ничего не меняют и оставляют дефолт,над этим ты с командой хорошо поработали и менять незачем по большому счёту…если это принять за точку отправления то этот пакетик будет маркером для утилит ,не более,но позволит,и уменьшить траффик,и исключит известные по багрепортам варианты когда просчёт переходит в бесконечный цикл и грузит машину до оверхед(наверняка помниш как с этим боролись,кста не слишком успешно,и сейчас зависоны не исключены,столкнулся на днях,благо помню как победить… :slight_smile: …старую мыслю оформил по новому не более )))

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

Понятное дело. Что вообще хорошего можно написать на питоне, уж лучше бы взяли старый добрый Perl что ли… Я как нибудь соберусь и все-таки попробую подключить Paludis.
а кто запрещает? ))) а если удачно прикрутить получится думаю и разрабы против не будут если хауту выложите ) давайте вместе всем миром улучшать то,что уже неплохо состряпано… а разрабы НАШЕЙ Кальки люди открытые для свежих идей,знаю не по наслышке,общался вживую,могу судить о таком…

Нулевой пакет не нужен. Информация о состоянии репозиториев, времени обновления и так хранится в ini.env файле.

Александр, а вы знакомы с проектом рефакторинга portage - pkgcore?

Я его попробовал. Конечно ещё не готов, но на моей системе задачу emerge -uDN @world отрабатывает корректно. Причём просчёт зависимостей pmerge выполняет секунд за 10 (i3-2120), в то время как emerge работает около 3 минут! И использует все ядра при этом параллельно.
Всё дело в эффективном алгоритме обработки дерева билд-файлов. И язык программирования здесь не является узким местом - Python вполне справляется с этой задачей.
Один из главных пожирателей CPU в Portage при просчёте зависимостей - парсинг bash-кода билд-файлов, причём в один поток. И в Pkgcore на это уделено специальное внимание - там для разбора билд-файлов используется не запуск bash, а специальная библиотека snakeoil.
Команда pkgcore отличные цели поставила:

  • сохранить формат билд-файлов
  • обеспечить прозрачную полную совместимость с gentoo/Portage, в том числе и с конфигами Portage
  • добавить поддержку альтернативных форматов конфигов

Мне кажется, что цели pkgcore гораздо правильнее чем в paludis - переработать существующий инструмент вместо изобретения несовместимого своего.
Так и подмывает предложить Вам подключиться к проекту Pkgcore и внедрить его в Calculate!

Что-то мне подсказывает, что комментариев от господ разработчиков мы не дождемся :slight_smile:

Мне кажется, что цели pkgcore гораздо правильнее чем в paludis - переработать существующий инструмент вместо изобретения несовместимого своего.

Тут согласен. Причем стоит наверно добавить, что Paludis - это вовсе не единственное в своем роде решение, другие gentoo-based дистрибутивы создают свои инструменты в борьбе с кривизной Portage (Entropy в Sabayon например). Так что в отношении Calculate это вопрос ресурсов* и наличия разработчиков, которые могут кодить еще и на C/C**, а не только на Python))
[*] вы где-нибудь видели, чтобы Бизнес стремился к идеалу? Хоть как-то работает - и б-г с ним :slight_smile:

Не понимаю, при чем тут умение программировать на C/C** ?

и наличия разработчиков, которые могут кодить еще и на C/C**, а не только на Python

Тот же Paludis написан на C**, а ни разу не быстрее, чем Portage.
Детские отговорки про Python и про сложную задачу просчёта зависимостей не принимаются.
Сама задача вычислительно по силам для современных процессоров. Тут проблема в грамотном алгоритме.
А вот решение с кэшированием зависимостей я считаю неоправданно громоздким и хрупким. Ведь в системе и так уже всё есть - база установленных пакетов, дерево билд-файлов, конфиги менеджера пакетов. Причём объём всего этого по современным меркам невелик - не более 10^7 узлов-записей.
Надо только научиться всё это быстро обрабатывать.

вы где-нибудь видели, чтобы Бизнес стремился к идеалу?

А бизнесу от прочистки тормозов Portage и выгода может получиться.
У нас вот, в организации, возможно и применили Calculate вместо Debian/Ubuntu, может даже поддержку у разработчиков купили бы.
Но вот попробовали… и сразу наткнулись на две детские проблемы:
# Оказалось невозможно инсталлировать Calculate в изолированной сети с закрытым git
# Очень (!) долго для binary-дистрибутива считаются зависимости. Само обновление зачастую происходит быстрее, чем вычисление списка обновляемых пакетов.

И вот, замечательные потенциальные возможности продукта оказались незамеченными!
Так что бизнесу тоже выгодно улучшать свой продукт.
Надо только найти способ монетизации своих усилий.
Вот, например, ребята на рефакторинг Vim (Neovim) нашли ресурсы!
И здесь можно придумать, например такую схему. Какая-то команда, скажем Calculate, под свои гарантии, организует краудфандинговую компанию, подключается к вменяемому проекту, например - Pkgcore, и совместными усилиями проект доводится до ума. И всем - польза.

CL не продаём, платную поддержку не оказываем, планов по грандиозному внедрению не ставим, акцент ведём в первую очередь на свои задачи, благо они у большинства компаний совпадают.

Для установки системы интернет не нужен. Вы можете подготовить образ с необходимым набором ПО и установить. Делается это прямо на флешке. При желании на ней же можно создать несколько вариантов установки.

Не знаю в какой момент вы тестировали, но определённые тормоза в просчёте зависимостей были убраны. Например раньше при каждом выполнении emerge было обращение к зеркалу и скачивание файла Packages (сейчас он весит 11 Мб). Emerge пытается определить по заголовку что файл не изменился но делает это не всегда эффективно и работает к тому же только с http. При проблемах с интернетом и вовсе могли появляться длительные задержки. Сейчас скачивается архив Packages (1,3 Мб) и только один раз вместе с обновлением портежей.

Pkgcore посмотрим.

Pavel Zhukov wrote:

Детские отговорки про Python и про сложную задачу просчёта зависимостей не принимаются.

Это не детские оговорки, увы, за примерами дальше этого дистрибутива и ходить не нужно. Для какой-то своей ниши оно может и неплохо, но когда на нем начинают клепать системные инструменты, то гарантированно начинается лажа проблемы.
Честно говоря начинаю жалеть, что выбрал Calculate для знакомства с gentoo-based, тут ни форума толкового нет, ни документации человеческой (например, про шаблоны никакого намека на howto в принципе не существует)… нет ничего хорошего, кроме репо с бинарными пакетами.

(например, про шаблоны никакого намека на howto в принципе не существует)

http://www.calculate-linux.org/projects/ru/boards/47

Про Python.

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

Мне кажется, что это опрометчивое высказывание. У меня есть примеры отличных инструментов как на Python, так и на C/C**, причём в разных областях, а также и совершенно негодных, написанных на разных языках. И использование какого-то конкретного языка программирования ничего не говорит о квалификации разработчика. Мало того, сейчас часто системы разрабатывают на смеси нескольких языков по вполне обоснованным причинам.

Про Calculate.

… нет ничего хорошего, кроме репо с бинарными пакетами.

Это неправда.
Есть ещё предсказуемая и надёжная операционка с возможностью гибкого выбора.
Есть аккуратно реализованная совместимость с Gentoo, а значит - возможность взаимопроникновения знаний между этими дистрибутивами.
Есть налаженная схема сборки своих коллекций бинарных пакетов (а значит можно Gentoo/Calculate использовать на медленных/старых машинах без компиляции).
Есть удобный способ заворачивать любой софт в пакеты (хотя это заслуга Gentoo). Попробуйте сделать такое грамотно в Debian/Ubuntu - сам на работе профессионально вынужден этим заниматься - это ж кошмар кошмарный - вот где действительная лажа!
@ @
На мой взгляд, Calculate - это замечательный проект с правильными целями.
Вообще, задача сделать и постоянно поддерживать в тонусе дистрибутив-экосистему - огромна.
А здесь я вижу классный результат! Вы же не думаете, что все, кто пользуется дистрибутивом - сумасшедшие, которые насильно себя истязают, а потом рассказывают всем сказки, как им хорошо страдать в Calculate?!
Причём, ведь разработка Calculate, насколько я понял, ведётся в интересах конкретного (не ИТ) производства, и поэтому откровенную туфту ребятам сделать не дадут.
@ @
Да. Кальке есть ещё к чему стремиться, но уже сейчас ею приятно пользоваться. Мне, например, гораздо приятнее, чем Debian, Ubuntu или Arch. В Gentoo/Calculate как-то всё удобно на своих местах расположено.
И, как правило, как написано в документации, так и работает. Бывают конечно мелкие косячки. Но разрешимые достаточно легко.

По сути, Calculate - это Gentoo с уменьшенными затратами на сборку пакетов и некоторыми принятыми по умолчанию безопасными решениями (которые, кстати, пользователь может спокойно, без геморроя, как в binary-дистрибутивах, изменить).
Можно сказать, что Gentoo очень неплохо звучит в исполнении Calculate!
Отсюда вывод, что надо пользоваться документацией Gentoo и понимать, какие нерешённые (или недорешённые) задачи Gentoo и как решают дополнительные инструменты Calculate.
Поэтому неплохо сначала пощупать Gentoo, а потом Calculate.
@ @
А так, да, трудно пока оставаться в рамках исключительно экосистемы Calculate.
Я вот, например, рассматриваю для себя Calculate, как бинарный профиль Gentoo, некий инструмент для генерации конкретных решений. Может быть это и есть правильное и важное место для Calculate.
@ @
А вообще, чрезмерно эмоционировать - вредно для реального понимания проблемы.
Более того - бурное личное негодование - причина остановиться и осмотреться.
Гораздо полезнее внимательно поискать, что сам лично не понимаешь и поточнее поставить вопрос.

jone j wrote

Честно говоря начинаю жалеть, что выбрал Calculate для знакомства с gentoo-based, тут ни форума толкового нет, ни документации человеческой (например, про шаблоны никакого намека на howto в принципе не существует)… нет ничего хорошего, кроме репо с бинарными пакетами.

да…видимо надо было начать уже совсем с того что попроще?из семейства Gentoo,и оптимально будет пожалуй с ChromeOS/ChromiumOS,шутю,таки да,но не смейтесь,это тоже Gentoo-based дистрибутивы и гуглю не смущает всё то что вы к минусам приплели,вся мешанина из разных языков внутри системы и системных пакетов…настраиваемость отдельных компонентов как и адаптивность системы в целом,совместимость с гигантской базой,быстрота работы,стабильность независимость системы от "прогрессивных"разработок интегрированных в другие базы практически насильно,интегрируемость с сетевыми технологиями и т.д и т.п,как раз то,что,судя по всему,вызывает у Вас ступор,привлекло и помогло сделать систему и с успехом распространять предустановленно на простых машинках…а “Калька"идёт своим путём,сделанная изначально для конкретных нужд и казалось бы узконаправленной,позволяет применение в весьма широком спектре от хоуммалтимедиа и гейммашин до центра управления станками чпу,практически в дефолтном состоянии…ну и напоследок я запамятовал название ,но гугл Вам поможет,есть такой гибридный дистр вроде генту но построенный на рпм а не портэже,вот Вам подошёл бы,и вопрос отпал бы сам собой… а по большому счёту,RPM vs PORTAGE,ответ прост- RPM в анусе по любасу,ибо сам по себе вовсе не умеет зависимости решать и автоматом ставить,это за него делают надстройки типа YUM и прочие,в разных дистрах на базе рпм… так что вопрос то Ваш изначально ниочём…и таки подучите уже матчасть,походу Вы и того чем пользуетесь глубоко не осмысливали…отсюда у Вас и вопрос такой возник"почему рпм просчитывает зависимости быстрее портэжа” да потому что он их и не считает,а получает из репо список файлов необходимых в системе для работы того или иного пакета и выводит его в консоль,список файлов,Карл!,не пакетов заметьте, а только файлов… а дальше уже не RPM-a дело что с этим списком делать, этим надстройка-оболочка занимается тот же YUM,хотябы, самый вменяемый в плане сохранения зависимостей или другой какой,не такой строгий…