Есть ли способ получить APT для установки пакетов в мой домашний каталог?

У Dpkg нет функции --relocate, которая есть у RPM. Однако стоит учитывать, сколько RPM-пакетов поддерживают эту функцию. По сути, это не может быть сделано.

Что вы можете сделать, так это использовать chroot, если вы хотите что-то протестировать перед глобальной установкой в ​​системе. Для этого вам нужно иметь возможность получить доступ к root. Первое, что нужно сделать, это создать базовый chroot:

# debootstrap lenny lenny-chroot

Это создает Ленни chroot внутри lenny-chroot каталог.

Теперь мы можем ввести chroot:

# chroot lenny-chroot

Теперь мы можем делать все, что захотим, и устанавливать все, что не мешает остальной системе. Когда мы закончим, просто введите выход или нажмите Ctrl-D

Linuxbrew - это еще один не-root менеджер пакетов для Linux (основанный на популярной системе управления пакетами Homebrew для OS X), который компилируется из исходного кода и сохраняет двоичные файлы в вашем домашнем каталоге.

Цитируя документы, особенности Linuxbrew:

• Может устанавливать программное обеспечение в домашний каталог и поэтому не требует sudo
• Установите программное обеспечение, не упакованное в собственный дистрибутив
• Установите последние версии программного обеспечения, когда родной дистрибутив устарел
• Используйте один и тот же менеджер пакетов для управления компьютерами Mac и Linux

Префикс Gentoo делает именно то, что вы хотите.

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

• Посмотрите пост разработчика для некоторого введения.
• Подробные варианты использования
• Информация об установке (?)
• Страница проекта

PS: Это не работает в Ubuntu >= 11.04 или любой другой производной Debian с Multiarch.

Так же, как незначительное дополнение к опции его компиляции, есть промежуточная опция компиляции в пакет с другим параметром префикса во время компиляции (с помощью "checkinstall" или, возможно, каким-либо другим способом). Преимущество заключается в том, что пакет будет отображаться в менеджерах пакетов, таких как aptitude или synaptic.

Кроме того, я думаю, что в некоторых случаях может быть возможно загрузить фактический.deb и принудительно установить другой префикс через установку dpkg, но я думаю, что это не то, что можно сделать с любым случайным пакетом, но они должны быть скомпилированы с некоторая переменная для их местоположения (а не буквальный явный префикс), которую вы экспортируете перед установкой. Я ничего не знаю о процедуре, однако, Google для "префикс dpkg instdir".

Вы можете использовать fakechroot - посмотрите демо на их сайте.

Нет, я не думаю, что ты можешь.

Лучшее, о чем я могу думать сейчас, это использовать apt-get source и скомпилируйте ваш пакет. Возможно, вы могли бы как-то настроить процедуру (которая может быть более или менее автоматизирована) для установки пакетов у вас дома.

Еще один должен использовать dpkg -X чтобы извлечь его в каталог по вашему выбору.

Безрукий GoboLinux может делать именно то, что вы просите: менеджер пакетов, без повышенных привилегий, в вашем собственном домашнем каталоге. Надеюсь, вы знаете, что делаете; rootless - не самый хорошо поддерживаемый режим установки Gobo, и когда я использовал его несколько лет назад, он потребовал нескольких настроек, поскольку скрипт установки был немного устаревшим по сравнению с другими изменениями Gobo.

Есть также клик, который перепаковывает довольно много .debs, может устанавливать пакеты в ваш домашний каталог и не требует никаких привилегий root для работы... но для первоначальной установки требуется root.

У меня есть решение, которое я успешно использовал для установки БОЛЬШОЙ коллекции взаимодействующих программных пакетов на школьном сервере Debian, где у меня вообще нет корневого доступа (даже для установки другого менеджера пакетов). Не использует deboostrap ни какой менеджер пакетов.

Метод частично ручной, но я сделал все возможное, чтобы сделать его удобным.

Он использует этот скрипт, который я назвал install (не забудьте chmod +x Это):

#!/bin/bash

# PREFIX is the installation root, i.e. a directory you have write access to
PREFIX=$HOME

# unpack the archive to $PREFIX
ar p "$1" data.tar.xz | tar xJ -C $PREFIX

