Следует ли удалять предыдущие версии при установке новой версии из исходного кода? Есть ли проблемы, связанные с тем, что вы этого не делаете?

Ответ TL;DR: «никогда не трогайте работающую систему», если все работает как положено, если только вы не знаете, что делаете, и не чувствуете себя предприимчивым :)Но использованиеapt remove <software>(или аналогичного )относительно безопасно, и конфликты версий или нарушенные зависимости по этому пути редки (для программного обеспечения, которое вы также установили через apt ).

Вручную, в качестве первого шага, вы можете проверить зависимости вашего программного обеспечения с помощью

ldd --verbose <program>

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

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

Конечно, вышесказанное верно только для общих файлов. Файлы и каталоги, которые установка поместила в ваш /home/, могут быть удалены с относительной уверенностью. Исключениями могут быть пакеты Gems, Shards или Python и т. д., но их можно относительно легко переустановить. Кроме того, если вы сгенерировали ключи доступа -или коды разблокировки, сначала сделайте резервную копию перед удалением.

Конечно, ответы на эту тему могут варьироваться от «Просто сделай это» до «Никогда не трогай это», и наверняка существует множество мнений по этой теме.

Надеюсь, это немного поможет.

Стандартной практикой в ​​Linux является установка нового программного обеспечения из исходников в /usr/localили /opt, что означает, что нет необходимости удалять уже установленное программное обеспечение.

При установке из исходного кода (с помощью sudo make install), вы отвечаете за выбор места установки.

Многие программные пакеты по умолчанию устанавливаются в папку /usr/local, если они установлены из исходного кода, но вам следует свериться с инструкциями по сборке исходного пакета и/или запускать «сухую» -установку запуска (часто make -n install, но обратитесь к инструкциям по сборке )после сборки программного обеспечения, но перед его реальной установкой.

При установке под /usr/localпрограммное обеспечение обычно не должно мешать упакованной версии, предоставляемой дистрибутивом, и поскольку переменная среды PATH для обычных пользователей обычно включает /usr/local/binперед /usr/binи /bin, локально собранная версия обычно имеет приоритет над упакованной версией.

Так что все должно быть хорошо сразу после установки. Но это может стать проблемой позже, когда дистрибутив будет обновлен и локальная -собранная установка будет старше, чем та, что упакована дистрибутивом. Если вы устанавливаете локально -собранное программное обеспечение с помощью sudo make install, исходный пакет может включать или не включать соответствующую sudo make uninstallпроцедуру -, и если вы удалили каталог сборки, автоматически -сгенерированный Makefile, который может содержать правильные шаги удаления, возможно, все равно исчезнет.

Таким образом, если вы используете sudo make install, вам следует записать вывод процедуры установки или, в противном случае, убедиться, что вы записали, какие файлы были добавлены на этапе установки, чтобы вы могли вручную удалить их позже. Планируйте заранее.(Если система, о которой идет речь, является сервером -для одного назначения, она может быть единственным программным обеспечением, созданным из исходного кода, поэтому все файлы в /usr/local/иерархии могут быть созданы этой установкой -, поэтому она может быть просто вопросом удаления всех файлов из каталогов в /usr/localпосле обновления основной версии.)

Если исходный пакет включает файл debian/rules, то исходный код уже включает конфигурацию, необходимую для создания фактического пакета Debian. В этом случае вы можете использовать dpkg-source -bвместо общих инструкций по сборке исходного кода, и результатом должен быть один или несколько пакетов .deb, которые вы можете установить с помощью менеджера пакетов.

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

(Вы можете получить предупреждение от менеджера пакетов, если не предпримете дополнительные шаги для криптографической подписи пакетов, которые вы создали, в зависимости от того, какой инструмент управления пакетами вы используете, но, поскольку вы только что создали пакеты самостоятельно, вы, вероятно, доверяете им.)

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

Как с общими инструкциями по сборке исходного кода, так и со специфическими для Debian -dpkg-source -b, если программный пакет, который вы собираете, зависит от некоторых библиотек,вам нужно будет не только установить совместимые версии этих библиотек (, в инструкциях по сборке обычно перечислены требуемые минимальные версии требуемых библиотек ), а также пакеты разработки для этих библиотек, чтобы компилятор знал, как использовать библиотеки.

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

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