Gentoo и компиление. Прекомпиленный пакеты.

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

> А я предлагаю составлять карту автоматически.

Ну так, чего трындим на ЛОРе-то, вперёд составлять карту! :)

то есть, у emerge проблемы в том, что он не прозрачно расширяемый: при каждом таком расширении требуется переписывать/переподписывать ебилд и цепочку зависимых от него + "стабильный" набор package.{mask,keywords,use}.
Тогда как если бы он этого не требовал, были бы более ортогональные изменения "портеджа" и сборка не только на клиенте, но и на любых доверенных ему с совместимым набором параметров сбоки. И грабли бы вылезли совсем в другом месте (интересно где, да).

алгоритмом распространения волны или через QSPF/Netsukuku? :))

Хм, а из sabayon hal у меня тоже не собирается:

In file included from probe-serial.c:32:

/usr/include/linux/serial.h:164: error: expected specifier-qualifier-list before ‘__u32’
make[5]: *** [probe-serial.o] Error 1
make[5]: *** Waiting for unfinished jobs....
mv -f .deps/probe-smbios.Tpo .deps/probe-smbios.Po
make[5]: Leaving directory `/var/tmp/portage/sys-apps/hal-0.5.11-r5/work/hal-0.5.11/hald/linux/probing'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/var/tmp/portage/sys-apps/hal-0.5.11-r5/work/hal-0.5.11/hald/linux'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/var/tmp/portage/sys-apps/hal-0.5.11-r5/work/hal-0.5.11/hald'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/sys-apps/hal-0.5.11-r5/work/hal-0.5.11/hald'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/sys-apps/hal-0.5.11-r5/work/hal-0.5.11'
make: *** [all] Error 2

Вот тут есть патч для serial.h https://bugs.launchpad.net/ubuntu/+source/linux/+bug/303711

исходники ведра точно проставлены в /usr/src/linux ? они той же версии что и загруженное ведро? а ядерные хедеры той же версии как и работающее ведро?

хотя не, исходники ведра там ненужны похоже что. только хедеры.

каникулы..

Это баг ядра, и как я понял наблюдается во всех дистрибах.

> Это баг ядра, и как я понял наблюдается во всех дистрибах.

именно 2.6.28 ?

Да. Хедеры и /usr/src/linux версии 2.6.28.

> Вот тут есть патч для serial.h https://bugs.launchpad.net/ubuntu/+source/linux/+bug/303711

Спс, попробую сегодня. :)

> именно 2.6.28 ?

ответ не нужен, сходил таки по ссылке =)

Добавил инклуд и проканало. :)

Дурачок...

P.S. а все выше, у кого там всё отваливается и не собирается - просто лузиры.

>Gentoo и компиление. Прекомпиленный пакеты.

Оооо! Ви есть не знать рюсский языка!

как я понял, красноглазием тут порядочно кого есть

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

ещё один. "Десять миллионов красноглазиков теребят eix-sync -Wl", и пересобирают заново с нуля, со своими чисто "уникальными" флагами и "флагами компиляции", а ты хочешь прервать их ритуал и помешать их щастью?
ЕретикЪ.

Ага, а еще под несколько процессоров и архитектур :)

и чо, "несколько процессоров & архитектур"?
практически у половины красноглазиков уже собрано с совместимым набором флагов. Осталось только расшарить и закачать.

вот хотя бы так: берём сорцы из hg, ложим собранные бинарники (и параметры сборки) в git. Если из одних и тех же сорцов с заданными параметрами сборки (компилятор/архитектура/ключи configure(USE-флаги)/рекомендуемые зависимости итп) собирается один и тот же бинарник, то в git будет ложиться один и тот же файл. Для нас не важно конкретно подпись этого бинарника, важна однозначная функциональная зависимость "параметры сборки"-"собранный бинарник". Эта ФЗ подписывается цифровой подписью (хешем от содержимого бинаря, сигнатурой ментейнера, именем файла в git-blob-storage (тот же хеш от содержимого),итп). Потом полученный бинарник расшариваем в например, торрент (или недоторрент через rsync обновление этих собранных в git бинарников).

Да не нужно это все. Компьютеры нынче мощные, то что собирается долго (openoffice, firefox...) уже есть в бинарной сборке.

В свежих хедерах уже пофиксили.