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

Это уже есть. В любой момент времени.

Лично я - всеми членами своего тела - против этой затеи. ;D
Хотите релиз - получите Calculator - тот эе gentoo.
Зачем ещё огород городить? Или нам ещё один Suse или
Mandriva, только sourced-base нужен? Тогда - велком
на FreeBSD, хотя я тут тоже загнул...

ВАМ не хватает внимания к дистрибутиву? Дополнительных пользователей?
Всё описанное вами - лично ВАМ зачем нужно?

Странноватая идея. Сейчас есть еженедельные автогенерируемые релизы, а то что предлагаеш ты - требует неособо много ума, но сильно много времени, сил да и вообще должно быть кому-то нужно. Нормальный релиз требует всесторонних тестов на совместимость пакетов вошедших в срез, а к тому времени как всё протестируют проходит достаточно много времени, чтобы сразу после установки огрести проблемы. Причём непонятно отчебы это ждать стейджа потом ещё целый год. От них и отказались от того что заняться некому, да и смысла особого нет... Но если у тебя есть желание - пожалуйста, присоединяйся к разработчикам и делай релизы.

Лично я вижу тут 2 позиции:
1. "Раскрутка" дистрибутива приведет к повышению числа пользователей, т.о. возможное ускорение роста и развития. Но, это только возможно.
2. Та ситуация, которую я вижу сейчас - медленное, равномерное, и скорее всего вдумчивое развитие дистрибутива, что со временем позволит заиметь достаточно проработанную структуру и базу документации...

Думаю, что все таки лучше медленно, но верно.

Эмм... это умопомрачительно:)
Идея то хорошая. Только давайте специально задерживать релизы (для подогревания публики) и выпускать их намеренно с ошибками и чтобы юзер просто так не смог обновиться. Это увеличит посещаемость форумов. Да, а замораживать обновление portage (!!!) - идея просто шикарная... Она придает смысл существованию релизов. Только надо еще убрать emerge -uDN world, и все будет супер.

Какой кошмар... лично я вижу смысл и огромное преимущество gentoo перед другими дистрибутивами linux - все самое новое и самая легкая сборка всего этого из исходников без разрушения инсталяции. Вы же хотите лучшее от дистрибутива убрать, заморозить, разбить на релизы... Самое интересное есть же возможность штатными средствами gentoo создавать свои дистрибутивы/срезы.. начиная с введением своего дерева портежей.. займитесь? будет у вас самое стабильное. только надо ли это комунити gentoo? если надо что то стабильное, есть монстры, которые этим занимаются очень давно и успешно - rhel/debian .. что то поновее и пораспиареннее? ubuntu...

Вот что не помешало бы по моему мнению в gentoo - это чуть побольше автоматизации сборок и обновлений, само собой не по умолчанию...:
* после emerge каждый пакет выдает текстовые рекомендации.. что то являются рекомендацией (например прописать в сервис автозагрузки), что то обязательным к исполнению (например запуск revdep-rebuild или python-updater).
Сам бог велел навести здесь порядок, определить категории, необходимость или рекомендация, зависимость действий от установки или обновления.. а может какую опцию для отключения автозапуска (ну несколько уровней автозапуска действий) потому зачастую сборка может происходить в chroot на левой машине ;) и уж точно службы запускать там необходимо но может понадобиться запуск обновления баз данных конкретного приложения, если они не используются...
Сложно, но можно попытаться описать условия автозапуска.
* все подумываю заняться написанием скриптов автосборки бинарных пакетов обновлений в chroot, с отчетом о неудачах но попыткой продолжения сборки.

Куда то не в ту степь вы ушли...
эти утилиты просто соибрают бинарные пакеты в стандарте дистрибутива redhat.. ну точно не gentoo, зачем они в gentoo? тем более они актуальны именно для бинарных дистрибутивов.
P.S. кстати sandbox в gentoo это чистое окружение или просто копия ткущей инсталяции? судя по необходимости в запуске revdep-rebuild, просто копия. Если нужно чистое окружение, никто не мешает собирать каждый пакет в chroot на stage3 (по уму какой-то конкретной версии), с повторной установкой уже созданных ранее необходимых зависимостей (emerge -k) и будет вам фактически то же самое, что делают эти утилиты. Только надо ли это?

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

О, так они перестали терь выпускать релизы? А я и не слышал этой новости.. Зашёл недавно на страницу дженту там последняя версия 2008.0, ну думаю всё - помер отличный дистрибутив и разработчики его забросили..
Устанавливал с последнего среза как и полагается, но всё же. Многие пользователи именно так и подумают, что дистриб мёртв.. Да и дополнительная реклама ему бы не мешала. Не будешь же рекламировать каждый срез :) уж не знаю с какой же он переодичностью там выходит, но представляю.. :)

Если кто-то задумал установить себе Getnoo, то обязательно доберётся до HandBook, а там подробненько так прописано, что скачать, откуда скачать, что сперва, что потом...

К тому же Gentoo "искаропки" ориентирован на тех, кто читать умеет и не боится "многабукаф"...
Популяризацией же дистрибутива лучше заниматься тем, кто его "осилил". Ибо лучшая реклама - личный пример. ;)

