Windows vs. Linux , Продолжение

Цитата Keepun @ 01.07.12, 13:47

Чтоб не набирать #emerge -p -C пакет несколько раз.

Зачем несколько раз? Ему же сразу несколько пакетов можно указать, нет?

Цитата Keepun @ 01.07.12, 13:47

А мне пришло

Ну а теперь наведи причинно-следственные связи: мне не пришло - у меня нет проблем, тебе пришло - у тебя есть проблемы
Не будем спорить и кричать "Глюк"/"Не глюк". Давай по-взрослому? Если ты считаешь, что это баг, то опиши его как на баг-треккере, самое главное - как воспроизвести.

Топик еще немного и можно переименовывать в Linux vs Linux

Мяут-Настоящий, а ты про зависимости не забыл?
И мне каждый раз придется разбирать "что не так", когда я начну менять ключи сборки...

Дистр Линя выглядит простым, пока ты юзаешь то, что его создатели учли. А захочешь че-нибудь изменить, то появляются не предвиденные проблемы.

Добавлено 01.07.12, 17:47

Цитата Adil @ 01.07.12, 15:29

Ну а теперь наведи причинно-следственные связи: мне не пришло - у меня нет проблем, тебе пришло - у тебя есть проблемы

Удобная позиция: "Я не знаю как это работает и не юзал никогда, поэтому это ты все неправильно сделал"

Еще раз может прочесть про ключи emerge и глянуть в его исходники (прикинь, они открыты), если не веришь, что я правильно поступил.

Цитата Adil @ 01.07.12, 15:29

Если ты считаешь, что это баг, то опиши его как на баг-треккере, самое главное - как воспроизвести.

Воспроизвести смогу, а вот вряд ли его исправят.
#revdep-rebuild ищет потерянные либы (смотри ldd). А тут меняется содержимое либы, а не ее версия.

Полное устранение этого бага выглядит так:
#equery d glib
и создаем скрипт на пересборку, потому что emerge не может сделать это сам.

Цитата Keepun @ 01.07.12, 17:28

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

Я собирал свою версию python с включенным дебагом - и ничего

А если хочешь что-нибудь менять, начинай с LFS, чего мелочиться-то?

Цитата Keepun @ 01.07.12, 17:28

Удобная позиция: "Я не знаю как это работает и не юзал никогда, поэтому это ты все неправильно сделал"

Как раз - наоборот, я давно знаю, как устроена передача электроэнергии и давно не сую пальцы в розетку. Но если тебе это доставляет удовольствие, твое право.

Цитата Keepun @ 01.07.12, 17:28

Воспроизвести смогу, а вот вряд ли его исправят.
#revdep-rebuild ищет потерянные либы (смотри ldd). А тут меняется содержимое либы, а не ее версия.

Полное устранение этого бага выглядит так:
#equery d glib
и создаем скрипт на пересборку, потому что emerge не может сделать это сам.

Ты-то сможешь - я в тебя верю. Но вот только багом, как это не удивительно, это будет считаться только после воспроизведения другими. А речи, типа "Я там ковырнул, тут подправил, а оно мне - бах! я ему - тынц, а оно все-равно шнягу пишет" - оставь для своих одноклассников.
И так, взрослого описания бага ты сделать не можешь.

И про изменение какой еще либы ты говоришь? world-файл - это либа? Или ты правил исходники GTK+? Мальчик, ты уж либо говори членораздельно, либо вынь пальцы из розетки.

Добавлено 01.07.12, 21:07

Цитата Uncle_Bob @ 01.07.12, 17:11

Топик еще немного и можно переименовывать в Linux vs Linux

Да если бы! Keepun ещё тот линуксоид с вендузятным воспитанием.

Цитата Keepun @ 01.07.12, 17:28

Дистр Линя выглядит простым, пока ты юзаешь то, что его создатели учли. А захочешь че-нибудь изменить, то появляются не предвиденные проблемы.

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

Цитата Adil @ 01.07.12, 20:48

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

Наивный
Я уже вписал свой ник в репу Генту Ищи в ChangeLog от NCurses.

А этот баг воспроизводится так:
Ставишь последнию стабильную GLib 2.3x
Пересобираешь все от нее зависящие.
Потом ставишь GLib 2.30 (emerge мне сам ее откатил по требования зависимости (проклятье Линя))
А теперь радуйся сообщениям "Не найдена g_mutex_lock" и т.п.

