sys-apps/portage-2.2.0

Напомните кардинальные отличия от стейбла.

Так вот почему они так часто новые alpha-версии клепали. А то я удивлялся при каждом синке.

Напомните кардинальные отличия от стейбла.

preserve-libs, preserve-rebuild.

Это и в 2.1 есть, причём уже давно.

Всем гентушникам радоваться полчаса!

Сижу на -9999. Мне на каждый чих радоваться?

fargred

Это и в 2.1 есть, причём уже давно.

Изначально эта фича появилась в 2.2. Это уже потом её портировали в декабре 2012 в 2.1.

https://forums.gentoo.org/viewtopic-p-5127806.html

Сижу на -9999. Мне на каждый чих радоваться?

Поломки бывают?

года два назад были.

And, another advantage over revdep-rebuild: things keep working, because it keeps the old libraries around until you reemerge things. It still has some issues, like preserving to much libs through. Note that this is on by default

dll hell во все поля. sort of :3

Немного оффтопа: как починить блокировки из-за добавления ABI_x86, когда старые пакеты emul-linux-* блокируют пакеты с abi установленным в 32?

Ну ничего себе

Не пытаться ставить новые emul-*, или размаскать соответствующие библиотеки

Я их не ставлю, их тянут игрушки, плееры и прочие штуки.

Мне помогло это

это причина по которой ABI_Х86 не готов. ты или начилуешь себя и не ставишь emul-*, либо не используешь ABI_Х86.

Так проблема в том, что некоторые пакеты стали требовать ABI_X86. Откуда я о нем и узнал.

Ура.

Так проблема в том, что некоторые пакеты стали требовать ABI_X86. Откуда я о нем и узнал.

А я думал, что я сам что-то сломал, а оно вон оно чё

некоторые пакеты что стали делать? можно ли примеры онных? у меня в make.conf ABI_Х86 подкомментирован, проблем на апдейтах не испытывал.

Некоторые пакеты стали требовать USE=abi_x86_32. Список уже не приведу, я полсистемы перелопатил в попытке удовлетворить зависимости. Попробую теперь обратно убрать 32 и посмотреть что будет.

Как разработчик генты, прошляпивший данный момент, заявляю - ахринеть! :-/

because it keeps the old libraries around until you reemerge things

Если не считать редких факапов(вызванных в основном бажными билдсистемами), то лучше уж так, чем получить отвал сервисов при смене версии у .so

Размаскировать новые emul-* пакеты(которые hardmasked), по всем возникающим проблемам - багрепорт.

Пока native multilib в генте - вещь для экспериментаторов и альфа-тестеров. Не можешь/не желаешь выступать в таком качестве - сиди на stable/unstable без указания ABI_X86

их тянут игрушки, плееры и прочие штуки.

ЕМНИП, принудительно тянут только в оверлеях(steam из steam-overlay например).

Так я же и говорю, все началось с того, что какие-то пакеты стали требовать ABI_X86. Иначе я бы спокойно сидел и об этих нововведениях не слышал.

Может кто-то из desktop team профакапил(очередной раз :-/) и сломал unstable. Только учти, убедись мэйнтэйнеры оверлеев могут и послать, потому что могут считать что bleeding edge = true(не все конечно).

Но если проблема в пакете из главного дерева - тогда точно надо багрепорт слать!

Оке, я уберу ABI_X86 из make.conf и посмотрю кто его требует.

Ах да, еще одну проблему встретил. phonon-kde и phonon-qt блокируют друг друга. На багзилле такого не нашел. Это я где-то накосячил или надо багрепорт писать?

abi_x86_32

Как по мне, одно из самых идиотских нововведений.

Почему? Оно позволит подтянуть последние версии софта, не дожидаясь, пока перепакуют emul-*.

Я жду-не дождусь abi_x86_32 в mesa

Проблема с ABI-X86 была в пакете libsdl из оверлея gamerlay :)

phonon-kde и phonon-qt блокируют друг друга. На багзилле такого не нашел. Это я где-то накосячил или надо багрепорт писать?

Да, tracker-бага нет, я еще не создал, виноват. Есть довольно раздражающий баг, который мешает нам выпилить qtphonon нахрен, согласно решению, принятому на собрании Qt team от 2013-07-02. Лог собрания, если интересно ;-)

Как по мне, одно из самых идиотских нововведений.

Нативный мультилиб вместо костылей из emul-*-libs(и кучи, просто кучи багов с ними связанных, в основном при version bump-ах обычных пакетов и несовпадении ABI с 32-х битными версиями) - это вин. То, что его нельзя «РРаз» и ввести и чтоб всё сразу заработало - это да, это проблема.

