Вопрос, вынесенный в заголовок темы, думаю не раз возникал у обладателей слабых машин, не желающих тратить время на сборку системы. И проблема даже не в этом.
Фактически, если Вы устанавливете себе новый релиз и в нём Вас что-то не устраивает, вы занимаетесь пересборкой, доустановкой необходимых пакетов или удалением ненужных. И с этого момента Вы теряете необходимость в новых релизах Calculate, так как второй раз заниматься этим же желания нет. Если есть мощная машина, то builder/scratch поможет. А если нет?
Чем ещё хороша gentoo – отсутствием ежегодных/полугодовых релизов. Она всегда стабильна. Буквально на днях обновили сервак, работающий без обновления два с лишним года!!! Без переустановок системы, без проблем. Конечно, есть Arch, есть Sabayon, но всё равно это не то…
Конечно, свой репозиторий бинарных пакетов требует решения многих задач, какие USE флаги и для каких пакетов использовать, для какой архитектуры собирать. Думаю, если исходить из того, что слабые машины в основном на i686, пока как эксперимент оставить одну архитектуру. USE-флаги обсудить на форуме. Было бы желание.
Возвращаясь к теме топика – я первым отвечу: только за и обоими руками!
В качестве эксперимента, мы можем выложить бинарные пакеты Calculate Linux 10.2.
Calculate Linux 10.0 поддерживает бинарный репозиторий и может с него обновляться без дополнительных настроек.
По поводу USE флагов, они будут совпадать с дистрибутивом. Т.е. в текущей схеме у нас несколько репозиториев под каждый дистрибутив.
Вопрос только в том, что портежи непрерывно меняются и для установки пакетов с измененным rX уже потребуется компиляция.
Да не так уж и часто они обновляются. Как вариант, можно раз в какой-нибудь период пересобирать под текущее дерево портежей и ещё вместе с пакетами держать дерево, с которого была произведена сборка.
По поводу бинарных пакетов – если есть возможность, выкладывайте. Попробую поэкспериментировать.
можно раз в какой-нибудь период пересобирать
Сейчас такой период - дата релиза.
Не понял… Период (день, неделя, месяц, год…)
ещё вместе с пакетами держать дерево
С этим сложнее, портежи обновляются во время сборки.
Опять не понял… Перед сборкой обновили дерево, пересобрали пакеты, всё это положили рядом. Кто захотел, обновил дерево не с оффициального сайта, а с вашего. И тут же поставил с вашего сайта бинарники. Или я что-то неправильно понимаю?
Период - это время, через которое наш ПК напрягается и собирает все от начала до конца
Опять не понял… Перед сборкой обновили дерево, пересобрали пакеты, всё это положили рядом. Кто захотел, обновил дерево не с оффициального сайта, а с вашего. И тут же поставил с вашего сайта бинарники. Или я что-то неправильно понимаю?
rsync-сервер поднимать? Ну пожалуй только это может быть выходом.
А что делать с обновлением Qt-core. Установка нового пакета может потребовать пересборки ряда других. Как здесь пользователю не ошибиться?
Период - это время, через которое наш ПК напрягается и собирает все от начала до конца
Раз в месяц?
rsync-сервер поднимать? Ну пожалуй только это может быть выходом.
Ну или обойтись малой кровью и держать снапшот на этот день для emerge-webrsync
А что делать с обновлением Qt-core. Установка нового пакета может потребовать пересборки ряда других. Как здесь пользователю не ошибиться?
Не понятно, зачем пользователю обновлять один Qt из оффициального репозитория. Надо чётко разграничить и оговорить сразу: если Вы начинаете что-то собирать руками у себя, то Вы автоматически отказываетесь от наших бинарников, в противном случае мы не гарантируем стабильную работу системы.
Если сидим на бинарниках, то обновляемся вместе с вами, в день выхода релиза.
Не понятно, зачем пользователю обновлять один Qt из оффициального репозитория. Надо чётко разграничить и оговорить сразу: если >Вы начинаете что-то собирать руками у себя, то Вы автоматически отказываетесь от наших бинарников, в противном случае мы не >гарантируем стабильную работу системы.
Если сидим на бинарниках, то обновляемся вместе с вами, в день выхода релиза.
Ок, только сколько времени займет такое обновление на нетбуке. У меня на ПК обновление KDE4 из бинарных пакетов заняло 40 минут. На стандартное calculate-way у меня уходит не более 6 минут, причем обновляется вся система.
Ок, только сколько времени займет такое обновление на нетбуке. У меня на ПК обновление KDE4 из бинарных пакетов заняло 40 минут. На стандартное calculate-way у меня уходит не более 6 минут, причем обновляется вся система.
Только Вы не учитываете один нюанс: образ calculate уже скомпилирован как надо Вам. А сколько времени ушло на подготовку образа?
А если взять систему целиком? Начинаем тогда опять лишнее удалять, нужное добавлять, ни неважно где, на рабочей системе, или в CLS. Если нас не устраивает список пакетов в образе, мы вынуждены делать одну и ту же работу с каждым обновлением образа calculate.
Тут надо выбирать – или ты сидишь на бинарниках, или пересобираешь систему и
уходишь в свободное плавание. Смешивание и того, и другого – это чревато, я
тут согласен.
Только Вы не учитываете один нюанс: образ calculate уже скомпилирован как надо Вам.
И что получается, то что предлагаете Вы - одни бинарные пакеты, за рамки которых ничего доустановить уже нельзя, одна архитектура, в которой ещё встречаются проблемы с PAE (4Гб ОЗУ и более), USE-флаги, которые тоже непонятно как поменять.
И что получается, то что предлагаете Вы - одни бинарные пакеты, за рамки которых ничего доустановить уже нельзя, одна архитектура, в которой ещё встречаются проблемы с PAE (4Гб ОЗУ и более), USE-флаги, которые тоже непонятно как поменять.
Однако, это не мешает выпускать Debian, Mandriva, Suse & etc…
Вот по поводу того что с бинарников дольше обновление идёт не поспоришь. У меня один сильный сервер я на нём скомпилил нужные пакеты и думал так каждый раз с 3х остальных обновлять. Ага… Раза в 3 больше времени уходит на полное обновление! Спасает distcc…
Если есть запал, то помогите парням из Calculate и создайте свою монолитную ветку! В принципе можете начать с ветки для нетбуков, чему большинство пользователей calculate порадуются, ну а если никаких нареканий не будет, то я думаю разработчики не будут против помочь… Правда, Александр?
Ну так
CLS + интерактивная сборка + свой уникальный набор пакетов + декорации = ОС для Netbook, которую можно сразуже потестировать на своем железе. А если как Вы говорите ограничиться 32-битной архитектурой, задача становится еще проще.
С распространением также проблем нет. Рекламировать проект можно на нашем сайте. Система-то действительно может быть интересной.
Для каждого профиля на мощном сервере заведена “бинаферма”, которая обновляется примерно раз в месяц. Из нее же делаются стейжи и бинарники.
После чего, наша утилита автоматического обновления обновляет все сервера. Когда их было 5 то это было бессмысленным занятием, но сейчас их больше 100 и это сильно экономит время. Кроме того обновляя “бинаферму” видно что там поменялось, что добавилось и, что следует ожидать после обновления сервера.
В принципе, все это довольно запутано и решение для простого пользователя сделать довольно сложно. Такая система используется год и честно говоря уже надоела.
Тема бинарных пакетов в Portage не очень то и раскрыта. Ее надо дорабатывать. Что я вижу в идеале:
Указываем в Portage путь где хранить и откуда брать бинарные пакеты (ftp, rsync и т.д.)
Указываем базу данных (mysql, sqlite, и т. д.) в которую он будет записывать информацию о пакетах: путь по которому пакет доступен, USE флаги, версия и т.д.
Что получится в итоге:
Обновляем первый сервер. Создались бинарные пакеты. Теперь сервер с таким же профилем обновится полностью из бинарников.
Обновляем второй сервер с отличным профилем. Большая часть пакетов обновится из бинарников, остальное будет собираться и заноситься в базу с другой версией или другими USE флагами. Теперь такой профиль так же обновится полностью из бинарников.
И так далее с остальными профилями.
В рамках компании, где куча серверов это будет просто замечательно. Все будет делаться само, достаточно только настроить.
Ну, а вот для общественности не знаю… В принципе почему бы и нет? Если таких “хранилищ” будет много, то Portage вообще может шерстить по всем в поисках нужной версии бинарного пакета. И в конце концов мало кто будет собирать Gentoo полностью из исходников.
Ну, а вот для общественности не знаю… В принципе почему бы и нет? Если таких “хранилищ” будет много, то Portage вообще может шерстить по всем в поисках нужной версии бинарного пакета. И в конце концов мало кто будет собирать Gentoo полностью из исходников.
Не нужно много хранилищ, есть же торрент!
В общем, механизм работы представляется в следующем виде: после компиляции пакета он складывается в локальный кеш на компьютере, под который отведено какое-то количество места, и сразу же на сервер раздачи отправляется сообщение, что у такого-то пользователя есть такой-то пакет, скомпиленный с такими-то параметрами.
Соответственно перед установкой пакета просто проверяется его наличие(с нужными ключами) на торренте, при наличии он скачивается и устанавливается.
И если пользователей со скомпиленными пакетами будет достаточно большое количество, вот тогда действительно мало кто будет собирать пакеты полностью. По крайней мере самые распространенные уж точно.
calculate-репозиторий бинарных пакетов вещь конечно очень нужная.
По поводу используемых USE, думаю не сильно ошибусь, если скажу, что достаточно солидный процент пользователей не занимается значительным изменением USE-флагов и списков установленных пакетов. Кроме этого, большинство USE-флагов сказываются лишь на нескольких пакетах, обновлению остальных из бинарников ничто не мешает. (Как вариант - в репозитарии установить что-то типо функции поиска: указываешь какие флаги изменял и остаются только те пакеты на которые эти флаги не оказывают влияния и можно качать для обновления бинарники.)
Для тех же кто значительно меняет систему более актуален скорее будет другой вопрос, который так же был озвучен в первом сообщении:
“Фактически, если Вы устанавливете себе новый релиз и в нём Вас что-то не устраивает, вы занимаетесь пересборкой, доустановкой необходимых пакетов или удалением ненужных. И с этого момента Вы теряете необходимость в новых релизах Calculate, так как второй раз заниматься этим же желания нет.” Конечно, на это уходит больше времени, чем на пересборку пакетов из исходников…
Предлагаемый вариант обновления системы http://www.calculate-linux.org/main/ru/system_update_guide (из ISO-файла) подразумевает полную идентичность системы предлагаемой на диске, даже в случае использования emerge -u world сталкиваемся с проблемами, как http://www.calculate-linux.org/boards/16/topics/2925
Так что для облегчения обновлений кроме репозитария бинарников возможно стоит придумать и более “прозрачный” способ обновлений, учитывающий все пользовательские изменения системы??
Так что для облегчения обновлений кроме репозитария бинарников возможно стоит придумать и более “прозрачный” способ обновлений, учитывающий все пользовательские изменения системы??
Из пакета, установленного в системе можно собрать бинарный пакет. Ничего после этого не мешает его установить в новой системе. Осталось только отработать процесс переноса софта в новую систему во время установки.
По флагам и пыр хотелось бы отметить следующее.
# Никто из мэйнстрима не занимается отладкой ядра. Раздел Kernel hacking должен содержать только Magic SysRq key и Allow gcc to uninline functions marked ‘inline’. Должны быть убраны все упоминания о коредампах, дебагинге и пыр. Ядро работает шустрее.
# CFLAGS/CXXFLAGS должны включать -fomit-frame-pointer. Для, почти всех, процессоров нужно явно указывать -mfpmath=see (список в man gcc).
Торрент есть, но не у всех есть доступ.
Антон Б wrote:
