Вопрос по сборке пакетов из исходников, разница в версиях библиотек и etc.

[CoolAller]

Хотел спросить, есть новые версии некоторых программ, которых нет в репозитории, но есть исходники на сайте разработчиков этих программ, где в явном виде не указывается для какой версии дистрибутива они предназначались. Начинаешь собирать и выясняется, что либо нужны более свежие пакеты, нежели те которые есть в репозитории, либо некоторые пакеты вообще отсутствуют в репозитории. Что в таком случае делать? Например, нужен vlc новой версии 3.0.1, в Debian 8 в репах только версия 2.2.7. Значит ли это, что только менять дистрибутив OS каждый раз когда понадобится какой-то софт или можно как-то решить проблему с новыми версиями и зависимостями? Почему нет таких проблем в проприетарных OS? Какова принципиальная разница и почему нельзя сделать так же? Нет какого-то единого фреймворка или чего-то еще не хватает? Если, например, нужны какие-то свежие либы, то почему просто не включать их в пакет с программой?

[ferum]

Ваш вопрос на половину риторический. Большинство из нас грешны тем что в большей или меньшей степени используем проприаретарное ПО. Браузеры yandex, opera, coogle-chromeа ещё skipe, teamviewer, crossover, wsp office и многое другое что то поставляется в deb пакетах что то в бинарном виде. Существуют варианты установки в /opt /usr/local а некоторый софт запускается из домашней папки пользователя. Заметим весь упомянутый софт способен работать на достаточно широком круге операционных систем как свежих так и не очень, тем не менее всегда существуют рамки по поддержке. Помним так же о бэкпортах, собирается достаточное количествосвежего софта для стабильных релизов но далеко не всё. С бухты барахты сказать  с уверенностью про vlc нельзя, скорее всего сделать так просто бэкпорт не удастся так как программа совсем не простая а вот сделать локальную сборку для помещения в /opt скорее всего можно если использовать виртуальную машину и пакеты из debian snapshot , разумеется надо учитывать нюансы в стартовых скриптах и правильно ссылаться на необходимые библиотеки, которые придётся изолированно подкладывать в папку с программой... в общем много надо чего знать.

[ecc83]

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

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

Значит ли это, что только менять дистрибутив OS каждый раз когда понадобится какой-то софт или можно как-то решить проблему с новыми версиями и зависимостями?

Выше я описал как нужно поступать. А менять ОS всё время не нужно, нужно сразу выбирать ту, которая соответствует твоим "хотелкам".

Почему нет таких проблем в проприетарных OS? Какова принципиальная разница и почему нельзя сделать так же?

Отчасти тоже есть, но меньше. А ты не задумывался почему такие огромные размеры "проприетарных OS"?

Если, например, нужны какие-то свежие либы, то почему просто не включать их в пакет с программой?

То есть к примеру у тебя есть пять разных приложений, которые используют одинаковую либу.
При запуске сразу этих приложений в памяти компьютера появляются пять копий одной и той же либы. Ты про это?

Тогда у меня вопрос, почему ты слез с проприетарной OS, которая построена по желаемому тобой принципу?

[ferum]

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

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

[ecc83]

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

Ну а какой выход, когда нужного приложения просто нет? Я как то четыре подхода делал, пока под CentOS собрал одну программу.
Причём сначала это казалось невозможно, а когда собралось, оказалось легко

[CoolAller]

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

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

OS, которая построена по желаемому тобой принципу?

Нет такой в природе.

А менять ОS всё время не нужно, нужно сразу выбирать ту, которая соответствует твоим "хотелкам".

Это в принципе невозможно, в основном из-за качества поддержки и других объективных причин.

огромные размеры "проприетарных OS"?

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

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

Абсолютно верно, собирал какую-то мелочь, время ушло вагон, в следующий раз когда понадобилось, плюнул и запустил программу на оффтопе, потратив 5 минут, ибо не вариант.

сделать локальную сборку для помещения в /opt скорее всего можно если использовать виртуальную машину и пакеты из debian snapshot

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

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

[I-Jurij]

1.

нужен vlc новой версии 3.0.1

Чего нет в более старой версии, не считая исправления всяких там багов?
Это к тому, что может вовсе не стоит заморачиваться?

По опыту сборки mplayer, mpv могу сказать, что требуется обновить (т.е. собрать новые версии) довольно много разных пакетов, начиная с ffmpeg, заканчивая фонтконфигами, фритайпами и т.д., кое-что обязательно, кое-что можно и пропустить. Для vlc сверху сто проц. добавится куча qt либ и их зависимостей.
То есть в итоге, чтобы обновить vlc правильно (пакетом), по хорошему нужно чуть ли не четверть системы пересобрать.
Чуть проще: сделать так, как выше писали и ругали (в отдельную папку). Но появляются дубли библиотек. Больше размер.
И совсем уж newway, от которого одни в восторге, другие - в унынии от подобности нелюбимой прориетарной оси: appimage и им подобные. Готовые спецзапакованные архивы программ с критическими зависимостями.

