Переезд на Arch

Aivar	# 5 лет, 12 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	AlexMak А вот ещё ламерский вопрос: обновляется обычно что? Всё.

red	# 5 лет, 12 месяцев назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	AlexMak А вот ещё ламерский вопрос: обновляется обычно что? Ядро с модулями и прочим служебным "обвесом", или только проги, которые сам наустанавливал? Подразумеваю, что можно и то, и другое, но по дефолту обновление чего происходит? в арче идет обновление пакетов и как такового разделения нету, здесь ядро это такой же пакет как, например, и git Хотя здесь предусмотрена возможность запретить обновление выбранным пакетам если их прописать в pacman.conf в соответствующих переменных, но это используется редко и в основном когда новая версия пакета оказалась глючной, так что после отката версии на старую её временно замораживают пока не починят.

red

# 5 лет, 12 месяцев назад

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

AlexMak
А вот ещё ламерский вопрос: обновляется обычно что? Ядро с модулями и прочим служебным "обвесом", или только проги, которые сам наустанавливал? Подразумеваю, что можно и то, и другое, но по дефолту обновление чего происходит?

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

akorop	# 5 лет, 12 месяцев назад
Темы: 111 Сообщения: 1756 Участник с: 29 февраля 2012	red апретить обновление выбранным пакетам если их прописать в pacman.conf в соответствующих переменных, но это используется редко и в основном когда новая версия пакета оказалась глючной, Или если этот пакет собираешь сам с какими-то отличиями от официального.

akorop

# 5 лет, 12 месяцев назад

Темы: 111

Сообщения: 1756

Участник с: 29 февраля 2012

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

Или если этот пакет собираешь сам с какими-то отличиями от официального.

vasek	# 5 лет, 12 месяцев назад (отредактировано 5 лет, 12 месяцев назад)
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	Запретить обновление пакета можно, но нужно быть готовым, что рано или поздно наступят проблемы. Все пакеты используют shared library (общие, совместно используемые библиотеки) и рано ли поздно ли произойдет изменение (в основном меняется soname) какой то используемой библиотеки и нужно быть готовым к решению проблемы и уметь это делать. Пример - у меня уже около года заморожен firefox (я не перешел на новую версию quantum) pacman -Q firefox firefox 56.0.2-1 а сейчас уже где-то 63 версия. Год все шло нормально, никаких проблем. Но не давно обновился пакет, который находится в зависимостях у firefox, а вместе с этим изменилась и версия одной общей библиотеки - firefox перестал запускаться. Пришлось лечить. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 12 месяцев назад (отредактировано 5 лет, 12 месяцев назад)

Темы: 47

Сообщения: 11853

Участник с: 17 февраля 2013

Запретить обновление пакета можно, но нужно быть готовым, что рано или поздно наступят проблемы.
Все пакеты используют shared library (общие, совместно используемые библиотеки) и рано ли поздно ли произойдет изменение (в основном меняется soname) какой то используемой библиотеки и нужно быть готовым к решению проблемы и уметь это делать.
Пример - у меня уже около года заморожен firefox (я не перешел на новую версию quantum)
pacman -Q firefox
firefox 56.0.2-1
а сейчас уже где-то 63 версия.
Год все шло нормально, никаких проблем. Но не давно обновился пакет, который находится в зависимостях у firefox, а вместе с этим изменилась и версия одной общей библиотеки - firefox перестал запускаться. Пришлось лечить.

Ошибки не исчезают с опытом - они просто умнеют

akorop	# 5 лет, 12 месяцев назад
Темы: 111 Сообщения: 1756 Участник с: 29 февраля 2012	vasek вместе с этим изменилась и версия одной общей библиотеки - firefox перестал запускаться. Пришлось лечить А как такое лечится?