Что же касается "релизов" - "их есть у gentoo"^

http://mirror.yandex.ru/gentoo-distfiles/releases/x86/

На популярность влияет в первую очередь количество вливаемых денег, во вторую -- отсутствие проблем у нулёвых или с небольшим опытом пользователей, ибо таких большинство, и именно им нужна популярность. Чтобы не думать, чего делать они в принципе не умеют. Тот, кто думает, ставит цели, определяет задачи, и подбирает (по своим критериям значимости) инструмент для достижения целей. Вот и вся недолга. В этом "секрет" популярности убунты и появления новой категории пользователей -- убунтушников. То есть, есть винднавозники, макосисты, юниксоиды, "тру-юниксоиды", линуксоиды. А еще есть убунтушники. Отдельная статья. Ладно, это вопрос политический.

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

Чего не хватает просто Gentoo, которым я пользуюсь уже лет 5 примерно:
- портежа на sqlite
- помошников на написание внятной документации
- внимания к появляющимся достойным пакетам вне портежа.
- и (понимаю, что это крайне трудно) выкидыванию хлама (пакетов) из портежа, потому что рано или поздно наступит граница управляемости. Будем надеяться, что не очень скоро...

Таковы соображения.

От себя скажу, что, если рассматривать идею, как (мне кажется) её понимают большинство тут отписавшихся, т.е. хранить сами описания в БД как средство ускорения работы portage это по меньшей мере глупость, решит одну проблему, породит сотню. Но кто сказал что нужно быть максималистом? нет нужды прыгать из крайности в крайность, нужна золотая середина.
Да, текущая реализация портежей - это огромный объем на диске (0.3-0.5Гб: у меня почти нет оверлеев du -sb /usr/portage/ --exclude=/usr/portage/distfiles --exclude=/usr/portage/packages* -> 347 015 942) и офигительные для таких задач объемы перечитываемых данных. И этот объем растет и будет расти. Я уже как то писал, если бы портежи не тормозили, то можно было бы на них каждую мелочевку (плагины те же у пакетов) реализовывать, очень логично и естественно.
Я не разбираюсь в реализации портежей, я как пользователь то далек от понимания работы но:
(тут варианты могут не пересекаться, это только идеи, но может тут есть те, кто является если не разработчиком, но тем, кто может подтолкнуть развитие портежей в нужном направлении, очень на это надеюсь)
1. Кто сказал что .ebuild нужно упразднить как формат и разрабатывать новый? ничего подобного, требуется решить проблему необходимости их (и мета файлов) постоянного сканирования.
2. Кто сказал что нужно хранить ВСЁ дерево в БД? львиный его объем (официальные портежи) редактировать в здравом уме мало кому понадобится, все пользуются оверлеями. Вот и пусть портежи поддерживают одновременно БД и файлы.
3. Кто мешает разработать файловую систему (fuse более чем достаточно) как прослойку между БД и /usr/portage
- основная (по моему мнению) проблема реализации параллельной прослойки БД к файловому описанию - это своевременное отслеживание изменений (хотя make.conf и все его инклюды тоже можно было бы по отслеживать на изменения), учет изменения переменных окружений портежей (реально это так необходимо?), меняющих структуру портежей (тот же путь к оверлеям)
- все равно без ebuild xxx.ebuild meta (emerge --meta) нет смысла использовать ебилд, ну так пусть в этот момент и апдейтится БД.
- разве в API файловой системы нет возможности сканировать изменения в дереве fs?
4. Надстройки над портежами типа eix (или тот же kuroo, интересная GUI для портежей, както пользовался) старательно сканируют базу под себя.. но её приходится постоянно обновлять, смысл тянуть сразу несколько баз когда достаточно сделать одну. Тем более изобретать паровозы, свои форматы БД и т.д... глупость, и их базу никто больше не использует.

Итого, ебилды трогать нельзя - это удобно и привычно. Необходимо изменить способ хранения метаинформации и внутренней БД как минимум зависимостей пакетов, плевать что, sql или нативное что-нибудь, лишь бы быстро и без велосипедостроения + поменьше бы зависимостей (вариант с fuse было бы интересно, но это значит в ядре должна быть соответствующая поддержка, кто-нибудь скажет ну нафиг :) хотя это точно не я).

1) Хотите популяризовать? - Присоединитесь к "команде" перевода оффициальной документации.
2) Исходя из опыта могу сказать, что сильно напряжно с каждого синка portage выгугливать и выискивать как пофиксить какие-то баги и несборки. И даже на stable c нуля сборка системы уходит в циклические зависимости. Проблема недостаточного тестирования закомиченых ебилдов?
Как пример простой emerge -avuN system world на системе не обновляемой ~ 2 года превратился в головную боль. То питон обновился, то python-updater не нашёл пакет, то ещё что-то в итоге система заброшена.
3) Бинарники нужны хотя бы для быстрого разворачивания gentoo системы, в 2005.1 шёл диск вкомплекте, вполне удобно.