2.

Значит ли это, что только менять дистрибутив OS каждый раз когда понадобится какой-то софт

Обычно необходимое ПО (и ОСь в том числе) определяется на этапе планирования. После чего это все ставится. И обновляется только по мере необходимости.
Если вам изначально нужна была новейшая версия vlc или еще чего - вы точно с дистрибутивом не угадали.

[CoolAller]

Чего нет в более старой версии, не считая исправления всяких там багов?

Есть поблемы с воспроизведением некоторых типов файлов, которые новая версия вопроизводит. Да и дело тут не только в VLC.

вы точно с дистрибутивом не угадали.

А с ним нельзя "угадать", так как в том дистрибутиве где есть то, что требуется другие глюки, только еще более серьезные.

Дело не в версии OS, а в том, что ИМХО подход в корне неправильный с привязанностью к пакетной базе OS. Я еще могу понять, что ладно там на какую-то глобально новую технологию перешли, как например, HTML5 вытеснил Flash или поменялась архитектура и какие-то программы перестали работать, хотя и этого повально не произошло, так как учли обратную совместимость.

[I-Jurij]

1. почему в оффтопе и в линуксе такая большая разница с юзабилити и
2. почему до сих пор не могут уйти от привязки к пакетам и их версиям, которые должны быть в дистрибутиве.
3. Как с этим тогда обстоит дело в Mac OS, там же не нужно компилить из исходников каждый раз при смене версии самой OS?

1. Потому что в линуксе каждый для себя создает юзабилити. В одиночку, как некто Патрег, сообществом, как большинство дистрибутивов, или промышленно-капиталистическим способом, как известные серверные оси.
2. Многим нравится привязка к пакетам, а версии можно обновить. Новые веяния, принесенные, как мне кажется более молодыми программистами и сборщиками: всякие аппимейджи, контейнеры и прочее уже есть (или скоро появится) в репах практически каждого большого дистра.
3. Думаю, так же, как и в linux, в котором тоже не нужно собирать каждый раз из исходников без необходимости (хотя некоторым нравится).

[CoolAller]

I-Jurij,
1. Это не ответ, это констатация факта.
2. Очень спорно, так как не зря есть такое выражение Dependency hell, которое не просто фигура речи
3. Вообще не согласен, не нужно там этого делать, так как сам юзал Mac, правда не очень долго, но я просто скачивал новую версию программы и устанавливал без необходимости компиляции с новыми версиями библиотек.

PS. Вопрос не в том, что "лучше", а что "хуже", вопрос в том почему так и есть ли какие-то объективные причины объясняющие это явление.

[I-Jurij]

1. Есть поблемы с воспроизведением некоторых типов файлов, которые новая версия вопроизводит. Да и дело тут не только в VLC.
2. А с ним нельзя "угадать", так как в том дистрибутиве где есть то, что требуется другие глюки, только еще более серьезные.
3. Дело не в версии OS, а в том, что ИМХО подход в корне неправильный с привязанностью к пакетной базе OS. ...

1. vlc сам не воспроизводит, это делает ffmpeg. Можно упростить задачу сборкой (обновлением) ffmpeg. Не знаю, актуально ли в stretch, до jessie в таких случаях меня всегда выручал репо debian-multimedia, там с другими флагами сборка проводилась.
2. Подход что ни на есть правильнейший, п.что единственный. Пакетная база - это и есть то, что выше вы называли фреймворком. Просто одни используют обкатанные временем для надежности, другим подавай поновее для эспериментов и движения вперед.
Я уже писал о новых подходах, среди них есть один с "фреймворком" в виде базовой убунту и довесками в виде программ, которые запустятся при наличии "фреймворка" в любой системе.
Все, уходящее от пакетной базы, пока что приводит к прожорливости и увеличению, хотя и безопасность вроде как лучше (лично не вникал).

[CoolAller]

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

Если бы не знал как обстоит дело на самом деле, то возможно бы согласился)

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

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

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

[I-Jurij]

почему так и есть ли какие-то объективные причины объясняющие это явление

Если найдете человека, который сможет ответить на эти вопросы - познакомьте меня с ним

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

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

[qupl]

Собственно по ссылке, которую я привел выше я понял как решается проблема совместимости в Mac OS и Windows, но мне так и не понятно почему нельзя сделать так же в Linux.

Зачем из линукс делать окна? (вопрос риторический)

[CoolAller]

I-Jurij, опять вы о другом) Я не говорю о субъективном удобстве, я говорю о объективной стороне вопроса, такой как экономия времени на таких вещах, которые просто обязаны быть простыми и не требовать от пользователя большого количества времени и телодвижений - обновление версий программ, где большее время должно уделяться разработчиком для правильной компоновки приложения для его успешного запуска и использования, а при наличии удобных инструментов и вовсе не отличаться по трудозатратам.
Cообщение объединено 05 марта 2018, 20:40:49

Зачем из линукс делать окна? (вопрос риторический)

Нифига не риторический, Mac OS это же не окна)

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