firefox 4 (установка)

[drBatty]

При выборе libglib2.0-0 (>= 2.25.15) предлагается собственно снести пол системы )

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

вот что нагуглил http://ithappens.ru/story/5412

[diesel]

При выборе libglib2.0-0 (>= 2.25.15) предлагается собственно снести пол системы )

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

можно .. но тогда это уже будет нифига не stable.

[drBatty]

можно .. но тогда это уже будет нифига не stable.

честно говоря я не знаю, можно-ли собрать FF4 под старую glib. Думаю проще сменить саму glib. в Slackware relase тоже нет FF4, вот пользуюсь current и жду... Мне ждать осталось недолго...

[diesel]

можно .. но тогда это уже будет нифига не stable.

честно говоря я не знаю, можно-ли собрать FF4 под старую glib. Думаю проще сменить саму glib. в Slackware relase тоже нет FF4, вот пользуюсь current и жду... Мне ждать осталось недолго...

можно ) собственно FF с оф сайта вполне себе запускается поэтому при особом желании можно и собрать

[t.t]

По-прежнему непонятно, чем ff4 из experimental не устраивает.

iceweasel 4.0 -> libgdk-pixbuf2.0-0 -> libglib2.0-0 (>= 2.25.15)

При выборе libglib2.0-0 (>= 2.25.15) предлагается собственно снести пол системы )

Конкретнее. libglib2.0-0 версии 2.28.4-1 зависит ровно от одного пакета из testing -- libpcre3 (>= 8.10); который в свою очередь зависит всего от одного пакета -- libc6, -- причём версия из stable его вполне устраивает.

При выборе libglib2.0-0 (>= 2.25.15) предлагается собственно снести пол системы )

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

вот что нагуглил http://ithappens.ru/story/5412

Советы убеждённого слакварщика в разделе Debian смотрятся, мягко говоря, не совсем уместно.

[drBatty]

Советы убеждённого слакварщика в разделе Debian смотрятся, мягко говоря, не совсем уместно.

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

[t.t]

Советы убеждённого слакварщика в разделе Debian смотрятся, мягко говоря, не совсем уместно.

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

Неправы. В данный момент, как я уже заметил выше, libglib из testing зависит ровно от одного пакета не из stable -- libpcre3 из testing, который ставится в stable вообще вчистую. Другими словами, если не пугает "смешанная система", то в glib проблемы точно быть не должно. А раз речь идёт об установке iceweasel из experimental, то пара пакетов из testing смущать точно не должна.

[diesel]

Советы убеждённого слакварщика в разделе Debian смотрятся, мягко говоря, не совсем уместно.

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

Неправы. В данный момент, как я уже заметил выше, libglib из testing зависит ровно от одного пакета не из stable -- libpcre3 из testing, который ставится в stable вообще вчистую. Другими словами, если не пугает "смешанная система", то в glib проблемы точно быть не должно. А раз речь идёт об установке iceweasel из experimental, то пара пакетов из testing смущать точно не должна.

вообще вопрос не в том от чего зависит glib, а что зависит от него. В принципе, если выключить "рекомендации", то список на удаление получается меньше, но с первого раза разгрести зависимости все-равно не получилось, второй раз не пытался - времени нет, да и не сильно оно мне щас надо.

[drBatty]

Неправы. В данный момент, как я уже заметил выше, libglib из testing зависит ровно от одного пакета

спасибо. я этого не знал.

[t.t]

вообще вопрос не в том от чего зависит glib, а что зависит от него. В принципе, если выключить "рекомендации", то список на удаление получается меньше, но с первого раза разгрести зависимости все-равно не получилось, второй раз не пытался - времени нет, да и не сильно оно мне щас надо.

А что же там есть из "зависящих от него" со строгим указанием версии (ну, кроме libglib-dev)? Мне встречалось только >=. Насчёт "не получилось" я просил указать конкретику не просто так. По опыту общения с aptitude знаю, что все "страшные косяки на полтыщщи пакетов" вылезают из-за одной-двух пропущенных мелочей. Если их поправить, всё сразу становится не на свои места.

