Portage 2.1 Released

А я вот на днях с gentoo на Debian пересел обратно... Gentoo конечно дистр прикольный тем, что всю систему в кулаке держишь :) Но компиляция...она как наркотик :) Чем дольше она идет, тем больше ее хочется o_O А как поставил Debian, сразу появилась куча свободного времени :) Можно было бы конечно и Ubuntu...но не пропадать же зря 2м dvd за 580 рексов с linuxcenter'а... Так что Debian теперь - наше все! ;-)

Кстати, когда сидел в gentoo на x86, глюков в потреже не было ВООБЩЕ. можно было спокойно оставить компиляцию на ночь, утром проснуться и получить свой kde или gnome :) А как пересел на ~x86 так просто ужоснах...то md5 не сходится, то компиляция вылетает...на то он и ~x86...

> На 3 гигагерцах и гигабайте памяти?

На 262 МГц и 384 мегабайтах памяти

портки трещат по швам

>На 3 гигагерцах и гигабайте памяти?

man nice, родной.

Джента рулит своими bleeding edge ебилдами. А сам portage... гм... там USE-флаги в депах прописывать уже можно? Или и по сей день иной раз emerge --pretend прокатывает на ура, а потом при собственно emerge вываливаемся на середине компиляции с сообщением вида "а вот сначала соберите ncurses с +unicode"?

Однако ж других source-based дистров с таким большим количеством пакетов нет и не предвидится, а наличие сырцов имеет определенные преимущества при желании поиграться со свежачком.

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

> А сам portage... гм... там USE-флаги в депах прописывать уже можно?

По-моему года два-три как изменение USE флагов меняет зависимости,
вы откуда свалились?

Он имеет ввиду такое вот:

Собрал ты всю систему без unicode. Потом захотел себе редактор nano юникодовым сделать. пересобираешь его с +unicode, portage ни на что е ругается и только вовремя ./configure сам nano вываливается с сообщением что ncurses собрано без unicode. поидее неплохо б что, такие случае сам portage отслеживал.

>Собрал ты всю систему без unicode. Потом захотел себе редактор nano юникодовым сделать. пересобираешь его с +unicode

man portage.

Или хотя бы gentoo-wiki.com

Если ты меняешь флаги, ты обязан пройтись по emerge -auvDN world

Все пакеты, зависящие от изменения этого флага пересоберутся.

RTFM, в общем.

>> Гента, конечно, замечательный дистрибутив, но мне очень не хватает возможности обновлять только security-fixes.

> А чем glsa-check не устроил? 8-0

Спасибо тебе, Человечище! :) Пошёл курить это дело...

>а с каких пор в гентее бинари ставить нельзя? можно даже RPMы ))))

Вопрос не в том можно ли бинари ставить, вопрос в том где их столько взять =)

>Если ты меняешь флаги, ты обязан пройтись по emerge -auvDN world >Все пакеты, зависящие от изменения этого флага пересоберутся.

Я ж сказал, что захотелось только nano с юникодом. Для этого есть /etc/portage/packages.use и ясное дело если я там укажу флаг unicode для nano, то пересборка всего мира нафиг не нужна. Но тем не менее, nano не соберется, даже если я весь мир собиру.

>если я там укажу флаг unicode для nano, то пересборка всего мира нафиг не нужна

Читаем маны - emerge -auvDN world пересобирает только пакеты, собранные с иными (по сравнению с текущими) USE флагами.

И ошибку, кстати, вываливает сам ебилд, а не ./configure

> По-моему года два-три как изменение USE флагов меняет зависимости

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

> Если ты меняешь флаги, ты обязан пройтись по emerge -auvDN world

А если я меняю их в /etc/portage/package.use? Причем выборочно для отдельных пакетов? Ты, надеюсь, не хочешь сказать, что если, например, мне нужно будет vim пересобрать с +gtk - мне нужно пересобирать всю систему? И как я могу _до запуска emerge_ определить, какие флаги потребуют пересборки, а какие - нет? А то вроде оно все автоматизировано, а так запускаешь, отходишь чай попить, возвращаешься... а оно на втором портеже (из десяти!) загнулось =/