vasek	# 5 лет, 12 месяцев назад (отредактировано 4 года, 10 месяцев назад)
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	akorop А как такое лечится? Однозначного решения нет, но в основном принцип один - ищется проблемная библиотека, анализируется причина появления проблемы и принимается решение о замене проблемной библиотеки. Опишу подробнее на своем примере проблемы с firefox При запуске в терминале видим следующий вывод ---> firefox `XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so: libhunspell-1.6.so.0: cannot open shared object file: No such file or directory Couldn't load XPCOM.` 1. Проверим действительно ли отсутствует библиотека libhunspell-1.6.so.0 ---> *find /usr/lib -name 'libhunspell' `/usr/lib/libhunspell-1.7.so.0.0.1 /usr/lib/libhunspell-1.7.so /usr/lib/libhunspell-1.7.so.0 /usr/lib/libhunspell.so` Действительно такой библиотеки нет, но есть libhunspell-1.7.so.0 - найдем какому пакету она принадлежит pacman -Qo /usr/lib/libhunspell-1.7.so.0 `/usr/lib/libhunspell-1.7.so.0 принадлежит hunspell 1.7.0-1` Напрашивается вывод, что firefox зависит от пакета hunspell, который вероятно был недавно обновлен. Проверим это ---> pacman -Qi firefox `Зависит от : ... hunspell...` grep hunspell /var/log/pacman.log `[2018-11-22 14:56] [ALPM] upgraded hunspell (1.6.2-1 -> 1.7.0-1)` Так оно и оказалось, firefox зависит от hunspell, который обновился. А если посмотреть какие библиотеки входят в этот пакет, то увидим ---> pacman -Ql hunspell \| grep lib `hunspell /usr/lib/libhunspell-1.7.so hunspell /usr/lib/libhunspell-1.7.so.0 hunspell /usr/lib/libhunspell-1.7.so.0.0.1 hunspell /usr/lib/libhunspell.so` Вроде бы все прояснилось - была библиотека libhunspell-1.6.so.0, но после обновления пакета hunspell, данная библиотека заменилась на libhunspell-1.7.so.0 2. Уточним это, проанализируем более подробнее Вернемся к первоначальному сообщению ошибки `XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so: libhunspell-1.6.so.0: cannot open shared object file: No such file or directory Couldn't load XPCOM.` Из которого видим интересный файл /usr/lib/firefox/libxul.so (запомним его). В принципе, можно было бы сразу посмотреть какие soname нужны firefox. UPD - в разделяемой библиотеке формата ELF присутствует так называемое SONAME - это строка символов, которая прописывается в двоичный файл в секцию DT_SONAME. Грубо говоря, это указание на версию для загрузки общей библиотеки. Посмотреть которые можно, например, так: readelf -d /путь/к/бинарнику \| grep NEEDED или objdump -x /путь/к/бинарнику \| grep NEEDED или ldd /путь/к/бинарнику UPD - обычно ldd не рекомендуют (бинарник запускается, а там может быть вирус), но мы не параноики .., тем более firefox всеравно запускаем. И так пробуем, например, ldd ---> ldd /usr/bin/firefox `не является динамическим исполняемым файлом` Это не бинарник, уточним ---> file /usr/bin/firefox `/usr/bin/firefox: POSIX shell script, ASCII text executable` Это обычный shell script - посмотрим содержимое файла ---> cat /usr/bin/firefox `#!/bin/sh exec /usr/lib/firefox/firefox "$@"` Посмотрим содержимое этой директории /usr/lib/firefox/ ---> ls /usr/lib/firefox `... libxul.so ...` И видим ранее упомянутый файл libxul.so** ... еще писал, запомним его А вот сейчас проверим эти soname на основе этого бинарника libxul.so всеми способами (для понимания) ---> readelf -d /usr/lib/firefox/libxul.so \| grep NEEDED \| grep libhunspell `0x0000000000000001 (NEEDED) Совм. исп. библиотека: [libhunspell-1.6.so.0]` ---> objdump -x /usr/lib/firefox/libxul.so \| grep NEEDED \| grep libhunspell `NEEDED libhunspell-1.6.so.0` ---> ldd /usr/lib/firefox/libxul.so \| grep libhunspell `libhunspell-1.6.so.0 => not found` И еще, для понимания soname, посмотрим эту запись в бинарнике (смещение вычислил заранее) ---> hexdump -C -s 226572 -n 20 /usr/lib/firefox/libxul.so `0003750c 6c 69 62 68 75 6e 73 70 65 6c 6c 2d 31 2e 36 2e \|libhunspell-1.6.\| 0003751c 73 6f 2e 30 \|so.0\|` 3. И вот сразу приходит на ум один из способов решения проблемы - в файле /usr/lib/firefox/libxul.so изменить один байт, точнее, вместо libhunspell-1.6.so.0 прописать libhunspell-1.7.so.0 Но многим этот способ не нравится, а значит сделаем простой симлинк ---> sudo ln -s /usr/lib/libhunspell-1.7.so.0.0.1 /usr/lib/libhunspell-1.6.so.0 UPD - почему сразу на libhunspell-1.7.so.0.0.1, а не на libhunspell-1.7.so.0??? - а потому что этот файл сам является симлинком ls -l /usr/lib/libhunspell-1.7.so.0 `lrwxrwxrwx 1 root root 24 ноя 17 15:32 /usr/lib/libhunspell-1.7.so.0 -> libhunspell-1.7.so.0.0.1` Проверяем ---> ls -l /usr/lib/libhunspell-1.6.so.0 `lrwxrwxrwx 1 root root ... /usr/lib/libhunspell-1.6.so.0 -> /usr/lib/libhunspell-1.7.so.0.0.1` Запускаем firefox - проблема ушла. Но может быть и так, что это не сработает (в случае слишком серъезных изменений, что мало вероятно), тогда самое простое найти и скачать данную старую библиотеку (можно взять из старого пакета hunspell). akorop, прошу не судить за подробное изложение - тебе это все знакомо, но подробно расписал для других, для лучшего понимания. EDIT 1 - добавление из другого топика - пусть все будет в одном месте ... Немного о номерах версий динамических библиотек и их влиянии на совместимость. Действует следующая схема нумерации библиотек - lib.so.x.y.z x – мажорный выпуск - мажорная версия библиотеки изменяется всякий раз, когда у неё меняется ABI и, как правило, совместимость при этом изменении не обеспечивается. y – минорный выпуск - минорная версия библиотеки изменяется при добавлении в библиотеку новой функциональности без изменения ABI и, как правило, совместимость при изменении обеспечивается (новые функции и типы данных добавляются, но старые при этом должны сохраняться). z – багофикс - багофикс изменяется при устранени ошибок (без добавления новой функциональности) и естественно на совместимость не влияет. Разработчики библиотеки стараются поддерживать ABI стабильным - изменение затратно. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 12 месяцев назад (отредактировано 4 года, 10 месяцев назад)

