Вопрос по установке программ (нужны подробности)

[kerg]

Ну, визуальная часть понятна – например в синаптике, отмечаю программу, она тянет зависимости и устанавливается. Открыл deb, посмотрел где написаны эти зависимости. Вроде в файле Control (depends). Остальное раскидывается по папкам bin, lib, share.
Этого достаточно или есть ещё что-то? Если я руками закидаю все файлы по папкам, программа заработает? Её будет видеть терминал (в том смысле что установленная программа может быть вызвана по названию)?

Это первая часть вопроса. А вторая сложней. Как поставить программу в другое место? Предположим я хочу поставить программу не туда куда предлагает менеджер пакетов и затянуть туда все зависимости.

[Bizdelnick]

Рекомендую почитать: http://debian-handbook.ru/packaging-system.html

Если я руками закидаю все файлы по папкам, программа заработает?

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

установленная программа может быть вызвана по названию)?

Да, если она находится в каталоге, указанном в $PATH.

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

Менеджер пакетов ничего не предлагает. Он просто распаковывает архив со всеми путями.

[kerg]

Менеджер пакетов ничего не предлагает. Он просто распаковывает архив со всеми путями.

Хорошо, но как всё-таки поставить программу в другое место (разумеется, наплевав на всю пакетную систему debian)?

[MrClon]

Средствами пакетного менеджера и без плясок с бубном — никак.
В общем случае можно самому скомпилять программу указав при этом нужный префикс.

[yars]

Насколько я могу судить, у apt* нет штатной возможности распаковать пакет в место, отличное от корня. Но зато это может dpkg. Если вдруг что не так, всегда можно написать что-нибудь свое, задача не очень сложная. Или, как сказали выше, пересобрать пакет с нужным префиксом.

[Bizdelnick]

Хорошо, но как всё-таки поставить программу в другое место (разумеется, наплевав на всю пакетную систему debian)?

Давайте конкретнее, а то там может оказаться слишком много тонкостей. Что за программа?

[Hephaestus]

Хорошо, но как всё-таки поставить программу в другое место (разумеется, наплевав на всю пакетную систему debian)?

У некоторых программ (например, Firefox) linux-версия доступна в виде тарболла с бинарниками. То есть уже скомпилированная. Распаковываем тарболл в удобный нам каталог, оттуда она в дальнейшем и запускается. Это один вариант.
Второй вариант: некоторые программы имеют инсталлятор типа programname.bin, который при запуске раскидывает файлы по нужным каталогам.
Минус обоих этих вариантов: пакетный менеджер об этих программах ничего не знает и управляться с ними будет сложнее.
А ещё некоторые программы изначально ставятся в /opt, который вроде бы, как раз для таких случаев и предназначен.
Отсюда вывод: установка программы в "другой каталог" вполне возможна, достаточно при сброке указать, "куда ставить-та?"(с)

А вот "плевать на пакетную систему" категорически не советую. Это может себе позволить пользователь с опытом сборки пакетов. Но такому пользователю и пакет собрать - не проблема.
Поэтому Вы всё-таки озаботьтесь созданием пакета, это наиболее правильный вариант, даже если программа уже в бинарном виде.
Если всё-таки речь идёт о сборке из исходников, то по первому времени (пока опыта наберетесь) поможет checkinstall - она создаёт вполне корректный пакет, и она не раз меня выручала.
Ну или в крайнем случае создайте в /opt/ каталог для этой программы и сгружайте всё туда. По крайней мере, будете знать, как удалить.
А вот раскидывать руками файлы по /usr/bin/ и пр. - вот этого делать не надо. Это вариант негодный.

[drBatty]

Этого достаточно или есть ещё что-то? Если я руками закидаю все файлы по папкам, программа заработает?

программа-то заработает, вот только пакетный менеджер НЕ сможет её удалить/обновить. Также, если программа сама является зависимостью, ПМ её вам второй раз поставит.

Как поставить программу в другое место?

собрать из исходников и опакетить.

[kerg]

Давайте конкретнее, а то там может оказаться слишком много тонкостей. Что за программа?

Да кучи программ, например из тестинга, ради которых не хочется превращать систему в тестинг.

[Bizdelnick]

из тестинга

Так бы сразу и сказали.
http://debian-handbook.ru/debian-packaging...uilding-package

[kerg]

оффтопик: а почему debian-handbook.ru не до конца переведён?

[Bizdelnick]

Хотите помочь с переводом? Милости просим: debian handbook russian translation

[kerg]

