И снова на арене Gentoo-дистмейкеры

линк в студию; т.к. на багзилле баг не открыт (или я не нашёл). Там как я понял 1 должны быть пофикшены зависимости, и пропатчен configure.ac, т.к. он выбирает из имеющейся с приоритетом gtk-3

Пояснение: у кого-то не собрался пакет.

Пояснение: у кого-то " KRoN73 собрался пакет. А ты не думал, что у 80% других юзеров он мог не собираться? А вообще ППКС. Дерево поддерживают паршивенько, а оно у нас одно.

Правленый ebuild transmission - введен gtk3 флаг

Правленный кусок.

Было:

IUSE="ayatana gtk lightweight qt4 xfs"

RDEPEND="
	>=dev-libs/libevent-2.0.10
	dev-libs/openssl:0
	net-libs/libnatpmp
	>=net-libs/miniupnpc-1.6
	>=net-misc/curl-7.16.3[ssl]
	sys-libs/zlib
	gtk? (
		>=dev-libs/dbus-glib-0.98
		>=dev-libs/glib-2.28
		>=x11-libs/gtk+-3.2:3
		ayatana? ( dev-libs/libappindicator:3 )
		)
	qt4? (
		x11-libs/qt-core:4
		x11-libs/qt-gui:4[dbus]
		)"

Стало:

IUSE="ayatana gtk gtk3 lightweight qt4 xfs"

RDEPEND="
	>=dev-libs/libevent-2.0.10
	dev-libs/openssl:0
	net-libs/libnatpmp
	>=net-libs/miniupnpc-1.6
	>=net-misc/curl-7.16.3[ssl]
	sys-libs/zlib
	gtk? (
		>=dev-libs/dbus-glib-0.98
		>=dev-libs/glib-2.28
		x11-libs/gtk+:2
		ayatana? ( dev-libs/libappindicator:2 )
		)
	gtk3? (
		>=dev-libs/dbus-glib-0.98
		>=dev-libs/glib-2.28
		>=x11-libs/gtk+:3
		ayatana? ( dev-libs/libappindicator:3 )
		)

Что сложного то в данной ситуации для мантейнера? Это ситуация, когда попадают в систему разные gtk версии программ и приводи дорогой пользователь их к единому виду до посинения. Аналогично с гномами, почему не вести было gnome и gnome3? А выкидывание пакетов из-за якобы отсутствующего мантейнера? Они по нескольку лет не меняют ebuild, а потом замечают, что мантейнер пропал?

Сорри, ошибка в строке >=x11-libs/gtk+:3 - должно быть x11-libs/gtk+:3. Ну не пользую я gtk3.

Что сложного то в данной ситуации для мантейнера?

не могу отвечать за других

Это ситуация, когда попадают в систему разные gtk версии программ и приводи дорогой пользователь их к единому виду до посинения.

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

Аналогично с гномами, почему не вести было gnome и gnome3?

не могу отвечать за других

А выкидывание пакетов из-за якобы отсутствующего мантейнера?

1-оно не выкидывается а marked for removal, по вполне логичным соображениям, и построить правильную логичную цепочку я думаю не составит труда. Далее если пакет действительно нужен, то меинтейнер найдётся, благо proxy-maintainers вполне распространены. Если разговор всё же про отсуствующий апстрим, то тут говорить вобще не очем.

Они по нескольку лет не меняют ebuild, а потом замечают, что мантейнер пропа

давай на живом примере, чтобы проще было на даты и changelog обратить внимание.

И да, это не верный ебилд по причине того, которую я описал выше, при наличии в слотах gtk:3 и gtk:2 флаг gtk приведёт к неправильным последствиям.

ну и да gtk+:3 != gnome3

пацаны, сваливаем на Exherbo, там таких проблем нет

давай на живом примере, чтобы проще было на даты и changelog обратить внимание.

Был маркирован к удалению compiz. Висит правда уже не один месяц как было заявлено, но шуму по этому поводу было много.

И да, это не верный ебилд по причине того, которую я описал выше, при наличии в слотах gtk:3 и gtk:2 флаг gtk приведёт к неправильным последствиям.

Каким именно? По моему это надумано. У меня включилось оформление gtk2 на transmission, сам пакет добротно пашет. И не только у меня. Не раз делился своими ebuild-ами - у всех работало.

Был маркирован к удалению compiz. Висит правда уже не один месяц как было заявлено, но шуму по этому поводу было много.

ну так никто им не занимался висела древняя версия из-за которой начинались проблемы => никто не фиксит => не отвечает требованиям для проги в дереве => mask for removal.