Темы: 47

Сообщения: 11853

Участник с: 17 февраля 2013

akorop
А как такое лечится?

Однозначного решения нет, но в основном принцип один - ищется проблемная библиотека, анализируется причина появления проблемы и принимается решение о замене проблемной библиотеки.
Опишу подробнее на своем примере проблемы с firefox
При запуске в терминале видим следующий вывод
---> firefox

XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so:
libhunspell-1.6.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

1. Проверим действительно ли отсутствует библиотека libhunspell-1.6.so.0
---> find /usr/lib -name 'libhunspell*'

/usr/lib/libhunspell-1.7.so.0.0.1
/usr/lib/libhunspell-1.7.so
/usr/lib/libhunspell-1.7.so.0
/usr/lib/libhunspell.so

Действительно такой библиотеки нет, но есть libhunspell-1.7.so.0 - найдем какому пакету она принадлежит
pacman -Qo /usr/lib/libhunspell-1.7.so.0

/usr/lib/libhunspell-1.7.so.0 принадлежит hunspell 1.7.0-1

Напрашивается вывод, что firefox зависит от пакета hunspell, который вероятно был недавно обновлен. Проверим это
---> pacman -Qi firefox

Зависит от           : ... hunspell...

grep hunspell /var/log/pacman.log

[2018-11-22 14:56] [ALPM] upgraded hunspell (1.6.2-1 -> 1.7.0-1)

Так оно и оказалось, firefox зависит от hunspell, который обновился.
А если посмотреть какие библиотеки входят в этот пакет, то увидим
---> pacman -Ql hunspell | grep lib