Наглядный пример (правда, пофиксен довольно давно - но мне больше всего запомнилось) - wxGTK. Когда-то его можно было собрать либо _только_ с поддержкой Unicode, либо без. При этом был ряд софтин, которые с юникодным wxGTK либо просто не собирались, либо собирались, но не работали. Естественно проверка эта была сделана вручную в ебилде, так что, сделав emerge --pretend amule, юзер об этом не знал. Узнавал он, когда вытащенная депами wxGTK уже собралась (с unicode, т.к. make.conf стояло USE="unicode"), а собственно amule загинался с предложением пересобрать wxGTK уже с -unicode. Веселье... Пофиксили это тем, что стали всегда собирать неуникодную версию, и при сборке обоих - класть их отдельно. Но это не единичный случай. Потом были похожие грабли с ncurses (не в курсе, пофиксили или нет), еще кое-что по мелочи. Суть в том, что USE-флаги пакета должны являться частью депа, т.е. ебилд должен иметь возможность задекларировать системе, что ему нужен не абы какой ncurses, а именно +unicode. Тогда emerge --pretend будет хотя бы отлавливать такие ситуации заранее, и давать возможность их быстро разруливать. Пока этого нет, я лично считаю portage по сути своей - сломанным. Во всяком случае, предложение пересобирать полностью систему при каждой правке package.use всерьез принять сложно.

Скажите, это кривое убожество уже научилось prefix при конфигурации прописывать или /usr/X11R6 так и является симлинком на гигантскую помойку /usr? И как там дела с enable/disable|with/without или по-прежнему кроме протеза мозга под названием USE вариантов нет? А то я гляжу у некоторых понятие emerge+USE уже стало синонимом понятия "компиляция".

>Скажите, это кривое убожество уже научилось prefix при конфигурации прописывать или /usr/X11R6 так и является симлинком на гигантскую помойку /usr? И как там дела с enable/disable|with/without или по-прежнему кроме протеза мозга под названием USE вариантов нет? А то я гляжу у некоторых понятие emerge+USE уже стало синонимом понятия "компиляция".

Да, префикс - переменная окружения, а если нужно самостоятельно сделать конфигуре - ebuild позволяет каждый шаг сборки пакета сделать... Тоесть

ebuild file.ebuild fetch

ebuild file.ebuild unpack

ebuild file.ebuild compile

ebuild file.ebuild install

ebuild file.ebuild qmerge

Рекомендую к прочтению man ebuild

>enable/disable|with/without или по-прежнему кроме протеза мозга под названием USE вариантов нет?

У анонимуса по-прежнему кроме протеза мозга ничего нет. Чем тебе USE не угодил?

>А если я меняю их в /etc/portage/package.use? Причем выборочно для отдельных пакетов? Ты, надеюсь, не хочешь сказать, что если, например, мне нужно будет vim пересобрать с +gtk - мне нужно пересобирать всю систему?

Ну. Прописываешь нужный флаг в /etc/portage/package.use, потом делаешь emerge -NDu world. Пересобирается только то, что нужно (+те, кто зависят от него).

> Ну. Прописываешь нужный флаг в /etc/portage/package.use, потом делаешь emerge -NDu world. Пересобирается только то, что нужно (+те, кто зависят от него).

Если я пропишу в package.use:

app-editors/nano unicode

при этом в глобальных флагах unicode не прописан, оно пересоберет ncurses с unicode по emerge -NDu world?

> Чем тебе USE не угодил?

действительно. встал и ушел отсюда. use флаги ему не нравятся. на лоровский флейм нужно приходить подготовленными!

USE флаги это всё же мягкие зависимости, хочется чтоб были ещё жёсткие, чтоб никакая фигня вроде qt, gtk1 и gconf не прошла в систему

проходил мимо, заметил 3 страницы флейма по поводу portage. почитал. слов нет... впервые в жизни иду против "фич" доступности линукса... графический инсталер генте не нужен!

>Если я пропишу в package.use:

>app-editors/nano unicode

>при этом в глобальных флагах unicode не прописан, оно пересоберет >ncurses с unicode по emerge -NDu world?

Нет.

>Да, префикс - переменная окружения...

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

>У анонимуса по-прежнему кроме протеза мозга ничего нет. Чем тебе USE не угодил?

Уважаемый сэр, сходите в сад послушайте там увлекательный рассказ другого сэра о 80-м прерывании, затем сделайте ./configure --help и проведите сравнительный анализ с USE-флагами.

>сделайте ./configure --help и проведите сравнительный анализ с USE-флагами.

И что? Чего Вам не хватает в USE? Напомню, что

1) В других дистрибутивах вообще нету ничего, аналогичного USE

2) В бинарных дистрибутивах пакеты собраны с такими опциями configure, какие понравились мейнтейнеру.

3) Никто не мешает лично Вам

3.а) Переделать ebuild

3.б) Скомпилить вручную

Или сэр всадопосылатель видел что-то лучше, чем USE? Поделитесь с народом.