Каким именно? По моему это надумано. У меня включилось оформление gtk2 на transmission, сам пакет добротно пашет. И не только у меня. Не раз делился своими ebuild-ами - у всех работало.

при наличии в системе gtk+:2 и gtk+:3 и флаге gtk программа слинкуется с gtk+:3. Это минимум идеологически неверно.

И да мнение gnome-team «gtk3 is the way to go». Я пока не совсем понимаю почему принято такое решение в случае transmission, пойду поругаюсь с ними, может чего интересного расскажу.

а у меня этот пакет не замаскрирован сейчас. вероятно потомучто я слоупок :<

теме 100 лет, тут уже другие «проблемы» обсуждают.

Пробовал, тяжко на нем сидеть. На exherbo пока только плюс - менеджер пакетов. Хотя портеж очень близок к нему по функционалу. Cave не быстрее, но в состоянии разруливать более тяжелые ситуации. А по факту в exherbo сейчас номинальное количество готовых пакетов и не всегда они полностью соответствуют требованиям. Кроме того придется много написать совсем с нуля. Ключи оптимизации проходят меньшие, чем в gentoo. Разруливание зависимостей не легче.

с portage-2.2, cave начинает ему проигрывать по функционалу, а @preserved-rebuild там вобще нет.

при наличии в системе gtk+:2 и gtk+:3 и флаге gtk программа слинкуется с gtk+:3. Это минимум идеологически неверно.

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

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

Я понимаю, я не спорю с тем, что это работает, но это достаточная причина, чтобы не оказаться в дереве. В общем сейчас надюсь с gnome herd пообщаяться и сообщить официальную позицию, так же попытаться переубедить в отношении transmission и evince (если он умеет gtk+:2) минимум.

Не в курсе - пока пользую 2.1.10.49. А козырь cave - 'круговые зависимости' portage-2.2 уже бьет?

вот решение (наглый хак):

Remove gtk:3 check in order to use gtk:2 only.

diff --git a/configure.ac b/configure.ac
index 1489015..4d3ed0f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -362,9 +362,9 @@ AC_ARG_WITH([gtk], AC_HELP_STRING([--with-gtk],[with Gtk]),
 if test "x$with_gtk" = "x2" ; then
     PKG_CHECK_EXISTS([gtk+-2.0 >= $GTK2_MINIMUM],[gtk_version="2" with_gtk="yes"],[gtk_version="none" with_gtk="no"])
 fi
-if test "x$with_gtk" = "x3" ; then
-    PKG_CHECK_EXISTS([gtk+-3.0 >= $GTK3_MINIMUM],[gtk_version="3" with_gtk="yes"],[gtk_version="none" with_gtk="no"])
-fi
+#if test "x$with_gtk" = "x3" ; then
+#    PKG_CHECK_EXISTS([gtk+-3.0 >= $GTK3_MINIMUM],[gtk_version="3" with_gtk="yes"],[gtk_version="none" with_gtk="no"])
+#fi
 AC_ARG_ENABLE([nls],
               [AS_HELP_STRING([--enable-nls],[enable native language support])],,
               [enable_nls=yes])
lines 1-17/17 (END)

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

Умеют.. Пользовал transmission (переполз на делюгу - там вкупе сервер) и пользую evince с gtk2. В принципе у меня вся система с единым gtk2, чему я несказанно рад. Места мало, работает быстро, оформление можно настроить как душе угодно, да и готовых тем море.

козырь cave - 'круговые зависимости'

А можно поподробнее? Что за козырь? На скорую руку не нагуглилось.

А что, они пилят gentoo/kfreebsd?

Что ты как маленький?

Они портируют нужное людям Open Source ПО и оформляют багрепорты разработчикам, если проблема критичная и решаемая в рамках кросс-платформенности. Или у тебя уже прочная ассоциация: «Open Source == GNU/Linux»?

в смысле, diamond dependencies, или циклические? в portage-2.2 алгоритмы сильно улучшились, но пока ещё не разруливает некоторые моменты, которые можно решить.

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

Зачем загонять себя в ловушку? Ведь всё равно когда-нибудь придётся перелезать на Gtk3.

Смысл понятен. А с sed-ом я не очень дружу - изучал в середине девяностых по книжке 'Введение в Unix' (ISBN 5-85582-005-X), но там как-то очень смутно все описано насчет потокового редактора.

идея в том, чтобы сделать _возможность_ использовать gtk:2 там, где программы её предоставляют, пока я услышал только 1 толковый аргумент почему это может быть плохо. А так никаких проблем в этом подходе нету.

Неверно написал - циклические зависимости

Но ведь portage-2.2 пока замаскирован. Или имеет смысл начать пользоваться? Боязно порушить.

Нет, у меня прочная ассоциация «FreeBSD - неюзабельное поделие».
Уж извини, но порты сильно всасывают по сравнению c portage.

Сижу уже больше года на portage-9999, все работает.

нормально всё, замаскирован в основном, чтобы не перелезали лишний раз. 9999 как ниже не советовал бы, но замаскированые весии <9999 вполне стабильны.

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

iZEN, тут вопрос в том, насколько много нужно переделывать, чтобы сделать интерфейс gtk3 таким же комфортным как gtk2 с точки зрения пользователя обычного ноутбука, а не планшетника. Когда gtk3 приведут в порядок, то можно будет его принять, а пока еще слишком много еще там прибито гвоздями и не настраивается через обычные конфигурционные файлы, да и часть программ еще на gtk2, а часть уже и на gtk3 и из-за этого куча бессмысленных проблем возникает. Не считаю нужным держать все возможные движки и настраивать их, приводя в божеский вид. Ну максимум к gtk2 можно добавить qt, но qt я не люблю за громадные библиотеки, которые вроде призваны уменьшить размер пакетов, а на самом деле еще больше их увеличивают.

По серьезному попробовать давно хотел, но все никак не доходило до дела. Вроде поговаривают, что он пошустрее даже стал. После подготовки iso-ки с моими настройками попробую потестить.

Сейчас хочу дополировать систему (отсюда куча вопросов, на которые ищу хорошие решения), обернуть в iso и залить гентушный стейдж под процессоры атом. А то народ просит (даже на лоре уже прецедент был), а поделится не могу кроме как рекомендациями по оптимизации и настройке. Но компиляция с нуля так, чтобы сразу все гладко вышло не у всех получается, да и время занимает изначальная установка прилично больше, чем установка из стейджа.

Спасибо. Будем поглядеть. Епрст, там уже 108-ая альфа)))

