Ленивого консерватизма пост

Что то стало лень каждый год ставить слаку, апгрейдить тоже неохота, нвидиа, насколько можно понять, забила болт на 96 legacy. Соединение лени общей и лени искать патчи на драйвер нвидии родило непатрикоугодную и вообще бредовую мысль, а что если просто собрать glibc, glib2, gtk, python и qt из current (который сейчас фактически бета) и поставить все это хозяйство вместе с новым гимпом ( остальные проги решил не менять, кроме питоньих, которых естественно пришлось пересобрать) на 13.37 ? Лень была преодолена и так и было сделано. Возня была только с модулями питона (только сейчас понял какое зло этот гвидобейсик ) и еще кое что по мелочи.
Пятый день полет нормальный. Доктор, это будет жить или можно предусмотрительно заказывать ящичек с ленточками ? :-)

Будет.
Задумано, что в эту сторону оно должно двигаться без проблем. На практике возможны "овраги" в местах нарушения обратной совместимости свежих glibc, glib2, gtk и qt с несвежими, на которые рассчитывал ранее собранный софт.
По питону пусть подскажет кто-нибудь более компетентный.

Там свои камни, но в принципе маленькие, пришлось ставить несколько версий отдельных маленьких либ, но всего несколько штук, и еще пересобрать несколько где есть биндинги к питону. Плюс пара симлинков :-), но вообще то фыручит. Опасался только того, что обратная совместимость гарантирована для gtk, но с qt вообще то про нее никто не говорит, но обошлось.
Но вообще о это может прокатить когда смена версия незначительна для glibc, что будет если разрыв в версиях будет большой, непонятно, остается только сплюнуть.
В основном на это подвигло проблемы с драйвером нвидии, на ее форуме один из разработчиков на вопрос "будете ли вы и далее поддерживать 96 драйвер" высказался в духе "по возможности", в переводе на русский нетрудно догадаться что это значит. Марк может и будет делать патчи, но тоже как то сомнительно, нува для этих карт это слезы. Так что.. Новую карту все равно рано или поздно придется брать

Станет плохо в этом сценарии, когда для очередной версии glibc скажут, что выкинули А, Б, ..., а что-то из них использовалось в уже установленном. Но поскольку пакет общепризнанно фундаментальный и довольно консервативный, остаётся надеяться, что подобные события не слишком часты...

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

Это с чего вдруг "все пользовательские"? За минусом сделанной оговорки по выброшенную функциональность, собранное с предыдущей версией glibc, ... в силу обратной совместимости должно работать с новой.
Посмотрите в ChangeLog.txt, при смене glibc полная пересборка всех пакетов пользовательского окружения не производится.

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

bormant написал:

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

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