Что-то как-то тяжело идёт.
Вот написана зависимость 'нечто-dev (>= 2.0)', посмотрел в синаптике, там 'нечто-dev 1:2.24.4-2'
Как это понимать? На какие цифры смотреть?

Документация какая-то масонская. Команда 'apt-get build-dep пакет-исходного-кода' вообще не работает никак. Что туда писать? Там дальше по тексту предлагается вручную скачать три разных файла. Нашёл без проблем, скачал. Но что писать, так и не понял. "Невозможно найти пакет с исходным кодом". sources.list настроен.

[Hephaestus]

Вот написана зависимость 'нечто-dev (>= 2.0)', посмотрел в синаптике, там 'нечто-dev 1:2.24.4-2'
Как это понимать? На какие цифры смотреть?

В данном случае версия - это 2.24.4, то есть таки >=2.0

Команда 'apt-get build-dep пакет-исходного-кода' вообще не работает никак. Что туда писать? Там дальше по тексту предлагается вручную скачать три разных файла.

Не надо руками ничего скачивать.
1. В /etc/sources.list прописываете строку репозитария с исходным кодом (по аналогии с бинарным, только начинается с deb-src)
2.Выполняете от рута apt-get update
3.Поиском находите нужный пакет apt-cache search название-пакета
4.Получаете исходные тексты apt-get source название-пакета (здесь как раз скачиваются те три файла и сразу распаковываются,если не ошибаюсь).
5.Получаете сборочные зависимости apt-get build-dep название-пакета
6.Выполняете сборку dpkg-buildpackage -us -uc
Если что-то не получается, значит либо не из того каталога командуете, либо не с теми правами.
Пункт 6 лучше делать с помощью fakeroot.

Вроде ничего не перепутал. Если что, коллеги меня поправят.

[kerg]

В данном случае версия - это 2.24.4, то есть таки >=2.0

А что означают 1: -2?

Не надо руками ничего скачивать.

If you need another version, you may need to download it manually from a Debian mirror or from the web site.

1.2.3.4.5.

Мне нужна новая программа. Я поставил deb-src http://ftp.debian.org/debian testing main contrib nonfree
Делаю apt-get source название-пакета. "Невозможно найти пакет с исходным кодом"
Делаю apt-get build-dep название-пакета. "Невозможно найти пакет с исходным кодом"
Ладно, нет так нет. Скачиваю вручную три файла.
dpkg-source -x file.dsc
Захожу в папку, dch --local falcot > dpkg-buildpackage -us -uc [-d].
"Неудовлетворённые сборочные зависимости"
А т.к. apt-get build-dep не работает, начинаю ручками "удовлетворять" эти зависимости через синаптик. Но, увы, судя по циферкам, это не всегда возможно.
dpkg-buildpackage -us -uc [-d]
"Ошибка 2"

Короче, возвращаюсь к первоначальной теме. Возможно я что-то не до конца понимаю. А не проще установить в совершенно другую папку testing-программу со всеми зависимостями, наплевав на менеджер пакетов? Мне не нужны автоматические обновления, я никогда не использую автоматических обновлений и вообще редко что обновляю без надобности. Хочу как в windows. Хочу чтоб программы лежали каждая в своей папке и использовали библиотеки из своей папки. Хочу чтоб программа не зависела от изменяющихся (или неизменяющихся) цифр системных библиотек. Собственно, в windows цифры меняются только в свойствах, в основном. Название файла остаётся прежним, доступ к функциям остаётся прежним, старые интерфейсы максимально долго поддерживаются. (насколько я понимаю, это самые что ни на есть принципы ООП – инкапсуляция и полиморфизм с перегрузкой функций).
Что мы имеем в linux? Поменялась цифра в одном пакете (даже если там просто обновление безопасности) и нужно менять полсистемы? Зачем?

[Bizdelnick]

А что означают 1: -2?

Версия пакета состоит из трёх компонент: номер эпохи (по умолчанию - 0), версия исходного кода ПО и ревизия (версия сборки). При сравнении двух версий сначала сравнивается номер эпохи, если он не отличается - версия исходников, если и она не отличается - ревизия. Эпоха почти никогда не указывается (то есть равна 0) и увеличивается только если разработчик зачем-то несовместимым образом изменил систему нумерации (например после версий 1, 2, 3, ..., 99 выпустил версию 1.0).
https://www.debian.org/doc/debian-policy/ch...tml#s-f-Version

я никогда не использую автоматических обновлений

Зря. В Debian никогда ничего не обновляют без причины. Чаще всего - для устранения уязвимости, ну и для исправления ошибок, разумеется.

Хочу как в windows.

См. рис. 1. Используйте Windows.