Помощи просить у revdep-rebuild бессмысленно в этом случае.

Цитата Мяут-Настоящий @ 01.07.12, 19:36

Я собирал свою версию python с включенным дебагом - и ничего

нахрена? дебажных пакетов нет?

Цитата Keepun @ 01.07.12, 21:41

Ставишь последнию стабильную GLib 2.3x ... Потом ставишь GLib 2.30

Э-мм, и как это соотносится с

Цитата Keepun @ 01.07.12, 17:28

А тут меняется содержимое либы, а не ее версия.

К тому же:

#emerge --sync > /dev/null
#eix-update > /dev/null
#eix -I glib
[I] dev-libs/glib
     Available versions:  
    (1) 1.2.10-r5
    (2) 2.30.2 2.30.3 [COLOR=red]~2.32.2 ~2.32.3[/COLOR]
    {debug doc fam hardened kernel_linux selinux (+)static-libs systemtap test utils xattr}
     Installed versions:  2.30.3(2)(10:49:05 01.05.2012)(static-libs -debug -doc -fam -selinux -systemtap -test -utils -xattr)
     Homepage:            http://www.gtk.org/
     Description:         The GLib library of C routines

И как мне поставить последнюю "стабильную GLib 2.3x", а потом откатиться назад к GLib 2.30, если последняя стабильная и есть GLib2.30? Так ты, батенька, еще и на нестабильном профиле сидишь, и еще на что-то жалуешься?
Вынул бы пальцы то ужо из розетки.

Цитата Adil @ 02.07.12, 05:31

Так ты, батенька, еще и на нестабильном профиле сидишь, и еще на что-то жалуешься?

Открою тебе страшную тайну: Гном 3 до сих пор не стабилизировали. И вряд ли стабилизируют (много времени прошло). Поэтому сидеть на "нестабильной ветке Гнома 3" заставляют сами майнтейнеры Генту. КЕДы для них важнее, поэтому их часто стабилизируют.

Если ты прочтешь начало этой истории, то я указал, что избавлялся от Гнома 3 (потому что КЕДы лучше).
dev-libs/glib-2.32 не стабилизирована? ну хрен с ней! Но работала она нормально. Emerge мне откатил ее на стабильную версию, после этого все и сдохло.

Сама проблема:
Почему собранные пакеты с glib-2.32 (не сама либа, а зависимости от нее) стали несовместимы с самой либой glib-2.30? И как такие сломанные зависимости должен разруливать revdep-rebuild?

Цитата Keepun @ 02.07.12, 13:27

Поэтому сидеть на "нестабильной ветке Гнома 3" заставляют сами майнтейнеры Генту. КЕДы для них важнее, поэтому их часто стабилизируют.

Вот блин, какие они, эти майнтейнеры плохие дяденьки - зажимают, понимаешь Гном3! Наверно, на зарплате у кде.орг сидят.

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

Цитата Keepun @ 02.07.12, 13:27

Почему собранные пакеты с glib-2.32 (не сама либа, а зависимости от нее) стали несовместимы с самой либой glib-2.30

О блин, а что они должны быть совместимы? Представь, что они использовали фичи, которых ещё не было в 2.30? Что-то ты совсем запутался в показаниях.

Цитата Adil @ 02.07.12, 14:52

Что-то ты совсем запутался в показаниях.

В каких? Как воспроизвести - я описал (сам же просил). А теперь указываешь на то, что я виноват, потому что в revdep-rebuild сложно реализовать такую проверку

Цитата Adil @ 02.07.12, 14:52

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

А о каком "признаке стабильности" пост? Это такое мифическое чудовище? Его даже описать сложно...

Цитата Adil @ 02.07.12, 14:52

О блин, а что они должны быть совместимы? Представь, что они использовали фичи, которых ещё не было в 2.30?

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

Во-вторых: все, что собралось glib-2.32 без новых функций не должно (это твоя логика) собираться с glib-2.30? А оно собирается. Только пересборку нужно провести (в этом случае) с мелких либ, а emerge сразу с крупных начинает.

Тут задача на разруливание зависимостей, которую технически решить не просто.

Но эти зависимости ради маленького экономия месте на ЖД записывают в "+" Линя против Виня (DLL Hell давно стал историей)

Добавлено 02.07.12, 18:57
В "c:\Program Files (x86)\" у меня ДеЛЛок на 2 216МБ.
Из них ДеЛЛок с общими именами на 657МБ.
Много из них не совпадают по размеру. Чтоб было по честному, то реально из низ наверно 500МБ можно попытаться вынести в общею папку.