hunspell /usr/lib/libhunspell-1.7.so
hunspell /usr/lib/libhunspell-1.7.so.0
hunspell /usr/lib/libhunspell-1.7.so.0.0.1
hunspell /usr/lib/libhunspell.so

Вроде бы все прояснилось - была библиотека libhunspell-1.6.so.0, но после обновления пакета hunspell, данная библиотека заменилась на libhunspell-1.7.so.0

2. Уточним это, проанализируем более подробнее
Вернемся к первоначальному сообщению ошибки

XPCOMGlueLoad error for file /usr/lib/firefox/libxul.so:
libhunspell-1.6.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Из которого видим интересный файл /usr/lib/firefox/libxul.so (запомним его).
В принципе, можно было бы сразу посмотреть какие soname нужны firefox.
UPD - в разделяемой библиотеке формата ELF присутствует так называемое SONAME - это строка символов, которая прописывается в двоичный файл в секцию DT_SONAME. Грубо говоря, это указание на версию для загрузки общей библиотеки. Посмотреть которые можно, например, так:
readelf -d /путь/к/бинарнику | grep NEEDED
или
objdump -x /путь/к/бинарнику | grep NEEDED
или
ldd /путь/к/бинарнику
UPD - обычно ldd не рекомендуют (бинарник запускается, а там может быть вирус), но мы не параноики .., тем более firefox всеравно запускаем.
И так пробуем, например, ldd
---> ldd /usr/bin/firefox

не является динамическим исполняемым файлом

Это не бинарник, уточним
---> file /usr/bin/firefox

/usr/bin/firefox: POSIX shell script, ASCII text executable

Это обычный shell script - посмотрим содержимое файла
---> cat /usr/bin/firefox

#!/bin/sh
exec /usr/lib/firefox/firefox "$@"

Посмотрим содержимое этой директории /usr/lib/firefox/
---> ls /usr/lib/firefox

...
libxul.so
...

И видим ранее упомянутый файл libxul.so ... еще писал, запомним его
А вот сейчас проверим эти soname на основе этого бинарника libxul.so всеми способами (для понимания)
---> readelf -d /usr/lib/firefox/libxul.so | grep NEEDED | grep libhunspell

0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libhunspell-1.6.so.0]

---> objdump -x /usr/lib/firefox/libxul.so | grep NEEDED | grep libhunspell

NEEDED               libhunspell-1.6.so.0

---> ldd /usr/lib/firefox/libxul.so | grep libhunspell

	libhunspell-1.6.so.0 => not found

И еще, для понимания soname, посмотрим эту запись в бинарнике (смещение вычислил заранее)
---> hexdump -C -s 226572 -n 20 /usr/lib/firefox/libxul.so

0003750c  6c 69 62 68 75 6e 73 70  65 6c 6c 2d 31 2e 36 2e  |libhunspell-1.6.|
0003751c  73 6f 2e 30                                       |so.0|

3. И вот сразу приходит на ум один из способов решения проблемы - в файле /usr/lib/firefox/libxul.so изменить один байт, точнее, вместо libhunspell-1.6.so.0 прописать libhunspell-1.7.so.0
Но многим этот способ не нравится, а значит сделаем простой симлинк
---> sudo ln -s /usr/lib/libhunspell-1.7.so.0.0.1 /usr/lib/libhunspell-1.6.so.0
UPD - почему сразу на libhunspell-1.7.so.0.0.1, а не на libhunspell-1.7.so.0??? - а потому что этот файл сам является симлинком
ls -l /usr/lib/libhunspell-1.7.so.0

lrwxrwxrwx 1 root root 24 ноя 17 15:32 /usr/lib/libhunspell-1.7.so.0 -> libhunspell-1.7.so.0.0.1

Проверяем
---> ls -l /usr/lib/libhunspell-1.6.so.0

lrwxrwxrwx 1 root root ...  /usr/lib/libhunspell-1.6.so.0 -> /usr/lib/libhunspell-1.7.so.0.0.1

Запускаем firefox - проблема ушла.
Но может быть и так, что это не сработает (в случае слишком серъезных изменений, что мало вероятно), тогда самое простое найти и скачать данную старую библиотеку (можно взять из старого пакета hunspell).

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