Поменялась цифра в одном пакете (даже если там просто обновление безопасности) и нужно менять полсистемы?

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

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

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

[Hephaestus]

Мне нужна новая программа. Я поставил deb-src http://ftp.debian.org/debian testing main contrib nonfree
Делаю apt-get source название-пакета. \"Невозможно найти пакет с исходным кодом\"

Так, стоп.
Вы добавили deb-src http://ftp.debian.org/debian testing main contrib nonfree в /etc/apt/source.list.
После этого нужно сделать apt-get update, см. п.2 в моём предыдущем посте. Вы это сделали или нет?
Если нет, то ни apt-source, ни apt-cache, apt-get build-dep ничего не найдут.
Остальное не комментирую, ибо все последующие трудности проистекают отсюда.

[Goodvin]

Короче, возвращаюсь к первоначальной теме. Возможно я что-то не до конца понимаю. А не проще установить в совершенно другую папку testing-программу со всеми зависимостями, наплевав на менеджер пакетов? Мне не нужны автоматические обновления, я никогда не использую автоматических обновлений и вообще редко что обновляю без надобности. Хочу как в windows. Хочу чтоб программы лежали каждая в своей папке и использовали библиотеки из своей папки. Хочу чтоб программа не зависела от изменяющихся (или неизменяющихся) цифр системных библиотек. Собственно, в windows цифры меняются только в свойствах, в основном. Название файла остаётся прежним, доступ к функциям остаётся прежним, старые интерфейсы максимально долго поддерживаются. (насколько я понимаю, это самые что ни на есть принципы ООП – инкапсуляция и полиморфизм с перегрузкой функций).
Что мы имеем в linux? Поменялась цифра в одном пакете (даже если там просто обновление безопасности) и нужно менять полсистемы? Зачем?

Тогда Вам нужен другой Linux, с шахматами и поэтессами.
Например, https://ru.wikipedia.org/wiki/GoboLinux

Отличия от традиционных дистрибутивов
Файловая иерархия

В иерархии GoboLinux файлы сгруппированы по функциональному назначению в категории с использованием индексации, основанной на симлинках. Индекс хранится в директории /System/Links/: все исполняемые файлы доступны в /System/Links/Executables/, все библиотеки — в /System/Links/Libraries, и так далее. Такой подход устраняет традиционные, характерные для FHS различия между несущественными файлами, находящимися в /usr, и критически необходимыми файлами, которые находятся в корне /. Разработчики других дистрибутивов стараются этого придерживаться, потому что такие различия были когда-то полезны, но сегодня, в совершенно другой, современной среде, они не являются необходимостью.

Иерархия файловой системы

На структуру GoboLinux повлияли ранние системы, такие как NeXTSTEP, AtheOS и BeOS, которые использовали собственную структуру файловой системы, сохраняя заметную совместимость с Unix. В корне GoboLinux лежат 6 директорий: Programs, Users, System, Files, Mount и Depot. Содержимое каждой из них описано ниже.

/Programs/ — Эта директория содержит по одной директории на каждую установленную программу. Каждая из них, в свою очередь, содержит одну или больше директорий для разделения версий и, опционально, директории Settings и Variable. Примеры путей — /Programs/Bash/3.0/bin/bash, /Programs/Xorg-Server/Settings/X11/xorg.conf.

[kerg]

После этого нужно сделать apt-get update, см. п.2 в моём предыдущем посте. Вы это сделали или нет?

Конечно сделал. И apt-get update делал и в синаптике "обновить" делал. Ошибок вроде нет, но и толку нет тоже никакого.
Кстати, всё остальное, кроме deb-src http://ftp.debian.org/debian testing main contrib nonfree я отключил, чтоб не скачало что-нибудь ненужное.

[Bizdelnick]

всё остальное, кроме deb-src http://ftp.debian.org/debian testing main contrib nonfree я отключил

Всё-всё? А откуда, по-Вашему, зависимости для сборки должны устанавливаться?
Не надо ничего отключать. Если хотите исходники из тестинга, достаточно явно это указать: apt-get source пакет/testing

[kerg]

Всё-всё? А откуда, по-Вашему, зависимости для сборки должны устанавливаться?

Но сам-то исходник он должен скачать? А его почему-то нет. "Невозможно найти пакет с исходным кодом".
Отключал и подключал, толку ноль. Пакета нет. Поэтому и спросил что туда писать.

[Bizdelnick]

"Невозможно найти пакет с исходным кодом".

Давайте сюда целиком весь текст из терминала. С самой командой и полным её выводом.

[kerg]

