если делать бинарный репозиторий для генты

Лучше -bin, иначе при запуске emerge <пакет> будет каждый раз ругаться, мол уточни какой именно пакет ты имел в виду. Да и инфа о настоящей категории потеряется, если ты все пакеты в одну поскидываешь.

конечно -bin, это устоявшаяся практика, если конечно пакет не становится бинарным по юзфлагу 'bin' или 'binary'.

«настоящая» категория и не нужна, а вот коллизия имён это да

интересно, а в portage можно задать приоритеты категориям?

интересно, а в portage можно задать приоритеты категориям?

Приоритеты чего? Порядка пакета при сборке?

а что, если в бинарный реп класть более крупные куски софта? скажем, binary-core/stage, binary-de/kdebase, причём второй со всеми своими зависимостями до binary-core/stage

порядка выборки по именам

Какой выборки? Если ты говоришь портежу установить пакет и их два с одинаковым именем, он тебе скажет уточнить. Никакого порядка выборки там не будет.

выборки по категории, т.е. если категории нет, то всегда выбирается самая приоритетная

Тебе придётся с зависимостями разбираться. Просто скопировать зависимости гентушных пакетов не выйдет, потому что твой пакет сможет зависеть и от сорцовых kdelibs, и от бинарных, и от бинарного kdebase например.

Выборка при каком действии? Опиши пошагово.

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

Ещё раз, это при каком действии? При emerge -s, emerge, emerge -uDN или что?

если emerge передаётся только имя пакета без категории, и в случае обнаруженной коллизии имён emerge не выводит список коллизий, а выбирает тот вариант, чья категория самая приоритетная

насколько я понял, такой фичи у портежа нет за ненадобностью

проснись

насколько я понял, такой фичи у портежа нет за ненадобностью

Я думаю, как раз наоборот. Такой фичи нет из-за её вредности. Нельзя ставить неизвестно что, не уведомив юзера что его запрос неточен. Может он не знал что есть ещё такой же пакет в более приоритетной категории, и это было важно.

защиты от дурака в генте не нужны

Читай про бинхосты и не майся дурью.

я не хочу бинхосты, я хочу дурь

портеж позволяет извращаться как угодно, не вижу смысла делать по манулуам

Я понимаю это желание. Такое желание возникает у каждого начинающего линуксоида: создать свой сайт про линукс, создать свой дистрибутив. Но это глупость. Чем раньше начнешь делать по мануалам, тем быстрее все будет работать.

Лучше запили бинарники свежей LibreOffice, остальное собирается не так уж и долго.

Вобщето стандартный портейж (emerge) нормально работает с бинарными пакетами (ключики -b/-B и -b) я когда админил кластер из 300+ серверов почти везде была гента и был 1 билд сервере на котором собирались бинарные пакеты, а все хосты просто их скачивали и распаковывали.

создать свой сайт про линукс, создать свой дистрибутив. Но это глупость.

Не тебе судить. Если не запрещено, значит разрешено. В этом нет ничего глупого, если человек хочет создать дистрибутив для себя.

Но зачем, ведь компиляция занимает секунды. Билд-сервер оправдан только если у тебя парк одинаковых машин.

В таком случае у Вас появится свое собственное дерево портов (оверлей) в котором будут дублироватся ВСЕ пакеты из основного дерева и Вам нужно будет 1) Править ВСЕ ebuild файлы на предмет зависимовстей и помечать их как конфликтные к аналогичным пакетам из основного дерева (поскольку bash и bash-bin по сути содержат одни и теж-е файлы). 2) Держать весь этот балаган в актуальном состоянии (а порты обновляются ежедневно в огромном ко-ве, хватит ли у вас ресурсов на это ?). 3) По хорошему собирать просто грамадное ко-во пакетов иначе будете попадать в ситуации когда какогото пакета в вашем дереве просто нету (или пакета определенной версии).

А в бинхостах все работает из коробки, потдерживать ничего не нужно. Если на у вас по какимто причинам отсутстивет требуемый пакет - хост сам его собирет.

нет, все пакеты я и не собирался

компиляция занимает секунды

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

у меня у самого 4.2.1.1

Ну это смотря что компилировать, что секунды а что и довольно долго (тотже gcc или какой нибудь KDE/FireFox/Chrome) + железо тоже разное бывает (какоето быстрое, какоето не очень, кое где вообще напряг с ресурсами (CPU, MEM, HDD)). Иногда бывает нужно обновить продакшен сервер - а он в онлайне и нагрузка на нем не маленькая, нагружать его дополнительно компилированием система - дорогое удовольствие получится, проще собрать гдето все (протестировать) и в прод залить уже готовые бинарники ...

Например я свой рабочий компьютер полностью обнавляю 2-4 раза в год (софт), как правило сборка занимает часов 30 (запускаю в пятницу вечером в понедельник все готово) - но у меня там софта много очень и проц не очень мощный (PentiumD).

А если серьезно, нужны бинарные пакеты webkit-gtk, chromium и libreoffice-bin последней версии. Я все никак не соберусь сделать это. То есть не tbz а именно precompiled.

Ну если 1-2 пакета то тогда смысл имеет, но к сборке нужно подойти обдумано. Иначе возможно ситуация что при обновлении системы/(или вашего пакета) при запуске программы на хосте появится надпись «library ABC.1.2.3 not found» или чтото в этом духе.

И да в gentoo принято именовать пакеты не binary-core/systemd а sys-core/systemd-bin - но это конечно дело вкуса ...