alexxy, как продвигаются дела с 1) projects.gentoo.ru 2) подписание ssl сертификата ?

* evadim, греп, сид, и т.д. это все таки прошлый век.. с линейной трудоемкостью, к тому же кто мешает сделать фреймворк тех же комманд, использующих sql и соответствующую базу данных, со всеми плюшками, включая индексы. Хотя решать задачу лучше всетаки более заточенными для этого средствами, иначе будет только хуже.
* 5копеек, про Обновление устаревшей инсталяции gentoo....
* alexxy, да use флаги (и не только, и LINGUAS и еще что-нибудь из make.conf) добавляют в граф новые ветки...
На сколько я понимаю, при попытке установить пакет проводится анализ зависимостей + то что поставлено + что-то для решения блокировок. Если база данных уже есть, то что же тогда читается с диска сотнями мегабайт при любой emerge? мне казалось что повторно читаются все ебилды, так или иначе затрагиваемые (а может и все) при обработке указанных пакетов. Что хранится в базе, которая сейчас собирается?
* alexxy, про бинарные пакеты, хотелось в отдельной ветке спросить, но спрошу тут, если я собираю пакет с -b с одним набором use-флагов, он сохраняется в /usr/portage/packages, а затем собираю с другим набором флагов, старый затирается? нет ли какой-нибудь возможности использовать общий packages для различных комбинаций инсталляций (про возможность сохранении информации chost тем более было бы интересно), а то сейчас для каждой инсталляции на сервере приходится повторно пересобирать свой архив packages, даже если меду ними много пересечений (пробовал использовать общий, получил увеличение проблем с необходимостью запускать revdep-rebuild). А может я не так проблему решаю?

Посмотрел я повнимательнее на ебилды, стало грустно. По моему мнению, корень проблемы в том, что ебилды - это полноценные скрипты, где логику зависимости depend и rdepend нельзя однозначно и всегда описать простым условием (если установлен use A то включить пакет B), там может (и присутствует) полноценный код с циклами, условиями (в т.ч. небось и от того, что уже установлено и что может быть установлено). Можно конечно придумать базу описывающую зависимости на определенную комбинацию текущих use (если быть точным на содержимое вывода emerge --info), будет очень быстро вычисляться зависимости но... практически не бывает ситуации, когда ebuild запускается без изменения этого состояния, либо после --sync изменился профайл, либо пользователь прописал какому-нибудь пакету очередной use флаг (а приходится кстати, для удовлетворения этих зависимостей), и в этот момент придется перестраивать всю базу (а это фактически тот же запуск на исполнение всех ебилдов). Да фактически установка пакетов уже меняет этот состояние, а значит необходимо опять перестраивать базу.
P.S. Так ли это актуально, определять зависимости произвольным кодом?

Теперь еще вопросец.. а нельзя ли прекомпилировать все ебилды в один большой ... запускаемый файлик :) линейно загружается в память и быстренько там исполняется.

Люди. Вы какие-то странные. Ебилды в один большой бинарь. Портаж в СУБД. Тормознутость портажа, имхо, на 50% из-за питона, не в обиду krigstask'у будет сказано, а на остальные 50% из-за древности и запутанности кода. Наверняка если переписать его с нуля, да еще лучше не на скриптовый язык, а на компилируемый - то работать будет быстрее и лучше (если думать головой, а не как с палудисом). Но это время, да и читаемость кода теряется.

Можно много оптимизаций сделать. На самом деле, сам по себе source файла - не так ужастно, это быстро. Другое дело что некоторые особо монструозные еклассы (Бааальшой булыжник в огород кде-тим) очень любят делать излишние тяжеловесные операции в коде инициализации, не особо задумываясь о том, какие потери производительности при банальном source'е это вызовет. А как вы верно отметили - source необходим для просчета зависимостей. Тут скорее дисциплина и стандартизация синтаксиса - выносить например, всякие инициализации не-системных переменных (т.е. не DEPEND/IUSE и т.п.) в pkg_setup или аналог и т.п.

Хотя тут тоже есть нюансы. Вообщем идей можно придумать много. Но пока это возня на форме - ничем кроме идей они не станут. Сделайте GLEP, сформулируете четко и ясно: зачем, почему, что лучше, что хуже, как обрабатывать какие ситуации, как реализовать существующий функционал. И запостите на gorg. Вот это будет подход, а это - пустые разговоры.

А можно реализовать что-то примерно такого:
во время установки программ(допустим ставится пакетов 20) на установке одного из них мы принудительно устанавливаем паузу. Пауза не во время компиляции, а перед fetch. Для чего это нужно - к примеру запустил emerge -e world, а по прошествии часов 5 нужно срочно выполнить ресурсоёмкие операции. Тут ставим emerge на паузу, делаем всё что надо, продолжаем. Опять же всё это можно сделать легко: ожидаем нажатия определённой клавиши, как только оно осуществленно, то на следующем за текущем пакетом ставим паузу.

Тормоза портежа исключительно из-за активной работы с диском... повторный запуск (когда весь портеж в кеше) или размещение в tmpfs ускоряют работу почти до долей секунд.