История изменений

Ага и постоянные проблемы в работе программ.

Только ты ему не продложил обновиться нормально целиком до тестового релиза (Debian tetsing), bookworm, или нестабильного релиза (Debian unstable), sid.

А предлагаешь смешивать ветки.

Понимаешь в чём суть, вся экосистема Linux построена по принципу, что программа компилируется под конкретные версии библиотек.

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

Программа собранная с под конкретную версию glibc, gtk, qt, libpng, zlib, openssl и прочее слинкована именно с этой версией библиотеки.

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

Как следствие остальные програмы в системе, которые собирались под версии библиотек из стабильного релиза будут запускаться и работать с версиями бибоиотек релиза под который они не собирались. И с большой долей вероятности они будут работать и запускаться. Но может возникнуть ситуация, что программа не будет корректно работать с новой версией библиотеки и будет падать. Или может возникнуть ситуация, что программа или библиотека из стабильного релиза слинкована с версией допустим с libpng-14.so, которая есть в стабильном релизе прсто не запуститься с более новой версией библиотеки из тестового релиза.

А у тебя из тестового или нестабильного релиза подтянется libpng-15. Версии беру условно. И всё, программа не запустится.

Можно конечно сделать символьную ссылку libpng-14 -> libpng-15 и надеяться, что по API / ABI эти библиотеки совместимы. Но это может оказаться не так.

И всё, ты сломал систему.

Не зря в Ubuntu есть snap пакеты, в которые помещаются программы и их зависимости, приложение в snap пакете как в «бутылке» запускается в окружении, под которое собиралось.

В служебной информации пакета может быть написано, что для его работы требуется >=libpng-14, но тебе никто из разработчиков deb пакета не даст гарантии, что приложение собранное под libpng-14 будет запускаться и работать с libpng-15.

И при смешивании релизов если ты ставишь пакет из тестового релиза, которому требуется libpng-15 в систему будет поставлен пакет с этой версией libpng. И libpng-14 спокойно обновится до libpng-15.

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

Т.к. разработчик (мантейнер) пакета тестирует свой пакет в рамках версии пакетов определённого релиза. Он не может гарантировать, что пакет будет работать с пакетом другой версии от другого релиза. Но в зависимостях может проставить вместо = условие >=libpng-14.10 для того, чтобы когда в стабильном релизе обновится пакет libpng-14.10 до libpng-14.11 он смог поставиться.

А может указать версию libpng-14 просто, без указания субверсии.

И всё, ты получил блокировку по зависимостям, что части пакетов требуется libpng-14, а части, из тестовой ветки, уже libpng-15.

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

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

Это тебе не Windows, где в какой-то степени немного проще и программа вообще ставится в c:\program files или в отдельную другугю директорию и не может повлиять на работу прочих программж. Хотя в случае зависимостей системных библиотек .Net Framework и прочего тоже могут быть нюансы.

В мире Linux либо собираешь новую программу под конкретное окружение софта, библиотек, релиза. Либо переходишь на новые релиз и возможно пересобираешь программы под эти библиотеки.

Повторяю не нужно давать вредные советы.

На своём ПК и в своей системе ты можешь делать всё, что хочешь, а советовать что-либо другим не надо.

Если тебе так хочется ему посоветовать rolling-релиз дистрибутив - советуй Arch или Gentoo.

Ага и постоянные проблемы в работе программ.

Только ты ему не продложил обновиться нормально целиком до тестового релиза (Debian tetsing), bookworm, или нестабильного релиза (Debian unstable), sid.

А предлагаешь смешивать ветки.

Понимаешь в чём суть, вся экосистема Linux построена по принципу, что программа компилируется под конкретные версии библиотек.

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

Программа собранная с под конкретную версию glibc, gtk, qt, libpng, zlib, openssl и прочее слинкована именно с этой версией библиотеки.

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

Как следствие остальные програмы в системе, которые собирались под версии библиотек из стабильного релиза будут запускаться и работать с версиями бибоиотек релиза под который они не собирались. И с большой долей вероятности они будут работать и запускаться. Но может возникнуть ситуация, что программа не будет корректно работать с новой версией библиотеки и будет падать. Или может возникнуть ситуация, что программа или библиотека из стабильного релиза слинкована с версией допустим с libpng-14.so, которая есть в стабильном релизе прсто не запуститься с более новой версией библиотеки из тестового релиза.

А у тебя из тестового или нестабильного релиза подтянется libpng-15. Версии беру условно. И всё, программа не запустится.

Можно конечно сделать символьную ссылку libpng-14 -> libpng-15 и надеяться, что по API / ABI эти библиотеки совместимы. Но это может оказаться не так.

И всё, ты сломал систему.

Не зря в Ubuntu есть snap пакеты, в которые помещаются программы и их зависимости, приложение в snap пакете как в «бутылке» запускается в окружении, под которое собиралось.

В служебной информации пакета может быть написано, что для его работы требуется >=libpng-14, но тебе никто из разработчиков deb пакета не даст гарантии, что приложение собранное под libpng-14 будет запускаться и работать с libpng-15.

И при смешивании релизов если ты ставишь пакет из тестового релиза, которому требуется libpng-15 в систему будет поставлен пакет с этой версией libpng. И libpng-14 спокойно обновится до libpng-15.

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

