Некореневі менеджери пакунків

З мого дослідження, я, мабуть, зауважую, що всі менеджери пакунків наполягають на тому, щоб він використовувався як привілейований користувач і його потрібно встановити /.

Як правило, мені подобається створити обліковий запис, скласти деяке програмне забезпечення та встановити $HOMEдля цього облікового запису. Я можу спробувати різні налаштування, і тоді, коли я закінчу, просто знищуйте обліковий запис.

Однак компілювання програмного забезпечення стає втомливим.

Мій досвід насправді обмежений yum, але я не розумію, чому я не зміг би впустити репо-файл ~/etc/yum.repos.dі попросити інсталювати все в домашній обліковий запис.

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

Бінарні пакунки складаються з припущенням, що вони будуть встановлені в певних місцях у /. Це не завжди легко змінити, і для цього знадобиться додаткові зусилля із забезпечення якості (що в першу чергу досить складно!), Щоб визначити, чи є конкретні бінарні файли чи не переміщуються.

До певної міри ви можете використовувати такі речі, як fakechroot, щоб створити всю систему в підкаталозі як некористувальний користувач, але це втомливо і неміцно.

У вас буде більше удачі з вихідними пакетами. Префікс Gentoo і GooLinux без коренів - це менеджери пакетів, які можуть встановлюватись у не /місцеположеннях і можуть бути використані не rootкористувачами.

Існує проект менеджера пакунків - Nix - із цікавою основоположною ідеєю (" функціональний " менеджер pkg), який також підтримує операцію кожного користувача:

Підтримка користувачів

Починаючи з версії 0.11, Nix підтримує багатокористувацьку підтримку. Це означає, що непривілейовані користувачі можуть надійно встановлювати програмне забезпечення. Кожен користувач може мати інший профіль, набір пакунків у магазині Nix, які відображаються в PATH користувача. Якщо користувач встановить пакет, який інший користувач вже встановив раніше, пакет не буде складено або завантажено вдруге. У той же час, одному користувачеві неможливо ввести троянський кінь у пакет, який може бути використаний іншим користувачем.

ПРИМІТКА, Я ХОЧУ ДОБАВИТИ: Nix потрібно використовувати в Unix-подібній системі на ваш вибір (наприклад, дистрибутиві Linux).

Існує також асоційована велика колекція пакетів, які можна встановити за допомогою менеджера пакетів Nix - Nixpkgs --будували для декількох платформ :

• GNU / Linux на 32-розрядному та 64-бітному x86 (i686-linux та x86_64-linux)
• Mac OS X (i686-darwin та x86_64-darwin)
• FreeBSD (i686-freebsd та x86_64-freebsd)
• OpenBSD (i686-openbsd)
• Windows / Cygwin (i686-cygwin),

і пов'язаний дистрибутив - NixOS :

NixOS - це дистрибутив Linux, заснований на Nix. Він використовує Nix не лише для управління пакунками, але і для управління конфігурацією системи (наприклад, для створення конфігураційних файлів в / і т.д.). Це означає, серед іншого, що можна легко повернути всю конфігурацію системи на попередній стан. Також користувачі можуть встановлювати програмне забезпечення без привілеїв root. Детальніше ...

і пов'язана система "безперервної" побудови - Hydra .

В першу чергу це пов'язано із залежностями. Деякі пакети не можуть бути встановлені користувальницьким PolicyKit. Отже, це потребує додаткового навантаження на пакувальника, який дарує свій вільний час, і зазвичай встановити програму так само просто, як набрати текст sudo(однокористувацька станція) або заявити адміністратора.

Є варіанти встановлення в $ HOME