Даже жирнолис собирается 10 минут! И у меня очень старое железо при этом, лет 5 уже как минимум. Что уж говорить про остальных. А так и либра, и хром уже есть бинарные, а всё остальное действительно быстро собирается.

Gcc собирается 15 минут, прошлые версии было 10. Так ли часто он обновляется, чтобы из-за этого переживать? Да и зачем kde на сервере тоже не ясно… Но kde собирается не долго, долго собирается только вебкит (а значит webkit-gtk и qtwebkit тоже).

TC не спрашивал стоит ли ему делать бинарный репозиторий, а спрашивал как лутчше его сделать - если ему зачемто нужно значит ему нужно. И TC не говорил что ему это нужно для сервера.

У меня gcc собирается порядка 30 минту, и при этом железо не самое дохлое в оффисе. Но для работы мне этого железа хватает за глаза (оснавная система, тестирование, разработка + куча виртуалок) и менять его ради более быстрой сборки gcc/kde/firefox я смысла не вижу.

PS. Бинарные пакеты на рабочей машине сейчас не собираю (у всех остальных не gentoo на десктопах). Хотя на старой работе собирал и пол оффиса обновлялось именно с моего бинхоста и были этому благодарны.

Ему ответили что лучше сделать бинхост, но он не хочет как лучше, он хочет «не так как в мануалах».

Если бухать ацетон во время сборки - несомненно. На core i5 и с 16 GB RAM он собирается в течении не менее получаса.

binary/stage4

омг, какое отношение имеет количество оперативки ко времени сборки? и выкинь уже свою двухядерную затычку, тебя обманули, когда сказали, что это процессор.

если бы gentoo был с бинарным репозиторием - я бы на него быть может и переполз
Хотя, говорят, такое в calculate уже есть

двухядерную затычку

а сколько ядер на сегодня «норма»?)

какое отношение имеет количество оперативки ко времени сборки

количество потоков. что-то у меня gcc стал жрать по гигу на процесс на некоторых пакетах. для четырёхядерника нужно 5G, для него же c hyper-threading 9G

Чому не юз-флаг, binary какой-нибудь?

У чуваков с i7 примерно та же история. А всё потому, что firefox разворачивает шаблоны. Много шаблонов. Почти на 8 гигабайт шаблонов. Я пытался ускорить процесс, разворавивая шаблоны в ramfs. Но хрен там.

А по теме: добавляй -bin.

Ежедневное обновление генты занимает меньше времени, чем ежедневное обновление винды. При этом, гента шустренько компилирует и ничего в этот момент не тормозит, а винда умирает в лагах стрекоча жестким диском.

Естественно раз в месяц выпадает gcc\firefox, которые компилятся более 3-х минут, и могут в теории вызывать какой-то дискомфорт в работе системы. Это всё на ~arch, на стейбле наверное и того проще с обновлениями дела обстоят.

Есть же флаги -k и -K и будет ставить из бинарного репозитория, не будет никаких конфликтов имён и не нужна будет возня с именами. Если ты use флаги менять не начнешь на каждой машине отдельно.

Какие-то ужасы вы рассказываете. Раньше (примерно до 15 версии) фуррифоксу для линковки достаточно было какой-то пары гигабайт оперативки, причём все файлы во время компиляции хранились там же неподалёку, в tmpfs. Потом, в 16 версии, замутили новый jit-компилятор для жабоскрипта (его уже выкинули), у которого были проблемы с гцц (из-за чего тот начинал генерировать некорректный код и хотел гигабайты памяти), а ещё было время, когда pgo странно работал и тоже хотел гигабайты, не принося никакого профита в итоге (вероятно по этой причине этот режим сборки с pgo и выкинули), ну и lto тоже весьма проблемный, но вроде в 4.9 ветке исправили потребление памяти гцц.

Не представляю, что там в последних версиях фуррифокса теперь, но собирается оно гораздо быстрее.

А что до HT — мне кажется маловероятным, что распараллеливание на большее число более слабых недоядер оказывает положительный эффект на время компиляции, тут скорее важны частота реальных ядер и пропускная способность памяти.

Ну и кроме того, мои слова подтверждаются информацией, записанной в emerge.log — у меня никогда не возникало больной идеи замерять время компиляции. Компилируется с "-march=native -pipe -fomit-frame-pointer -fstack-protector-strong --param=ssp-buffer-size=4 -mfpmath=sse -floop-block", самый обычный убербюджетный четырёхядерник пятилетней давности, больше ничего интересного сказать не могу.

-fomit-frame-pointer

по-дефолту даже на x86 давно

-fstack-protector-strong

на генте gcc пропатчен, в нём тоже по-дефолту

-mfpmath=sse

на x86_64 по-дефолту всегда. а если у тебя не x86_64 — зря

Ежедневное обновление генты занимает меньше времени, чем ежедневное обновление винды. При этом, гента шустренько компилирует и ничего в этот момент не тормозит, а винда умирает в лагах стрекоча жестким диском.

Ау меня так: Ежедневное обновление винды занимает меньше времени, чем ежедневное обновление генты. При этом, винда намного быстрее проставляет обновки в совокупности и ничего в этот момент не тормозит, а гента умирает в лагах стрекоча жестким диском из-за своппинга и недостатка ОЗУ.

На core i5 и с 16 GB RAM он собирается в течении не менее получаса.

А вот на дуалкоре с 4 GB RAM...

Mon Feb 16 07:07:12 2015 >>> www-client/firefox-35.0
merge time: 1 hour, 58 minutes and 26 seconds.

Значительное отставание. Интересно.

бинарный репозиторий для генты

Гентушники начинают что-то понимать...