тут недавно прходила новость про доку по клепанию ебилдов может почитаем:) ? или хотябы man ebuild. Зависимости от флагов в портежах есть, согласись, что ./configure не смог бы тебе ляпнуть, что надо бы съемержить такой-то пакет с тем-то флагом и в этом случае (еслибы это все-таки был autotools и ты докапался до истины сам) ты не перечислял бы тут классику проблем с бажными дистрибуциями с генте, а справедливо отнес бы проблему к криворукости разработчиков валящихся программ. Необходимость пересбора пакета разрешающего зависимость очень и очень спорна: в том же случае с wxGTK автоматический пересбор решал бы проблему для последней установленной программы (допустим она требует с уникодом) и ломал бы работу других приложений (которым надо wxGTK без уникода). opensource ПО содерижт множество екземляров предоставляющих одинковую функциональность, дублирующих друг дурга и конфилктующих между собой. Portage это инструмент, а инструмент не должен изображать мыслительную деятельность и принимать решения за хозяина. Впрочем есть одна ос где в основном так и происходит:)

> Зависимости от флагов в портежах есть

Если есть - то это действительно замечательно, и вопросов больше не имею =) Просто portage именно по этому поводу вполне справедливо давно и долго пинали.

А так я его помню еще с тех времен, когда у него package.use и прочих /etc/portage не было. Вот это было веселье... Ну, раз доделали - молодцы: лучший source-based дистр стал еще лучше.

>USE флаги это всё же мягкие зависимости, хочется чтоб были ещё жёсткие, чтоб никакая фигня вроде qt, gtk1 и gconf не прошла в систему

USE="-qt -gtk итд" или сразу в make.conf не пробовали?

Павел, всё соберётся как надо. Пример ниже. Новые USE-флаги метятся %, изменённые *. Зависимости отслеживаются.

# USE="-unicode" emerge -pvuDN nano

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-libs/ncurses-5.5-r2 USE="gpm -bootstrap -build -debug -doc -minimal -nocxx -unicode*" 0 kB
[ebuild R ] app-editors/nano-1.3.11-r2 USE="justify ncurses nls slang spell -build -debug -minimal -unicode*" 0 kB

Total size of downloads: 0 kB

во всех доках такое использование USE флага не рекомендуется ибо потом при обновлении по крону все соберется без unicode.

Если делать по докам, а имеено если ты хочешь какой то USE флаг только для одного пакета, то писать его надо в /etc/portage/packages.use, но записав его туда пакет (в случае unicode и nano) не соберется.

Что вы пытаетесь доказать? Есть такой недостаток у portage, есть соответствующий баг в багзиле еще с 2002 года, и что бы вы ни говорили если делать так как принято в Gentoo, то проблемы с зависимостями иногда возникают.

Другой пример. Собираем MySQL 4.1, собираем php с флагом mysql, обновляем MySQL до 5.0 версии и о чудо, php больше не умеет работать с MySQL =) Почему пользователь должен помнить все то, что было собрано с заголовочными файлами MySQL и пересобирать это вручную? В ебилде должна быть какая-то функция, что если предыдущая версия пакета меньше определенной, то после сборки пакета ищем все что зависит от него и пересобираем. Но такого нет.

Почему нет - есть. Мантайнеры решили этого не далать ибо нефиг. А что тебе мешает пересобрать все зависимые от MySQL пакеты одним движением пальца ?

> во всех доках такое использование USE флага не рекомендуется ибо потом при обновлении по крону все соберется без unicode.

Я не собираюсь объясняться и оправдываться, так как прекрасно знаю эти тонкости и толстости. Любители апдейтов по крону по своему правы, а по моему нет.

> Другой пример. Собираем MySQL 4.1,...

Хе-хе-хе, ты бы ещё про обновление gcc с 3 до 4 рассказал бы. Ух, сколько там всего ломается...

Подожди, мальчонка ещё про revdep-rebuild не дочитал, а уже дядек бородатых на ЛОРе полез мордой по столу возить.

> Павел, всё соберётся как надо. Пример ниже. Новые USE-флаги метятся %, изменённые *. Зависимости отслеживаются.

Это точно новые? больше похоже на локальные.

>> USE флаги это всё же мягкие зависимости, хочется чтоб были ещё жёсткие, чтоб никакая фигня вроде qt, gtk1 и gconf не прошла в систему

> USE="-qt -gtk итд" или сразу в make.conf не пробовали?

Не поможет!

во-первых - флаг gtk не обязательно означает gtk1. Во-вторых - это не жёсткий запрет, если я потом напишу emerge kde он мне вытянет по зависимостям и qt, кстати, ещё и gconf в придачу! В-третьих - в Thunar почему-то прописана зависимость на gconf :-( пришлось руками ебилд править.

хы-хы, и первый gtk для imlib ;-)

[ebuild R ] app-office/koffice-1.4.2-r7 USE="javascript mysql postgres xinerama -arts -debug -doc" 0 kB

Подправляем...
grep opengl /etc/make.conf | wc -l
0

[ebuild U ] app-office/koffice-1.5.1-r1 [1.4.2-r7] USE="mysql postgres xinerama -arts -debug -doc -opengl%" 35,166 kB

Возвращаем...
grep opengl /etc/make.conf | wc -l
1