# go through all unpacked text files and search for occurences of /usr/...
# we're gonna replace some of them with $PREFIX/usr
files=$(dpkg --contents $1 | grep '^-' | awk '{print $6}' | sed 's/^..//' | sort | uniq)
for f in $files; do
    file="${PREFIX}${f}"
    if grep -Iq . "$file"; then
        if grep -q '/usr' "$file"; then
            # interactively ask for each occurence, if it should be replaced
            vim -c '%s#/usr#'$PREFIX'/usr#gc' -c 'wq' "$file"
        fi
    else
        echo "Leaving binary file $file unmodified"
    fi
done

Поэтому обычно я сначала скачиваю файл deb, используя apt-get download package_name, Тогда я бегу ./install package_name_blabla.debи вручную принимать решение о каждом случае /usr в распакованных файлах, если он должен быть заменен на $PREFIX/usr или нет.

Это решение полностью зависит от того, какие пакеты установлены в системе, а какие установлены с помощью этого метода. Обычно, например, файлы pkg-config нуждаются в такой замене, тогда как строки shebang, такие как #!/usr/bin/perl не делайте. Общее правило заключается в том, что результирующий путь должен указывать на существующий файл.

Если пакеты установлены таким образом, вам, очевидно, нужно как-то рассказать о них другим программам. Это может быть достигнуто путем добавления правильных значений в LD_LIBRARY_PATH, PATH, PYTHONPATH, PKG_CONFIG_PATH, CMAKE_MODULES_PATH, CMAKE_PREFIX_PATH и т.п.

В этом подходе есть предостережение, что зависимости не загружаются / устанавливаются автоматически; Вы должны отслеживать их вручную.

Кроме того, APT, очевидно, не знает об этих пакетах, поэтому всегда будет показывать, что они отсутствуют. Но это имеет смысл - кто захочет установить общесистемное приложение, которое зависит от установки пользователя.

Если вы хотите удалить программу, вы можете перечислить содержимое архива deb, используя ar p "$1" data.tar.xz | tar tJ а затем удалите все эти файлы из PREFIX,

Я обычно получаю исходники и проверяю файл типа "INSTALL". Обычно есть инструкции, чтобы сделать ./configure --prefix=somedir, Тогда вы должны добавить somedir/bin на ваш путь.

Очень мало случаев, когда вам нужно устанавливать пакеты в вашу домашнюю папку.

Однако вы можете скомпилировать и установить программное обеспечение на свой локальный компьютер. Просто распакуйте, затем настройте ./configure --prefix=$HOME/local или какой-то другой каталог. Вы можете тогда make а также make install как обычно. Это скомпилирует и установит эту программу в ~/local/Например, программа, которую вы выполняете, будет в ~/local/bin/programmname,

Я все еще работаю над проблемой, но debootstrap в основном то, что вам нужно, и должно работать с fakeroot. debootstrap - это просто набор сценариев оболочки, поэтому я разбираю его, чтобы посмотреть, что заставляет его работать. Трудной частью будет удаление файлов после их установки.

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

Лучшее, что я могу придумать, - это среда chroot, как люди делают для 32-битных приложений в 64-битных системах. Это более затратно, как если бы вы вызывали debootstrap в chroot, но с некоторыми символическими ссылками, забавным скриптом оболочки оболочки, он может делать то, что вы хотите.

Из моего собственного опыта не существует простого способа использовать существующие пакеты DEB для установки в другой каталог, который не является средой chroot. Для всех инструментов установки Debian/Ubuntu dpkg/ aptitude/ dselect требуются привилегии root для правильной работы.

Теперь, имея исходную DEB, вы можете изменить файл Debian / rules, чтобы он собирал и устанавливал пакеты в другое дерево каталогов, но тогда вы не используете уже имеющиеся двоичные пакеты.

Как уже упоминали другие, вы можете использовать debootstrap и легко создать среду chroot, что я делал в прошлом, чтобы иметь 32-битную среду на 64-битном хосте, но для этого требуется установка chroot, по крайней мере, с дублированными базовыми пакетами. Если у вас есть место, и это жизнеспособное решение, вы можете соединить его с dchrootили даже лучше schroot, чтобы облегчить выполнение приложений, установленных в среде chroot.

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

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

rpm --initdb --dbpath DIRECTORY

Тогда есть несколько вариантов, которые могут помочь:

• --prefix
• --relocate