Вопрос: Стоит ли мне имея раздел в 100ГБ, пытаться сэкономить на этих 500МБ и получить заботу о зависимостях, как это мне предлагают в Лине?

Цитата Keepun @ 02.07.12, 18:29

Вопрос: Стоит ли мне имея раздел в 100ГБ, пытаться сэкономить на этих 500МБ и получить заботу о зависимостях, как это мне предлагают в Лине?

Думаю, когда это пара десятков виртуалок в облаке, это не так уж плохо. А учитывая что современный серверный Линь по сравнению с "серверной" виндой (я надеюсь, хоть плитку из нее выпилят) весит на порядок меньше - так вообще шыкарно!

Server Core не предлагать, а диффать до просветления Get-WindowsFeatures

Цитата Keepun @ 02.07.12, 18:29

В каких? Как воспроизвести - я описал (сам же просил). А теперь указываешь на то, что я виноват, потому что в revdep-rebuild сложно реализовать такую проверку

То ты говорил, что версия не меняется, меняется содержимое библиотеки.

Цитата Keepun @ 01.07.12, 17:28

А тут меняется содержимое либы, а не ее версия.

Потом оказалось, что меняется версия.

Цитата Keepun @ 01.07.12, 21:41

Ставишь последнию стабильную GLib 2.3x
Пересобираешь все от нее зависящие.
Потом ставишь GLib 2.30

Ты уж как то стабилизируйся, что ли.

Цитата Keepun @ 02.07.12, 18:29

А о каком "признаке стабильности" пост? Это такое мифическое чудовище? Его даже описать сложно...

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

Цитата Keepun @ 02.07.12, 18:29

Но эти зависимости ради маленького экономия месте на ЖД записывают в "+" Линя против Виня (DLL Hell давно стал историей)

Ты бы лучше для начала разобрался, что такое DLL. Основной профит-то - не экономия места на диске, а экономия места в ОЗУ, ибо секции кода ДЛЛ-ек разделяются между приложениями. Вот и подумай, стоит ли тебе экономить 500МБт ОЗУ, которого у тебя не 100ГБт, а чутка меньше?
Короче, учи матчасть, а потом уже спорь с взрослыми дяденьками.

# ls -l /usr/lib/libgth*
-rw-r--r-- 1 root root 22216 июня  27 00:36 /usr/lib/libgthread-2.0.a
lrwxrwxrwx 1 root root    26 июня  27 00:36 /usr/lib/libgthread-2.0.so -> libgthread-2.0.so.0.3000.3
lrwxrwxrwx 1 root root    26 июня  27 00:36 /usr/lib/libgthread-2.0.so.0 -> libgthread-2.0.so.0.3000.3
-rwxr-xr-x 1 root root 18696 июня  27 00:36 /usr/lib/libgthread-2.0.so.0.3000.3
 
# ACCEPT_KEYWORDS="~amd64" emerge -1 ">=dev-libs/glib-2.32"
[ebuild     U  ] dev-libs/glib-2.32.3 [2.30.3] USE="-static-libs*"
 
# ls -l /usr/lib/libgth*
lrwxrwxrwx 1 root root   26 июля   3 14:19 /usr/lib/libgthread-2.0.so -> libgthread-2.0.so.0.3200.3
lrwxrwxrwx 1 root root   26 июля   3 14:19 /usr/lib/libgthread-2.0.so.0 -> libgthread-2.0.so.0.3200.3
-rwxr-xr-x 1 root root 5920 июля   3 14:19 /usr/lib/libgthread-2.0.so.0.3200.3
 
# emerge -1 =x11-libs/gtk+-2.24.10-r1
no errors
 
# emerge -1 =x11-libs/pango-1.29.4
no errors
 
# emerge -1 =x11-libs/gtk+-2.24.10-r1
no errors
 
# emerge -1 glib
>>> Emerging (1 of 1) dev-libs/glib-2.30.3
no errors
 
# ls -l /usr/lib/libgth*
-rw-r--r-- 1 root root 22216 июля   3 14:39 /usr/lib/libgthread-2.0.a
lrwxrwxrwx 1 root root    26 июля   3 14:39 /usr/lib/libgthread-2.0.so -> libgthread-2.0.so.0.3000.3
lrwxrwxrwx 1 root root    26 июля   3 14:39 /usr/lib/libgthread-2.0.so.0 -> libgthread-2.0.so.0.3000.3
-rwxr-xr-x 1 root root 18696 июля   3 14:39 /usr/lib/libgthread-2.0.so.0.3000.3
 