• Примітивні "менеджери пакунків" з мовою зазвичай підтримують його поза коробкою (наприклад, дорогоцінний камінь для Ruby або Cabal для Haskell) або з невеликим налаштуванням (я забув ім'я для python)
• Добрий старий ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(або варітації, як jhbuild).
• Там була програма для установки в $ HOME кілька років тому. Однак я не можу його знайти - я думаю, майже ніхто не використовував його, оскільки він встановлював їх самостійно або адміністраторів гвоздів.

Я використовую JuJu, що в основному дозволяє мати дійсно крихітний дистрибутив Linux (містить лише менеджер пакунків) у вашому каталозі $ HOME / .juju.

Це дозволяє мати вашу власну систему всередині домашнього каталогу доступною через proot, отже, ви можете встановлювати будь-які пакунки без привілеїв root. Він буде працювати належним чином для всіх основних дистрибутивів Linux, єдине обмеження полягає в тому, що JuJu може працювати на ядрі Linux з мінімально рекомендованою версією 2.6.32.

Ще одна із досить іншою моделлю - 0install . Він заснований на ідеї, що ви насправді не встановлюєте пакети, а просто запускаєте їх із глобального простору імен, який завантажує, компілює при необхідності та кешує програмне забезпечення, яке ви хочете використовувати.

Якщо ви добре працюєте з компіляцією з джерела та вирішенням залежностей самостійно, головним чином, хочете, щоб менеджер пакунків управляв операціями розгортання / нерозгортання / оновлення, ви можете поглянути на GNU Stow або дещо вдосконалений XStow . З ними ви встановлюєте інсталяцію в окремий каталог (як правило, під $PREFIX/stow), а потім stow робить посилання на програмне забезпечення з вашого реального префікса. Це дозволяє легко видалити програмне забезпечення повністю. Я успішно використовую його для управління своїм програмним забезпеченням, встановленим на замовлення в моєму університеті.

Мій досвід насправді обмежений лише yum, але я не розумію, чому я не зміг би скинути репо-файл у ~ / etc / yum.repos.d і змусити yum встановити все в домашній обліковий запис.

Менеджери основних пакетів Linux розглядають світ як системний адміністратор ... де машина є єдиною сутністю. Це дозволяє отримати відповіді на запитання на кшталт "які видатні помилки застосовуються до системи X" та "як відрізняються система X і система Y". Це також дозволяє yum мати "історію", яка може бути використана, мати rpmdb версії та робити такі речі, як "yum - оновлення безпеки" тощо.

Є деякі менеджери пакунків, наприклад, zero-install, які намагаються переглянути світ як користувач ... тобто. які додатки зробити я мати доступ.

Ви можете подумати, що пізніша модель є кращою, але IMNSHO є причина, що ви не чули про встановлення нуля, але чули про нум.

У блоці є нова дитина: " JuNest ( Jailed User NEST) - дистрибутив на базі Arch Linux, який працює на будь-якому дистрибутиві Linux без доступу до кореня". @ https://github.com/fsquillace/junest Перевага полягає в тому, що він не вводить новий вид формату пакету, тому після дуже простої установки (мінімум: приблизно 320 млн.), повний сховище Arch Linux (понад 13000 пакетів банкоматів) у вас під рукою.

Інструменти, які використовується Slackware, зокрема installpkg, можуть. На чоловіковій сторінці:

--root /otherroot
       Install using a location other than / (the default) as the root of the 
       filesystem to install on. In the example given, use /otherroot instead.
       Setting the ROOT environment variable does the same thing.

Однак я не знаю жодного з кращих фронтальних, які здатні це зробити (наприклад slapt-get, наскільки я знаю, не можу цього зробити). Теоретично, ви повинні бути в змозі псевдонім installpkgдо installpkg --root ~/Apps- однак, я думаю , що більшість фронтендів вимагає кореня для запуску, яка перемагає точку.

Я б запропонував http://linuxbrew.sh/

В основному це вилка пива для macOS і має попередньо складені двійкові файли для використання ...

Особливо чудово підходить для обробки старих версій gcc.

Якщо ви дійсно хочете встановити вручну, корисним посібником є http://www.linuxfromscratch.org/

Yum потрібно записати в базу даних, яка є власною коренем. Через це ви не можете використовувати його як звичайний користувач.

Ви можете спробувати розпакувати файли rpm (rpm2cpio package.rpm | cpio -idmv) всередині обраного вами каталогу.

Але коли ви виконаєте свою програму, вам доведеться подбати про зміну LD_LIBRARY_PATH, щоб завантажити залежні бібліотеки. Також це не піклується про будь-які залежності.

Приклад:

# mkdir new_root
# cd new_root
# wget ftp://mirror.switch.ch/pool/4/mirror/centos/6.7/os/x86_64/Packages/vim-enhanced-7.4.629-5.el6.x86_64.rpm
# rpm2cpio vim-enhanced-7.4.629-5.el6.x86_64.rpm | cpio -idmv
# ./usr/bin/vim -version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 24 2015 02:23:23)

Вищезгадане не має залежних бібліотек, інакше вам доведеться використовувати щось на зразок:

export LD_LIBRARY_PATH=./usr/lib ./usr/bin/program