Т.к. разработчик (мантейнер) пакета тестирует свой пакет в рамках версии пакетов определённого релиза. Он не может гарантировать, что пакет будет работать с пакетом другой версии от другого релиза. Но в зависимостх может проставить вместо = условие >=libpng-14.10 для того, чтобы когда в стабильном релизе обновится пакет libpng-14.10 до libpng-14.11 он смог поставиться.

А может указать версию libpng-14 просто, без указания субверсии.

И всё, ты получил блокировку по зависимостям, что части пакетов требуется libpng-14, а части, из тестовой ветки, уже libpng-15.

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

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

Это тебе не Windows, где в какой-то степени немного проще и программа вообще ставится в c:\program files или в отдельную другугю директорию и не может повлиять на работу прочих программж. Хотя в случае зависимостей системных библиотек .Net Framework и прочего тоже могут быть нюансы.

В мире Linux либо собираешь новую программу под конкретное окружение софта, библиотек, релиза. Либо переходишь на новые релиз и возможно пересобираешь программы под эти библиотеки.

Повторяю не нужно давать вредные советы.

На своём ПК и в своей системе ты можешь делать всё, что хочешь, а советовать что-либо другим не надо.

Если тебе так хочется ему посоветовать rolling-релиз дистрибутив - советуй Arch или Gentoo.

Ага и постоянные проблемы в работе программ.

Только ты ему не продложил обновиться нормально целиком до тестового релиза (Debian tetsing), bookworm, или нестабильного релиза (Debian unstable), sid.

А предлагаешь смешивать ветки.

Понимаешь в чём суть, вся экосистема Linux построена по принципу, что программа компилируется под конкретные версии библиотек.

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

Программа собранная с под конкретную версию glibc, gtk, qt, libpng, zlib, openssl и прочее слинкована именно с этой версией библиотеки.

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

Как следствие остальные програмы в системе, которые собирались под версии библиотек из стабильного релиза будут запускаться и работать с версиями бибоиотек релиза под который они не собирались. И с большой долей вероятности они будут работать и запускаться. Но может возникнуть ситуация, что программа не будет корректно работать с новой версией библиотеки и будет падать. Или может возникнуть ситуация, что программа или библиотека из стабильного релиза слинкована с версией допустим с libpng-14.so, которая есть в стабильном релизе прсто не запуститься с более новой версией библиотеки из тестового релиза.

А у тебя из тестового или нестабильного релиза подтянется libpng-15. Версии беру условно. И всё, программа не запустится.

Можно конечно сделать символьную ссылку libpng-14 -> libpng-15 и надеяться, что по API / ABI эти библиотеки совместимы. Но это может оказаться не так.

И всё, ты сломал систему.

Не зря в Ubuntu есть snap пакеты, в которые помещаются программы и их зависимости, приложение в snap пакете как в «бутылке» запускается в окружении, под которое собиралось.

В служебной информации пакета может быть написано, что для его работы требуется >=libpng-14, но тебе никто из разработчиков deb пакета не даст гарантии, что приложение собранное под libpng-14 будет запускаться и работать с libpng-15.

И при смешивании релизов если ты ставишь пакет из тестового релиза, которому требуется libpng-15 в систему будет поставлен пакет с этой версией libpng. И libpng-14 спокойно обновиться до kubpng-15.

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

Т.к. разработчик (мантейнер) пакета тестирует свой пакет в рамках версии пакетов определённого релиза. Он не может гарантировать, что пакет будет работать с пакетом другой версии от другого релиза. Но в зависимостх может проставить вместо = условие >=libpng-14.10 для того, чтобы когда в стабильном релизе обновится пакет libpng-14.10 до libpng-14.11 он смог поставиться.

А может указать версию libpng-14 просто, без указания субверсии.

И всё, ты получил блокировку по зависимостям, что части пакетов требуется libpng-14, а части, из тестовой ветки, уже libpng-15.

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

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

Это тебе не Windows, где в какой-то степени немного проще и программа вообще ставится в c:\program files или в отдельную другугю директорию и не может повлиять на работу прочих программж. Хотя в случае зависимостей системных библиотек .Net Framework и прочего тоже могут быть нюансы.

В мире Linux либо собираешь новую программу под конкретное окружение софта, библиотек, релиза. Либо переходишь на новые релиз и возможно пересобираешь программы под эти библиотеки.

Повторяю не нужно давать вредные советы.

На своём ПК и в своей системе ты можешь делать всё, что хочешь, а советовать что-либо другим не надо.

Если тебе так хочется ему посоветовать rolling-релиз дистрибутив - советуй Arch или Gentoo.

Ага и постоянные проблемы в работе программ.

Только ты ему не продложил обновиться нормально целиком до тестового релиза (Debian tetsing), bookworm, или нестабильного релиза (Debian unstable), sid.

А предлагаешь смешивать ветки.

Понимаешь в чём суть, вся экосистема Linux построена по принципу, что программа компилируется под конкретные версии библиотек.

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

Программа собранная с под конкретную версию glibc, gtk, qt, libpng, zlib, openssl и прочее слинкована именно с этой версией библиотеки.

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

Как следствие остальные програмы в системе, которые собирались под версии библиотек из стабильного релиза будут запускаться и работать с версиями бибоиотек релиза под который они не собирались. И с большой долей вероятности они будут работать и запускаться. Но может возникнуть ситуация, что программа не будет корректно работать с новой версией библиотеки и будет падать. Или может возникнуть ситуация, что программа или библиотека из стабильного релиза слинкована с версией допустим с libpng-14.so, которая есть в стабильном релизе.