# emerge -1 =x11-libs/gtk+-2.24.10-r1
libtool: link: gcc -o /tmp/portage/x11-libs/gtk+-2.24.10-r1/work/gtk+-2.24.10/gdk/tmp-introspectvypko0/.libs/Gdk-2.0 -DGDK_PIXBUF_DISABLE_DEPRECATED -O2 -march=native -pipe -Wall
-pthread /tmp/portage/x11-libs/gtk+-2.24.10-r1/work/gtk+-2.24.10/gdk/tmp-introspectvypko0/Gdk-2.0.o -Wl,--export-dynamic  -L. ./.libs/libgdk-x11-2.0.so
-lpangocairo-1.0 -lpango-1.0 /usr/lib64/libfontconfig.so -lfreetype -lz -lbz2 -lexpat -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite
-lXdamage -lXfixes -lgdk_pixbuf-2.0 -lcairo -lX11 -lm -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libpangocairo-1.0.so: undefined reference to `g_mutex_trylock'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libpangocairo-1.0.so: undefined reference to `g_mutex_unlock'
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `g_mutex_lock'
collect2: ld returned 1 exit status
 
# revdep-rebuild -i
No ERRORS!

=x11-libs/pango-1.29.4 собирается так:
/bin/sh ../../libtool --silent --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -DG_LOG_DOMAIN=\"Pango\" -DPANGO_ENABLE_ENGINE -DPANGO_ENABLE_DEBUG -I../.. -I../../pango -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include   -I/usr/include/freetype2 -Wall -c -o arabic-fc.lo arabic-fc.c
  CC     arabic-ot.lo

Если кто-то (Adil) не понял, то - это воспроизведение сценария, когда зависимости - ЗЛО!

-lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0
Все они указывают на ссылки, имена которых не меняются. А куда эти ссылки ведут... вот из-за этого revdep-rebuild тупит

Только пересборкой x11-libs/pango (в глобальном масштабе), как я сначала думал, тут не обойтись
# equery d glib и вперед! - об этом я выше постил.

Цитата Adil @ 03.07.12, 06:05

Ты бы лучше для начала разобрался, что такое DLL. Основной профит-то - не экономия места на диске, а экономия места в ОЗУ, ибо секции кода ДЛЛ-ек разделяются между приложениями. Вот и подумай, стоит ли тебе экономить 500МБт ОЗУ, которого у тебя не 100ГБт, а чутка меньше?

Запомни: спорить о менеджере памяти - это неблагодарное занятие!

Я знаю, что такое DLL. А вот ты явно не знаешь, что Винь сначала проверяет: загружена ли уже такая ДЛЛка в память.
Если есть несколько идентичных копий ДЛЛки в разных папках, то загружена будет только одна.

Если бы это не так, то множество копий msvcr*.dll и остальных уже бы выжрали все Гбайты оперативы

Цитата Adil @ 03.07.12, 06:05

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

Сообщение отредактировано: Keepun - 03.07.12, 12:10

Цитата Keepun @ 03.07.12, 12:00

Я знаю, что такое DLL. А вот ты явно не знаешь, что Винь сначала проверяет: загружена ли уже такая ДЛЛка в память.
Если есть несколько идентичных копий ДЛЛки в разных папках, то загружена будет только одна.

Сам себе противоречишь - как такое поведение спасёт от DLL Hell? Или при вызове LoadLibrary("some.dll") винда телепатически угадывает, что проге нужна some.dll версии v2.0, а не v1.0, уже загруженная в память? Тебя обманули Свидетели ИеМикрософт, когда сказали, что Виндоуз умеет телепатию.

Цитата Keepun @ 03.07.12, 12:00

Если бы это не так, то множество копий msvcr*.dll и остальных уже бы выжрали все Гбайты оперативы

У тебя на компе множество копий идентичных msvcr*.dll? Не верю.

Цитата Keepun @ 03.07.12, 12:00

Если кто-то (Adil) не понял, то - это воспроизведение сценария, когда зависимости - ЗЛО!

Навскидку - если кто не понял, то Keepup про флаг --deep (сборка/пересборка с учетом зависимостей) не знает. Или делает вид, что не знает