[ebuild U ] app-office/koffice-1.5.1-r1 [1.4.2-r7] USE="mysql opengl% postgres xinerama -arts -debug -doc" 35,166 kB

Сами выхлоп проанализируете?

Не понял, почему в оригинале opengl не было, откуда он потом взялся? Помоему ты emerge --sync сделал и тебе пришёл пакет в котором есть поддержка опенгл!

Ну да. В установленном у меня 1.4.2 нет такого флага, а в 1.5.1, который мне предлагают, есть. Этот флаг и метится %.

> # USE="-unicode" emerge -pvuDN nano

Угу. Но тут ты просто временно переопределяешь глобальные USE-флаги (при том, что в манах четко написано, что так вообще делать низзя, т.к. уже два года как есть package.use). А вот если ты в package.use включишь unicode отдельно для nano - оно обломится. Причем не gracefully, а в мучительной агонии, о чем и речь.

Кстати, так я не понял - это пофиксили все-таки уже или нет? А то все разное говорят, непонятки. Слазил в доки (http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#...) - там про USE-флаги в депах ни слова.

>Подожди, мальчонка ещё про revdep-rebuild не дочитал, а уже дядек бородатых на ЛОРе полез мордой по столу возить.

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

Про gcc тоже не надо, просто сборка gcc ничего не ломает, плюс к тому выводится подробная инструкция по миграции на новый gcc, плюс новый gcc встает рядом со старым, а не вместо как это делает mysql.

Бородачи блин.

Нет, не пофиксили. Ручное переопределение -- единственный способ, либо менять в make.conf, что повлияет на все пакеты в дальнейшем, мало того, если пишешь флаги в package.use, то обламываешься и с make.conf.

> Не надо про revdep-rebuild, это средство лечения, а не повседневный инструмент.

Ню-ню... Жди, когда у тебя половина дистрибутива развалится из-за потерянных зависимостей. Я соглашусь с тем, что это долгий и нудный костыль и как-то пересмотреть эту ситуацию желательно, но данный рабочий инструмент необходим, так как много чего цепляется не к foo.so.N, а к foo.so.N.XX.YY и пикнуть не успеешь, как что-нибудь да поломаешь.

> просто сборка gcc ничего не ломает

Я где-то сказал что ломает? Я сказал про *обновление*, а не установку рядом, хотя обойти это тоже легко. Потом, нафига мне через год 5 разных версий компиляторов в системе?

Про --noreplace и app-admin/eselect-mysql Вы оказались тоже не в курсе? Сильно сомневаюсь. Уважаемый любитель обновления по крону, хотите крон -- забудьте про индивидуальную настройку пакетов. Единственное на что годится крон -- --fetchonly. Это моё мнение, Вы с ним можете не согласиться, но и я своего мнения менять не собираюсь.

> Про gcc тоже не надо, просто сборка gcc ничего не ломает, плюс к тому выводится подробная инструкция по миграции на новый gcc, плюс новый gcc встает рядом со старым, а не вместо как это делает mysql

Да, особенно связка libstdc++.so.X не ломается ;-)

>... Во-вторых - это не жёсткий запрет, если я потом напишу emerge kde он мне вытянет по зависимостям и qt,...

Ах, вот как вопрос стоит, ну тогда остается только замаскировать то что вам не нужно. Хотя я не понимаю: зачем это надо в принципе? Если вы предпочитаете QT/GTK, то выставляете соответсвующие флаги, если прога писана только под конкретную либу, то либо не ставить ее и искать аналог, либо ставить со всеми необходимыми либами. Ну а по поводу глупых зависимостей: а в каком дистре их нет?, в gentoo их намного меньше чем в любом другом.

>И что? Чего Вам не хватает в USE? Напомню, что

Ну скажите мне пожалуйста, какими USE-флагами в mplayer'е включаются динамические плагины, i18n, выбор языка манов, статическая компиляция, кодировка, порядок байтов и т.п. И какое влияние на сборку окажет переменная debug, какой будет уровень отладочной информации, будет ли использоваться профайлинг и т.д.? Что вообще может сказать USE="kde", кроме того что для сборки понадобится kde, смысловой нагрузки о том какой конкретно функционал обеспечивает наличие тех или иных флагов в конкретной программе вообще нет.

>какими USE-флагами в mplayer'е включаются

Если хотите увидеть тонкости, потрошите сам ебилд :)
less /usr/portage/media-video/mplayer/mplayer-1.0_pre8.ebuild
Если что-то не нравится, перекрываете его и правите на свой вкус.

> какой конкретно функционал обеспечивает наличие тех или иных флагов

Читайте:
/usr/portage/profiles/lang.desc
/usr/portage/profiles/profiles.desc
/usr/portage/profiles/use.desc
/usr/portage/profiles/use.local.desc