В общем и целом я вот о чём: доказать мне, что iceweasel 4 в stable без танцев с бубном не становится, будет сложно, т.к. у меня он там стоит, и я потратил на его установку не более минуты.

[drBatty]

Мне встречалось только >=. Насчёт "не получилось" я просил указать конкретику не просто так. По опыту общения с aptitude знаю, что все "страшные косяки на полтыщщи пакетов" вылезают из-за одной-двух пропущенных мелочей. Если их поправить, всё сразу становится не на свои места.

тут вы правы, но эти мелочи могут лежать там месяцами, и никак себя не проявлять, а в один прекрасный момент ВНЕЗАПНО появляются полтыщща пакетов :(
У меня в мандриве так было. У многих такое в дебе. У меня не было, ибо я очень осторожен с этим вашем apt-get.

В общем и целом я вот о чём: доказать мне, что iceweasel 4 в stable без танцев с бубном не становится, будет сложно, т.к. у меня он там стоит, и я потратил на его установку не более минуты.

зависимостей >= там очень много, и не факт, что они _всегда_ будут >=. Возможен вариант, когда в один "прекрасный" момент они станут >= && <=, как например случилось с adobe flash - memcpy всю жизнь работала так, а тут её "подправили". И кое-что рухнуло...

То, что вы потратили "меньше минуты" ни о чём не говорит - сегодня у вас работает, а завтра _может_ рухнуть. (правда, тут не вина apt-get, rpm тут ни чем не лучше, я уж молчу про слаку...)

[t.t]

В общем и целом я вот о чём: доказать мне, что iceweasel 4 в stable без танцев с бубном не становится, будет сложно, т.к. у меня он там стоит, и я потратил на его установку не более минуты.

зависимостей >= там очень много, и не факт, что они _всегда_ будут >=. Возможен вариант, когда в один "прекрасный" момент они станут >= && <=, как например случилось с adobe flash - memcpy всю жизнь работала так, а тут её "подправили". И кое-что рухнуло...

Не забывайте, что это non-free. В main и contrib такого как правило не возникает в принципе. Если вдруг где-то (в т.ч. в non-free) появится <=, никто не мешает и этот пакет обновить тоже.

Мне встречалось только >=. Насчёт "не получилось" я просил указать конкретику не просто так. По опыту общения с aptitude знаю, что все "страшные косяки на полтыщщи пакетов" вылезают из-за одной-двух пропущенных мелочей. Если их поправить, всё сразу становится не на свои места.

тут вы правы, но эти мелочи могут лежать там месяцами, и никак себя не проявлять, а в один прекрасный момент ВНЕЗАПНО появляются полтыщща пакетов
У меня в мандриве так было. У многих такое в дебе. У меня не было, ибо я очень осторожен с этим вашем apt-get.

То, что вы потратили "меньше минуты" ни о чём не говорит - сегодня у вас работает, а завтра _может_ рухнуть. (правда, тут не вина apt-get, rpm тут ни чем не лучше, я уж молчу про слаку...)

Ви мине будете рассказывать! У меня на рабочих машинах смеси с тех времён, когда sarge был ещё testing. Если ставить всё только с debian.org, проблем не возникает. Последнее время не возникает проблем и с debian-multimedia.org.

[drBatty]

Не забывайте, что это non-free. В main и contrib такого как правило не возникает в принципе. Если вдруг где-то (в т.ч. в non-free) появится <=, никто не мешает и этот пакет обновить тоже.

а это обычно возможно не сразу. если A и Б зависит от Х, то может возникнуть ситуация, когда нам надо 2 Х - старый для А, и новый для Б. Может-ли ваш apt-get поставить две glibc сразу? Получается, что мы обновим X (или Б), что потянет обновление Б (или Х), и А у нас сломается. Ибо версия Х слишком нова для А.

В этом случае, обновление ВНЕЗАПНО порушит какой-то компонент системы (что, согласитесь, очень неприятно), и нам придётся ждать, пока разраб А не сделает версию для новой Х. И ждать долго, если А - non-free.

Ви мине будете рассказывать! У меня на рабочих машинах смеси с тех времён, когда sarge был ещё testing. Если ставить всё только с debian.org, проблем не возникает.

я согласен, в debian очень внимательны с зависимостями, и проблем обычно не возникает. но вот какая-нить кубунта таким похвастаться вряд-ли сможет. Да и что может сделать маинтейнер, ежели сам программный комплекс слишком сложный? Ну как Gnome например. У вас Gnome?

[taaroa]

Да и что может сделать маинтейнер, ежели сам программный комплекс слишком сложный? Ну как Gnome например. У вас Gnome?

stable api nonsens. насколько он сложный, этот программный комплекс? товарищи (клиенты/пациенты/разработчики/etc) с bugs.gentoo.org вам расскажут в мельчайших подробностях, с логами и бэктрэйсами.
_одна_ программка (сходу) требует новую glibc, которая требует новый gcc...

[drBatty]

насколько он сложный, этот программный комплекс? товарищи (клиенты/пациенты/разработчики/etc) с bugs.gentoo.org вам расскажут в мельчайших подробностях, с логами и бэктрэйсами.

не совсем понял, о чём вы?

[taaroa]

насколько он сложный, этот программный комплекс? товарищи (клиенты/пациенты/разработчики/etc) с bugs.gentoo.org вам расскажут в мельчайших подробностях, с логами и бэктрэйсами.

не совсем понял, о чём вы?

Может-ли ваш apt-get поставить две glibc сразу? Получается, что мы обновим X (или Б), что потянет обновление Б (или Х), и А у нас сломается. Ибо версия Х слишком нова для А.

[drBatty]

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

[watashiwa_daredeska]

Может-ли ваш apt-get поставить две glibc сразу?

Может, если есть соответствующие пакеты. И это имеет смысл, если соответствующие программы скомпилированы так, чтобы искать libc в соответствующем месте. И так во всех до единого бинарных дистрибутивах, даже в GoboLinux.

В этом случае, обновление ВНЕЗАПНО порушит

Только если зависимости неправильно прописаны. APT не ломает зависимости, если его очень-Очень-ОЧЕНЬ сильно не попросить.

[drBatty]

Может, если есть соответствующие пакеты. И это имеет смысл, если соответствующие программы скомпилированы так, чтобы искать libc в соответствующем месте. И так во всех до единого бинарных дистрибутивах, даже в GoboLinux.

да-да. для этого надо скомпиллить программу А, так, что-бы она искала старую X например в usr/local/. Либу-то я скомпиллю, но в случае, если А - нонфри, то в /usr/local/ нужно _новую_ компиллить. И соответственно, чуть более чем весь новый софт - туда-же. Если у вас Gentoo, это в общем-то не сложно. В слаке чуть сложнее (но тоже можно). Перебрать десктопный дебиан...

Только если зависимости неправильно прописаны. APT не ломает зависимости, если его очень-Очень-ОЧЕНЬ сильно не попросить.

вы не поняли - в зависимостях написано version >= 666, и ВНЕЗАПНО оказывается, что 666 <= version <=776, ибо начиная с 777й не работает. О чём естественно никто "не знал" когда-то давно, при создании версии 666. И как случилось с флешем, когда в новой glibc функция memcpy() стала работать чуть иначе. Что вполне допустимо, ибо по стандарту она вообще не обязана работать в этом случае, а может с лёгкостью разделить на ноль. Но в адобе об этом "забыли".

PS: да, апт в этом случае видимо прибьёт флеш. и будет в общем-то прав... Если в дебе пропишут, что его надо убить...

[taaroa]

две glibc

Может, если есть соответствующие пакеты. И это имеет смысл, если соответствующие программы скомпилированы так, чтобы искать libc в соответствующем месте. И так во всех до единого бинарных дистрибутивах, даже в GoboLinux.

ага, чОрная магия. и во всех бинарных дистрибутивах её можно смело откатывать до младшей версии, делать downgrade? без всяких последствий?
справка: glibc не обладает совместимостью сверху вниз.
sys-devel/gcc-4.6.0 double free or corruption with =sys-libs/glibc-2.11* для примера.

2.36. Why shall glibc never get installed on GNU/Linux systems in /usr/local?
{AJ} The GNU C compiler treats /usr/local/include and /usr/local/lib in a special way, these directories will be searched before the system directories. Since on GNU/Linux the system directories /usr/include and /usr/lib contain a --- possibly different --- version of glibc and mixing certain files from different glibc installations is not supported and will break, you risk breaking your complete system. If you want to test a glibc installation, use another directory as argument to --prefix. If you like to install this glibc version as default version, overriding the existing one, use --prefix=/usr and everything will go in the right places.

[watashiwa_daredeska]

PS: да, апт в этом случае видимо прибьёт флеш. и будет в общем-то прав...

Совсем не обязательно. Меня он спрашивает, ибо есть варианты: прибить, например, флеш или не обновлять libc. Аналогичная проблема как-то вылезла с несовместимостью iceweasel и libcairo какой-то версии. Да, поначалу я на этот глюк наступил, но после соответствующего выяснения обстоятельств сопровождающий пометил iceweasel как несовместимый с этой версией libcairo, и некоторое время libcairo и iceweasel не обновлялись, пока новые версии не стали доступны в этой ветке Debian. Те, кто наступил на эти грабли раньше, чем среагировал сопровождающий, имели возможность воспользоваться apt_preferences.

в зависимостях написано version >= 666, и ВНЕЗАПНО оказывается, что 666 <= version <=776, ибо начиная с 777й не работает.

В Debian stable этого обычно внезапно не оказывается, ибо версии не меняются на протяжении жизненного цикла. А если очередная версия какой-нибудь нонфри перестает работать со stable, это уже проблема нонфри, а не stable.

Либу-то я скомпиллю, но в случае, если А - нонфри, то в /usr/local/ нужно _новую_ компиллить.

Уродовать систему ради нонфри? Лучше нонфришную A изуродовать через LD_LIBRARY_PATH и/или LD_PRELOAD.

и во всех бинарных дистрибутивах её можно смело откатывать до младшей версии, делать downgrade?

При чем тут downgrade? Речь идет о двух одновременно установленных версиях библиотеки. Их определенно надо собрать с разными именами и собрать программы так, чтобы они искали эти библиотеки с соответствующими измененными именами.

[t.t]

Не забывайте, что это non-free. В main и contrib такого как правило не возникает в принципе. Если вдруг где-то (в т.ч. в non-free) появится <=, никто не мешает и этот пакет обновить тоже.

а это обычно возможно не сразу. если A и Б зависит от Х, то может возникнуть ситуация, когда нам надо 2 Х - старый для А, и новый для Б. Может-ли ваш apt-get поставить две glibc сразу? Получается, что мы обновим X (или Б), что потянет обновление Б (или Х), и А у нас сломается. Ибо версия Х слишком нова для А.

В этом случае, обновление ВНЕЗАПНО порушит какой-то компонент системы (что, согласитесь, очень неприятно), и нам придётся ждать, пока разраб А не сделает версию для новой Х. И ждать долго, если А - non-free.

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

Ви мине будете рассказывать! У меня на рабочих машинах смеси с тех времён, когда sarge был ещё testing. Если ставить всё только с debian.org, проблем не возникает.

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

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

Да и что может сделать маинтейнер, ежели сам программный комплекс слишком сложный? Ну как Gnome например. У вас Gnome?

У меня IceWM, но уж это-то здесь при чём? Сомнения относительно non-free я ещё как-то могу понять (да и то см. самое начало этого поста), а уж в свободном ПО такую проблему даже представить сложно.

Вообще, всё это теоретизирование. Теоретически такая ситуация возникнуть может. Практически её вероятность пренебрежимо мала.

[drBatty]

В Debian stable этого обычно внезапно не оказывается, ибо версии не меняются на протяжении жизненного цикла. А если очередная версия какой-нибудь нонфри перестает работать со stable, это уже проблема нонфри, а не stable.

я с вами согласен. и дебиановцы согласны. А вот Линус - не согласен

У меня IceWM, но уж это-то здесь при чём?

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

Вообще, всё это теоретизирование. Теоретически такая ситуация возникнуть может. Практически её вероятность пренебрежимо мала.

в убунте с гномом/юнити - постоянно. У нас с нашей IceWM - конечно всё хорошо. Я и не спорю

[t.t]

я с вами согласен. и дебиановцы согласны. А вот Линус - не согласен

У меня IceWM, но уж это-то здесь при чём?

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

Вообще, всё это теоретизирование. Теоретически такая ситуация возникнуть может. Практически её вероятность пренебрежимо мала.

в убунте с гномом/юнити - постоянно. У нас с нашей IceWM - конечно всё хорошо. Я и не спорю

Тут дело не в гноме, а в убунте. В Debian у меня нередко стояли довольно большие куски гнома, но проблем это не вызывало. Убунта вообще подразумевает, что стоять будет то, что ставится по умолчанию. Если даже вылезать из main (в котором всего около 3 тыс. пакетов), всё уже не очень хорошо. А если смешивать разные ветки, то и вовсе плохо.

[sash-kan]

Тут дело не в гноме, а в убунте. В Debian у меня нередко стояли довольно большие куски гнома, но проблем это не вызывало. Убунта вообще подразумевает, что стоять будет то, что ставится по умолчанию. Если даже вылезать из main (в котором всего около 3 тыс. пакетов), всё уже не очень хорошо. А если смешивать разные ветки, то и вовсе плохо.

а почему так происходит, по-твоему?
в ubuntu не используют lintian? или плюют на его выводы?

[taaroa]

Тут дело не в гноме

...а в связке glibc/gcc.
да, использую gnome.
нет, тулкитофобией не страдаю.
да, установил firefox 4 параллельно с icecat 4.

[drBatty]

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

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

в ubuntu не используют lintian? или плюют на его выводы?

1) что такое lintian?
2) ИМХО бубунта == коммерческий продукт, там есть сроки, планы, и т.д. разрабы просто не в состоянии учесть все зависимости. А в Debian пока не допилят - будет testing. Не?