включено только
deb-src http://ftp.debian.org/debian/ testing main contrib non-free


root@debian:/home/kkk# apt-get source gnome-commander
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
E: Игнорируется недоступная версия «1.2.8.15-3» пакета «gnome-commander»
E: Невозможно найти пакет с исходным кодом для gnome-commander


root@debian:/home/kkk# apt-get source fontmatrix
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
E: Невозможно найти пакет с исходным кодом для fontmatrix

[Bizdelnick]

Невозможно найти пакет с исходным кодом для fontmatrix

Его и нет в тестинге: https://packages.debian.org/search?keywords...amp;section=all
Что касается gnome-commander, то он есть и ставится, но для этого в источники надо добавить не только deb-src, но и deb.

Да, обратите внимание: устанавливать исходники и работать с ними надо от обычного пользователя, не от root!

[kerg]

Так ничего и не добился. Увы. Даже мелкие программки требуют превращать систему в тестинг. Честно говоря, непонятно, какие идеи сподвигли разработчиков сконструировать такую неудобную систему (имеется ввиду систему установки пользовательских программ).

[Bizdelnick]

Идея простая: это всё реально поддерживать в рабочем состоянии, своевременно исправляя баги и уязвимости и не привнося новых. А непривычно — не значит неудобно.
Можете попробовать более "либеральный" дистрибутив, Arch например.Только с ним подружиться будет посложнее, чем с testing. Но в итоге, возможно, поймёте, чего Вам надо, и выберете что-то среднее.

[kerg]

Я думал, что поддерживать прикладную программу в рабочем состоянии должны разработчики программы, а не системы.
Вот вышел, скажем, недавно новый inkscape (0.9), windows-пользователь получает его тут же, но при этом не удаляет старый. Потому что новый может быть с глюками, но зато в нём присутствуют новые полезные фичи, которые можно использовать прямо сейчас. При этом, что новую, что старую версии, можно просто распаковать и начать использовать. Для пользователя linux это целая история. К слову, для debian, в данный момент, новейшего inkscape нету, даже в unstable. Предполагается сидеть и вникать в премудрости сборки пакетов и пытаться удовлетворить неудовлетворимое – тысячи зависимостей.

(кстати, Firefox действительно сделан в виде архива. Скачиваешь и получаешь то, что нужно, без головной боли. Ещё больше зауважал FF).

[Bizdelnick]

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

Сколько дистрибутивов реально может поддерживать разработчик? Один, два? А их сотни, если не считать довольно близкие и похожие — всё равно десятки. Некоторые разработчики действительно держат свои репозитории для ряда дистрибутивов (последняя стабильная и разрабатываемая версии Inkscape, например, есть в PPA-репозиториях для Ubuntu). Но тянуть сразу всё невозможно физически, поэтому этим занимаются сопровождающие дистрибутива.

Предполагается сидеть и вникать в премудрости сборки пакетов и пытаться удовлетворить неудовлетворимое – тысячи зависимостей.

Не надо рассказывать сказок. Нет там тысяч зависимостей, а какие есть — вполне удовлетворимые. Вот сейчас ради эксперимента затянул исходники версии 0.91.0 для ubuntu 12.04 и запустил сборку под wheezy — никакой ругани на отсутствующие зависимости нет (собираю pdebuild'ом).
Upd. Собралось, можете взять, если хотите.

[Bizdelnick]

К слову, для debian, в данный момент, новейшего inkscape нету, даже в unstable.

Сейчас у разработчиков Debian наиболее наиболее приоритетная задача — работа над testing, в котором все версии пакетов уже заморожены. Обновления в unstable появляются нескоро. Это зависит от этапа жизненного цикла дистрибутива, привыкайте.

[kerg]

Не надо рассказывать сказок. Нет там тысяч зависимостей, а какие есть — вполне удовлетворимые.

Чтоб установить новый gnome-commander (мизерная программа, в сравнении), синаптик предлагает установить 285 новых пакетов, 338 пакетов обновить, 52 удалить, 386 mb получить. Вот вам и сказки.
Программа TotalCommander, которая значительно более развита, чем GnomeCommander, не требует вообще ничего и весит 5 mb, и работает на нескольких версиях windows без проблем. А тут мелочь требует 623 пакета, что говорить о более крупных?
И это при том, что система отлажена и в данный момент всё работает, и смысла менять всё это нет. А установлю я эту мелочь, где гарантия, что ничего не отвалится? (а оно совершенно точно отвалится, нужно менять и остальное тоже)
Мне надо прибить новую полку в подполе, зачем делать перепланировку половины дома?