То, что его нельзя «РРаз» и ввести и чтоб всё сразу заработало - это да, это проблема.

А что вообще мешает? Вводим, пробуем выполнять emerge -pv для каждого пакета. Смотрим, кто конфликтует и фиксим. Потом все изменения разом коммитим, чтобы не ждать заведения 9000 багов.

Вводим

Нужно одновременное портирование ебилдов на новые еклассы от всех мэйнтэйнеров. Если речь идет о пакете где 3,5 файла ставятся - вопросов 0. Большие пакеты сложно портировать не сломав, плюс есть всякие тонкости в некоторых случаях навроде заголовков(да, да headers), которые РАЗНЫЕ(!) для разных ABI(на x86 пакет ставит одни заголовки в /usr/include, для amd64 - другие, но с тем же именем).

Потом все изменения разом коммитим

Всё это мгновенно не делается. Нельзя лезть править пакеты, которые ты не мэйнтэйнишь(нет, ну конечно можно, только если что-то сломается, волком будут смотреть ну ты понел на кого. И по шапке можно получить от Developer Relations, если совсем внаглую поступать)

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

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

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

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

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

По идее должно работать так. У нас есть две ветки репозитория. Дерево для юзеров и дерево для разработчиков. Разработчики могут вносить изменения только в дерево для разработчиков. Раз в N часов некий сервер проверяет целостность дерева для разработчиков. Если она соблюдается (все собирается, ничего не сломано), вносим изменения в дерево для юзеров. Если хоть один пакет сломался, рассылаем уведомления мейнтейнерам сломанных пакетов и тем, кто вносил изменения с момента последнего слияния (на случай, если это внесший изменение что-то сломал). Таким образом все всегда собирается (вернее, все зависит от эффективности программы, которая проверяет целостность).

Так потому и вечная бета, что такие косяки. В ядре такой фигни нет, там сломавший что-либо получает по шапке от Линуса.

В ядре такой фигни нет, там сломавший что-либо получает по шапке от Линуса.

Вся эта фигня была, были и новые версия ядра по несколько на дню, чтобы исправить внезапно появившийся баг. Конечно, теперь в ядре задействованы десятки, если не сотни, тысяч людей, часть из них получает деньги от той же РедХад. Когда в команде генты будет также все в шоколаде, тогда.

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

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

Что значит нестабильная ветка, ты так и не усвоил. Меня больше волнует слоупочество в стабилизации пакетов.

Я не против нестабильной ветки. Я только предлагаю способ упростить ее стабилизацию. Сейчас тестируется все вручную, стабилизируется по запросу пользователей. И то далеко не всегда пакет в стабильной ветке является стабильным.

И то далеко не всегда пакет в стабильной ветке является стабильным.

Вот это мне и не нравится. С одной стороны, udisks-2 в стабильной, а стабильный wine тянет udisks-1. С другой стороны, стабильный asymptote требует нестабильного TeX Live 2013, трагичность ситуации в том, что версия asymptote под стабильный TeX Live 2012 уже выпилена из дерева. Не хочу переходить на нестабильную ветку из-за этих всех ABI, но и стабильная далеко не стабильная.

Нативный мультилиб вместо костылей из emul-*-libs

Копай глубже. Проблема - в бинарных блобах.

И никто не мешает перенять их опыт в генте, а не бежать впереди паровоза с нестабильными пакетами.
в генте

Ты хотел сказать, во всем OSS-сообществе?
Но нет, у нас мало написано WM/DE/etc/etc/yet_another_etc. Лучше 20 костылей, чем 2-3 хороших проекта.

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

в условиях CVS это практически невозможно :-(
А переход на git всё затягивается :-(

Дело не в том, кто кому платит и сколько людей

Доооо... Когда приходится ждать фиксов от мэйнтэйнера неделями(!), потому что на нём висит около 300 пакетов и он чисто физически не успевает всё - это однозначно нехватка ресурсов. Поэтому дело всё-таки в этом...

Просто в ядре сейчас работают квалифицированные люди, которые умеют вести рабочий процесс, а не студенты как раньше.

В генте есть(негласно, но тем не менее) т.н. senior developers, которые разрабатывают ее уже 8-10 лет. Но что толку, если, как я уже говорил нет ресурсов?

Меня больше волнует слоупочество в стабилизации пакетов.

Та же ситуация что и везде - 'lack of manpower'. Наш «бог стабилизации»(за ним числится где-то 80-90% устабилизированных пакетов на некоторых архитектурах) - Agostino Sarubbo один за всем не успевает. А выхлоп остальных(включая меня) - ничтожно мал.