[taaroa]

1) что такое lintian?

Lintian dissects Debian packages and tries to find bugs and policy violations. It contains automated checks for many aspects of Debian policy as well as some checks for common errors.
http://lintian.debian.org/

[t.t]

Тут дело не в гноме, а в убунте. В Debian у меня нередко стояли довольно большие куски гнома, но проблем это не вызывало. Убунта вообще подразумевает, что стоять будет то, что ставится по умолчанию. Если даже вылезать из main (в котором всего около 3 тыс. пакетов), всё уже не очень хорошо. А если смешивать разные ветки, то и вовсе плохо.

а почему так происходит, по-твоему?
в ubuntu не используют lintian? или плюют на его выводы?

Не анализировал. Лишь сделал для себя вывод, что в убунте столь же вольно обращаться с установкой пакетов невозможно. Начиная с того, что за пределами их куцего main запросто можно напороться на криво собранный пакет, который и сам по себе не может ни нормально установиться, ни нормально снестись. И продолжая косяками с зависимостями. А заканчивая, пожалуй, кривоватостью самого aptitude или даже libapt.

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

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

Чем измеряется "слишком"? Не субъективный ли критерий? Мне достаточно того, что новая версия программы как правило появляется в unstable/experimental в течении нескольких дней, а в testing -- одной-двух недель.

в ubuntu не используют lintian? или плюют на его выводы?

Не анализировал.

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