Сейчас хочу дополировать систему (отсюда куча вопросов, на которые ищу хорошие решения), обернуть в iso и залить гентушный стейдж под процессоры атом. А то народ просит (даже на лоре уже прецедент был), а поделится не могу кроме как рекомендациями по оптимизации и настройке. Но компиляция с нуля так, чтобы сразу все гладко вышло не у всех получается, да и время занимает изначальная установка прилично больше, чем установка из стейджа.

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

По поводу гтк: в общем никто не запрещает пропатчить transmission, _но_ необходимо написать ебилд таким образом, чтобы гарантировать то, что не будут загружены одновременно либы для gtk-2 и gtk-3. Что не то, чтобы очевидно (мой вариант был неверным). В общем мне сказали куда копать завтра попробую сделать и запостить на b.g.o, хотя не факт, что примут т.к. это up to maintainer.

собственно варианты:

1). написать gtk2-only пакет в -r200 или т.п. (x11-libs/vte-0.28.1-r200, x11-themes/gtk-engines-xfce)

2). ставить параллельно с gtk3-версию, т.е. делать слот

(1+2) например, webkit-gtk

3). ставить одновременно и то и другое

3 вариант очевидно плох, 1 хорош для приложений, 2 для библиотек.

Вот в общем-то простое объяснение почему это было не сделано сразу :) учитывая, что разные gtk-шники любят иногда поломать совместимость.

концепт в студию

До концепта пока как до китая.. одни идеи(

Что касается зависимостей:

transmission-2.50]$ find -type f -exec grep "include <" {} \;

#include <stdio.h> /* fprintf() */
#include <stdlib.h> /* atoi() */
#include <string.h> /* memcmp() */
#include <signal.h>
#include <libtransmission/transmission.h>
#include <libtransmission/bencode.h>
#include <libtransmission/tr-getopt.h>

...

...

#include <sys/param.h>
#  include <sys/param.h>

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

идея ломать стандартные файлы конфигурации пакетов (если я правильно понял) не самая лучшая идея, в плане легкости поддержки и принципа least surprise. Если я понял неправильно, то рад видеть на примере конкретных программ.

Что касается конфигурационных файлов (в /etc и др.), то иметь три слоя не так плохо как кажется.

1.В основном стандартные обобщенные параметры для работы пакета без нюансов.

2.В профильном уже контекстно зависимые от профиля и возможно изменяющие параметры основного слоя.

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

Конечный конфигурационный файл генерируется на основе конкатенции этих слоев, но с переопределением значений переменных.

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

Пример:

в основном слое

