numpy в зависимостях

То есть необязательная установка дополнительных пакетов для openoffice или xnviewmp для поддержки воспроизведения мультимедиа ожидается и воспринимается мной нормально, но тот факт, что после установки музыкального проигрывателя выясняется, что он вообще ничего не в состоянии воспроизвести (а это его основное назначение) до тех пор, пока вручную не поставишь кучу пакетов, очень расстраивает.

так пусть эта зависимость будет там, где она требуемая, а не опциальная

ну то, что там unused variables по сути, это не к генте

В данном случае это напрямую касается Gentoo, так как вызов этих самых «unused variables» прописан внутри live-ebuild'а как управляющая опция и данный ebuild требует внесения изменений, чтобы соответствовать внесённым апстримом изменениям.

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

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

Только не забудь случаи вида «пакет А задетектил установленный, но не прописанный по зависимости, опциональный пакет B. Далее пакет C проверяет(тоже опциональную) поддержку B в пакете A и сюрприз, находит её. Потом пользователь выполняет emerge --depclean, пакет B отправляется в /dev/null и пакет C начинает вести себя вообще по-другому, а то и глючить». Продолжи эту линию неучтенных зависимостей, помножь это на то, что чем глубже отсутствующий пакет, тем обычно невнятнее сообщение об ошибке и на выходе ты получишь ад.

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

Вынос такого в USE-флаги - тоже не панацея, если нельзя флагами принудительно объяснить пакету A что поддержку B делать не нужно(даже если пакет B установлен). Для пакетов, проверяющих наличие поддержки в рантайме с текущими возможностями USE-флагов это сделать просто НЕЛЬЗЯ.

Вообще мне кажется что я уже по-третьему кругу разжевываю тебе чем чревато такая чехарда с зависимостями. Если тебя не устраивает наличие конкретного в системе - у тебя всегда к услугам package.provided. Тут как с user patches - есть поддерживаемая разработчиками конфигурация, есть неподдеживаемая. Это не значит что пользователю нельзя накладывать патчи, просто первым делать попросят пересобрать пакет без них, дабы убедиться что это не они - проблема.

Пока что опциональные зависимости, которые никак не ложатся на парадигму USE-флагов - это неподдерживаемая конфигурация.

Как только телепаты вернутся, то никаких логов и не надо будет.

О, а я только собирался сегодня дигапать эту тему, но я фанат autotools, тем паче что Cmake они поддерживают неофициально, так что в ближайшие недели оно окажется на автотулзе

Очень редко, больше похоже на ни разу за 10 лет. Просто не забывайте depclean прогонять почаще, особенно после апдейтов. Крайне приятно 300 пакетов перла выкинуть бесплатно (и не приятно, что очередной минорный апдейт потом тянет ещё 200 пакетов перла, которые никогда никому нужны не были).

Пусть autotools будет, так даже лучше.
Я даже удивился, что там делает CMakeList.txt при наличии configure.ac? К тому же в последнем все эти опции всё ещё на своём месте.

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

нафига его надо был переписывать на cmake

спроси об этом людей, которые занимались поддержкой пакета до того, как он стал его ментейнером в июне этого года

ну, окей

Ну традиционно Cmake считается более простым решением, хотя лично я с этим в корне не согласен, мне проще изучить configure.ac а далее Makefile.am нежели 100500 CMakeList.txt, впрочем, как тебе уже заметили Cmake там втащил не я (я и в баге тебе написал)

Самое печальное, что при обновлении до версии 3.3.10 в коммите никак не пояснялось , почему внезапно qmake, использовавшийся в 3.3.7, заменили на cmake :(

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

а куда она их пытается по умолчанию поставить с autotools?

щас уже точно не помню (я 4 дня назад первый раз переписать попробовал) но оно делает симлинк на /usr/bin, а это фейспалм, поэтому кажется cmake и заюзали, он менее проблемный, даже странно, клиент то нормальный и апстрим вменяемый вроде

Я даже пофиксил, наслаждайся