EDIT 1 - добавление из другого топика - пусть все будет в одном месте ...
Немного о номерах версий динамических библиотек и их влиянии на совместимость.
Действует следующая схема нумерации библиотек - lib.so.x.y.z
x – мажорный выпуск - мажорная версия библиотеки изменяется всякий раз, когда у неё меняется ABI и, как правило, совместимость при этом изменении не обеспечивается.
y – минорный выпуск - минорная версия библиотеки изменяется при добавлении в библиотеку новой функциональности без изменения ABI и, как правило, совместимость при изменении обеспечивается (новые функции и типы данных добавляются, но старые при этом должны сохраняться).
z – багофикс - багофикс изменяется при устранени ошибок (без добавления новой функциональности) и естественно на совместимость не влияет.
Разработчики библиотеки стараются поддерживать ABI стабильным - изменение затратно.

Ошибки не исчезают с опытом - они просто умнеют

nafanja	# 5 лет, 12 месяцев назад (отредактировано 5 лет, 12 месяцев назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	vasek, а можно просто пересобрать пакет огнелиса, в большинстве случаев новая библиотека подхватится автоматом... Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

vasek	# 5 лет, 12 месяцев назад
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	nafanja а можно просто пересобрать пакет огнелиса, в большинстве случаев новая библиотека подхватится автоматом… Не всегда это возможно. У меня firefox заморожен именно из-за введения всяких новшеств, из-за которых я не могу открыть десятки тысяч документов формата mht. Пересборка выльется в разработку нового приложения. Намного проще изменить один байт или прописать симлинк - не больше 5 минут. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 12 месяцев назад

Темы: 47

Сообщения: 11853

Участник с: 17 февраля 2013

nafanja
а можно просто пересобрать пакет огнелиса, в большинстве случаев новая библиотека подхватится автоматом…

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

Ошибки не исчезают с опытом - они просто умнеют

nafanja	# 5 лет, 12 месяцев назад (отредактировано 5 лет, 12 месяцев назад)
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	vasek У меня firefox заморожен именно из-за введения всяких новшеств, нужно найти PKGBUILD с нужной версией, и пересобрать... новая библиотека может быть не совместима со старой, ну там функции изменятся например. а так при сборке сразу можно узнать проблему и исправить... вариант описанный тобой ограничен в возможностях. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 5 лет, 12 месяцев назад (отредактировано 5 лет, 12 месяцев назад)

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

vasek
У меня firefox заморожен именно из-за введения всяких новшеств,

нужно найти PKGBUILD с нужной версией, и пересобрать...

новая библиотека может быть не совместима со старой, ну там функции изменятся например.
а так при сборке сразу можно узнать проблему и исправить...

вариант описанный тобой ограничен в возможностях.

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

vasek	# 5 лет, 12 месяцев назад
Темы: 47 Сообщения: 11853 Участник с: 17 февраля 2013	nafanja нужно найти PKGBUILD с нужной версией, и пересобрать… Для меня проще сначала залезть в исходник и изменить 1 - 2 байта, а вот уж если это не сработает, тогда возможна и пересборка. Хотя, если честно, длительное замораживание пакета очень редкий случай - за все время это у меня 1-ый случай, замораживание на год. Но на всякий экстренный случай всегда должен быть запасной вариант - и он у меня имеется - для просмотра формата mht установлен vivaldi - если для firefox не разработают нужное расширение, придется переходить на vivaldi. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 12 месяцев назад

Темы: 47

Сообщения: 11853

Участник с: 17 февраля 2013

nafanja
нужно найти PKGBUILD с нужной версией, и пересобрать…

Для меня проще сначала залезть в исходник и изменить 1 - 2 байта, а вот уж если это не сработает, тогда возможна и пересборка.
Хотя, если честно, длительное замораживание пакета очень редкий случай - за все время это у меня 1-ый случай, замораживание на год.
Но на всякий экстренный случай всегда должен быть запасной вариант - и он у меня имеется - для просмотра формата mht установлен vivaldi - если для firefox не разработают нужное расширение, придется переходить на vivaldi.

Ошибки не исчезают с опытом - они просто умнеют