# This blank configuration will automatically use DHCP for any net.*
# scripts in /etc/init.d.  To create a more complete configuration,
# please review /usr/share/doc/openrc*/net.example* and save your configuration
# in /etc/conf.d/net (this file :]!).

# Only needed if you have more than one DHCP module installed

в профильном (dhcp wifi)

modules="dhcpcd"
config_wlan0="dhcp"
dhcpcd_wlan0="-t 10"
dhcp_wlan0="release nodns nontp nonis"
slaves_bond0="wlan0"
config_bond0="null"
rc_need_bond0="net.wlan0"

slaves_bond0+="eth0"
rc_need_bond0+="net.eth0"

При обновлениях затрагиваются только те слои, которые к ним относятся, не трогая личных настроек.

В принципе это очень грубая хотелка избавится от анализа всех строчек обновляемых конфигурационных файлов)))

P.S.

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

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

Автоматизация возможно для систем сборки полагающихся на пакетную систему с центральным репозиторием (в этом случае можно оттуда брать и обновления) или явной системой пакетов, как я уже говорил примеры это g-ctan (CTAN для Tex), g-cpan для перла, hackport для haskell. Подробно могу рассказать про последний, там автоматом находятся все haskell зависимости, по спец эвристикам определяются зависимости от c-пакетов и если не возможно, то это передаётся юзеру, пока не выдёргиваются флаги но это вопрос времени. Тут всё просто т.к. все пакеты ставятся совершенно однотипно, в сишных библиотеках же появляется куча проблем с тем как прописать файлы, куда, что переложить, чтобы было верно, прописать правильные правда файлам, положить документацию куда надо, и т.д. при этом вопрос о флагах, что выносить в USE, что оставлять для EXTRA_ECONF, что совместимо с какой архитектурой и как флаги совместимы между собой может быть решён только человеком при этом только при тестировании пакета. Причём желательно, чтобы мейнтейнер был активным пользователем либы и мог проверить хитрые use case (проблема возникшая у крона в этом треде с zabbix и fping). Некой доли автоматизации добиться можно, тут есть несколько, направлений выделение общих функций (развите eclass) благодаря чему написание ебилда упрощается от версии к версии, написание автоматических генераторов, но тут скорее всего нужно будет писать сложные парсеры для каждой из билд-систем, что очень не факт, что оправдано.

Как-то так обстоит ситуация.

3 вариант очевидно плох, 1 хорош для приложений, 2 для библиотек.

2 вариант тоже не фонтан (смысла нет иметь неиспользуемые библиотеки) - это уже когда нет варианта с однотипным интерфейсом как в случае с qt(

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

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

да хотел указать в этом направлении, два года назад на GSC Лаутре рассказывал, что они пытаются сделать, выглядело логично, но на мой взгляд сложно в поддержке со стороны мейнтейнеров, для бинарного суб-дистрибутива с чёткой целевой группой это вполне осиливается, но для мета-дистрибутива, каким является гента в том виде, решение, мне кажется, не реализуемо. Хотя прошло 2 года может быть шаблоны превратились во что-то адекватное.

как я понял, основная идея в возможности импорта/экспорта конфигов во внутренний формат и как следствие перенос их между версиями программы или даже между разными программами выполняющими одну функцию (что смотрится минимум интересно). И там используется очень похожая схема и xml и xslt во все поля :).

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

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

Насколько слышал они развивают постоянно свои наработки. Надо будет посмотреть может они уже документацию зарядили по ним.

А я думал, что они ставятся в этом случае вместе. Проморгал. От 'двойных' слотов, кстати, почти удалось почистить систему, но не все пока осилил.

а нельзя в апстим послать патч для configure с доп. ключом --force-gtk2 ?

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

ну им-то по сути от такого патча ни горячо, ни холодно, а всем дистростроителям удобно

Такой классный когда-то дистрибутив убили :-/

При пяти звёздах уже пора бы знать, что дистрибутив и ОС - разные вещи. Дистрибутив - форма распространения ПО, у него есть синонимы типа «установщик», «инсталятор».

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

Забавно. На одной из машин, где эта ошибка 23-го вылезала, если вручную замаскировать =sys-kernel/linux-headers-3.3, то при emerge -av1 virtual/os-headers он теперь предлагает честный downgrade до 3.1 без ошибок.

Пришлось теперь также и на второй сделать: поломали linux-headers (комментарий)

А то =sys-apps/busybox-1.19.3-r1: не собирался. Можете прописать там в требования, чтобы sys-kernel/linux-headers-3.1 был :)

я правильно понял, что стабильный бизибокс (1.19.3-к1) не собирается с нестабильным linux-headers (3.3)?