Пользователь
0,0
рейтинг
30 июня 2009 в 13:13

Администрирование → Linux: Установка программ не входящих в дистрибутив при помощи менеджера xstow

Введение


Современные дистрибутивы Linux имеют в своем составе очень много софта. Проблемы с установкой/удалением/обновлением такого софта решены, можно сказать, идеально. Всем занимается менеджер пакетов. Выбрали нужный пакет, менеджер пакетов установит его. Нужно удалить — менеджер пакетов удалит и аккуратно все почистит. Но, иногда хочется, или нужно, установить программное обеспечение, не входящее в дистрибутив, или распространяющееся в исходниках, или даже в бинарниках. Как поступать в таких случаях?


В дальнейшем, для определенности, предполагаем, что мы используем Linux, дистрибутив Ubuntu или Debian.

Установка пакета из исходников


Классический для свободного софта путь распространения, распространение в исходных текстах. В таком виде программа представляет собой архив с именем вида:

name-version.tar.gz


Установка такого софта производится выполнением набора несложных команд:

tar -xzvf name-version.tar.gz
cd name-version
./configure
make
sudo make install


Расшифровка действий:

Шаг Команда Что делает
1 tar -xzvf name-version.tar.gz Распаковка архива
2 cd name-version Переходим в полученный после распаковки директорий
3 ./configure Настройка исходников на нашу систему
4 make Компиляция
5 sudo make install Установка


Проблемы


Проблема 1: Отсутствие нужных библиотек


Очень часто все не идет так гладко, а на шаге 3, команда configure на что-то жалуется. А жалуется она как правило на отсутствие нужных библиотек, или заголовков библиотек. Рассматриваем внимательно выход, который выдала команда configure на консоль и устанавливаем недостающие библиотеки и заголовки. Заголовки для Debian-подобных дистрибутивов, в том числе и для Ubuntu находятся в пакетах с суффиксом -dev в названии пакета.

Предположим мы увидели, что configure жалуется на библиотеку, устанавливаем ее в систему:

sudo apt-get install name


Запускаем configure опять. Теперь жалуется на заголовки этой же библиотеки. Устанавливаем и их:

sudo apt-get install name-dev


Ну наконец, установили все нужное, откомпилировали, работаем и получаем удовольствие. Казалось бы, счастье, вот оно. Но нет, вырисовывается проблема 2:

Проблема 2: бардак в системе


Предположим, мы установили одну программу из исходников, другую, третью. И вдруг нам понадобилось удалить первую, или заменить ее версию. А мы, оказывается не знаем, какие файлы относятся к этой программе и где они. Одни программы устанавливают свои файлы в иерархию /usr/local, другие вообще в /usr. В общем, мы не знаем, как вычистить файлы, относящиеся к пакету.

Отступление: Стандартная иерархия файловой системы Linux (File System Hierarchy Standard)


В Linux есть стандарт на размещение файлов в системе. Ссылки приведены в разделе Литература. По этому стандарту, в иерархии директорий /usr должны храниться файлы используемые пользователями, в том числе и пользователям с других компьютеров. В иерархии директорий /usr/local — файлы используемые локальными пользователями. Таким образом нам нужно наши программы ставить в иерархию /usr/local, и при этом избежать бардака.

Менеджер пакетов xstow


Сделать это нам поможет менеджер пакетов xstow. Можно пользоваться также менеджером stow, xstow — это расширенная версия. Что он делает? Очень простую вещь. Мы устанавливаем наши программы в иерархию /usr/local/stow, каждую программу в свою директорию, а потом менеджер xstow создает символьные линки на наши файлы из иерархии /usr/local. Устанавливаем xstow:

sudo apt-get install xstow


Теперь последовательность операций при установке пакета с использованием менеджера xstow.

tar -xzvf name-version.tar.gz
cd name-version
./configure --prefix=/usr/local/stow/name-version
make
sudo make install
cd /usr/local/stow/
sudo xstow name-version


Расшифровка действий:

Шаг Команда Что делает
1 tar -xzvf name-version.tar.gz Распаковка архива
2 cd name-version Переходим в полученный после распаковки директорий
3 ./configure —prefix=/usr/local/stow/name-version Настройка исходников на нашу систему так, чтобы установить в указанный директорий
4 make Компиляция
5 sudo make install Установка
6 cd /usr/local/stow/ Переходим в директорий, где лежат программы
7 sudo xstow name-version Создаем символьные линки в иерархию /usr/local


Команда:

sudo xstow -D name-version


Удаляет символьные ссылки. После удаления ссылок директорию с файлами программы, находящуюся в /usr/local/stow/ можно удалять.

Заключение


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

Литература


1. Стандартная иерархия файловой системы Linux (File System Hierarchy Standard)
2. Filesystem Hierarchy Standard
Евгений Казанов @evgenyk
карма
27,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (83)

  • НЛО прилетело и опубликовало эту надпись здесь
    • +5
      Я очень редко его встречал, поэтому и не упомянул. Я на эту возможность никогда не рассчитываю.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          — ./configure — сейчас поправлю.
          — Это как обо всех возожностях писать? Документацию переписывать?
          • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              Нормально.
    • +5
      Лучше бы он про checkinstall написал.
    • 0
      при этом правда нада исходники не удалять. И если потом сделать ./configure с другими параметрами, make uninstall уже может не совсем так же работать. Что, впрочем, очевидно.

      проще ебилд написать за 5 секунд =)
  • 0
    все конечно хорошо, но кроме GNU build system есть и другие. лучший метод установки — прочесть сначала README, INSTALL etc. дальше по обстоятельствам
    • +1
      Цель статьи — показать начинающим возможности xstow по наведению порядка, кстати есть еще и другие методы, но у меня прижился этот.
      • 0
        если софтина собирается не autotools, то смысла в configure нет. make могут и полностью свой написать, а что там за таргеты будут, какие переменные окружения там используются — все зависит от разработчика. в конце-концов кто то захочет и прикрутит bash скрипт для инсталла и компиляции. если в посте основное — xstow, то следовало бы отразить это в названии :) а так, исходя из топика, хотел бы повторить для начинающих, что компиляция и установка программ, не входящих в дистрибутив начинается в первую очередь с чтения доков
  • 0
    добавлю-ка в избранное. спасибо
  • +8
    Под Убунту удобно после make, собирать пакет, а не ставить из исходников, с помощью checkinstall.
    • 0
      Пробовал, давно, правда. Нашел более удобным собирать пакеты в случае, если нужно устанавливать массово на много машин. В остальных случаях прижился xstow.
      Я и свои административные скрипты так же храню.
      • 0
        Ну вариантов вообще предостаточно, но мне просто не нравится плодить лишнии сущности.
        • 0
          Эта — не лишняя. Опыт многолетней работы в Debian, потом в Ubuntu.
          Этот способ:
          — Корректен и согласован с полиси.
          — Очень быстр, быстрее, чем менеджер пакетов.
          — Позволяет легко держать и переключать несколько версий софта, а это бывает ой как надо.
  • +6
    это все делает из убунты слакварь. не делайте так.

    если сложно следовать вот этому
    https://wiki.ubuntu.com/PackagingGuide/Complete
    и этому
    https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/basic-debhelper.html
    то есть графические хелперы:
    https://launchpad.net/~giftwrap/+archive/ppa
    https://launchpad.net/gdebui
    https://launchpad.net/debianpackagemaker
    https://launchpad.net/debcreator
    • 0
      Не соглашусь. Считаю, у каждого решения своя ниша. Опять таки соответствует стандартам на файловую систему.

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

      Когда нужно что-то установить по быстрому, на «посмотреть», установить новую версию, вполне считаю допустимым сделать так как описано.

      Вообще, традиционно, в UNIX есть три варианта установки, они сложились не зря, для каждого свое место.

      1. Установка в домашнюю директорию
      2. Установка в иерархию /usr/local
      3. Установка в иерархию /usr

      Важно не путать для чего какая нужна и не допускать бардака.
      • 0
        на посмотреть быстро… наверное, можно. тогда в этой статье нужно указать, что ./configure желательно вызывать с --prefix /some/private/writable-to-regular-user и обязательно без sudo make install. как-то так. но лучше такого не делать, даже быстро. простые пакеты просто дебианизировать а сложные так наверняка не станут, нужны будут зависимости, которые нужно либо ставить из таких же tar.gz так же криво, или мешать самосборы с системными.
        • 0
          В том-то и дело, что этот вариант не мешает самосборный софт с системным, а вот если пакетизировать, то мешает. В случае упаковки в пакеты нужно более тщательно тестировать и тратить больше времени, возможны конфликты имен с системным. Времени понадобится больше. Нужно самому решать, стоят ли этого затраты времени.
      • –1
        так уж получилось, что по политике дебиана в /usr/local не должно быть программ. Это так, просто к сведению.
        • +2
          www.debian.org/doc/manuals/reference/ch12.en.html#_compile_and_install_a_program

          Debian does not touch files in "/usr/local/" or "/opt". So if you compile a program from source, install it into "/usr/local/" so it will not interfere with Debian.
          • +3
            значит моя память оказалась настолько дырявой, насколько это возможно. Извините.
        • +1
          первый раз про такое слышу, что это за политика такая, можно ссылку?, всегда думал что там может быть что угодно в том числе и программы
      • +2
        Я все, что из исходников ставлю в /opt. Если надо удалить, то просто rm -rf /opt/каталог.
        • 0
          С xstow получается

          cd /usr/local/stow/
          xstow -D каталог
          rm -rf каталог
          


          Преимущества: xstow раскладывает ссылки по тем директориям, в которых другой софт и другие админы ожидают их увидеть. Да еще и пути и ld.so настроен на эти же директории.

          В случае же изменения версии софта, если вам нужно быстро поменять версию:

          cd /usr/local/stow/
          xstow -D ver-1
          xstow ver-2
          


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

          И всега порядок!
          • 0
            Такого софта не так много, чтобы его часто надо было видеть другим программам. А ls /opt напрямую выдаст список всех левых «пакетов».

            Я не против xstow, но например у меня программ из исходников всего две, так что ставить ради них еще менеджер нецелесообразно.
  • +2
    мне понравилась статья, пишите ещё.
    • –2
      статья дискретизирует убонтоводов, вы что думаете, юниксоиды не знают про мейк-мейкинстолл??? уже десятки лет все так как описано. в статье ничего нету о анализе конфиг-лога, билд-лога. ничего о контроле над ./configure… в статье рекомендуется по неудачному билду доустанавливать зависимости а не до начала установки. для дополнительных уроков информатики начальной школы — вот это что.
      • 0
        В мире вообще ничего нового нет, уже несколько тысяч лет.
        Статья для нычинающих. Не все ведь рождаются со знаниями дарованными свыше в голове.
        Как по мне, проще глянуть в выход ./configure и посмотреть, чего оно хочет, чем заранее все собирать. Где написано, что это некошерно?
        • 0
          это некошерно если чуток подумать: на этапе ./configure, если не отслеживать зависимости, можно получить отсутствие важной зависимости и в результате получить успешный билд но без требуемого функционала. например, одно время ffmpeg вынесли в экстернал зависимость в своем svn libswscale. если собирать руками и не смотреть на зависимости — можно получить после ./configure мейкфайл без USE_SWSCALER.
          • 0
            Конечно, если компилируешь из исходников, за зависимости отвечаешь сам. Однако иногда надо компилировать. И я тут уже привел ссылку на документацию Дебиан. Они советуют ставить самосборный софт именно в /usr/local и гарантируют, что их менеджер пакетов туда не полезет и конфликтов с менеджером не будет.
            • 0
              не цепляйтесь за /usr/local, да хоть в /my-super-bin/ — удивительно, но дебиан его тоже не тронет, но смысл? вы вторгаетесь не в техническую мешанину пакетов и зависимостей а в логическую. some-lib-xxyy.tar.gz вроде как и есть, а его пакетный менеджер не видит или ./configure вроде как работает, а собранный бинарник нет.
              • 0
                /my-super-bin/ Не подходит по двум причинам. Не кошерное место по полиси, bin намекает, что это только бинарники.

                Я уже тут писал, повторю еще раз. В UNIX три кошерных метода установки софта:

                1. Установка в домашнюю директорию — Устанавливает пользователь только для себя.
                2. Установка в иерархию /usr/local — Устанавливает администратор, софт уникаьный для данной машины, польуются локальные пользователи.
                3. Установка в иерархию /usr — Устанавливает менеджер пакетов, может быть расшарен по сети.

                Все методы законные и все настраивается так, что ни менеджер пакетов не сойдет с ума и ld.so будет работать.
                • 0
                  ну тогда подробней пожалуйста о том, как менеджер пакетов убунты узнает об установке пакета в /usr/local через make install. я такого не знаю.

                  а про три метода для юникса — ну почитайте про пути установки в pkgsrc или в сановском /opt/sun*. так уж только три?

                  прошу заметить, из всех возможных методов установки пакетов в убунте вы выбрали самый извращенный, самый неадекватный этому дистрибутиву и поверхностно его описали. я рад что народ минусует меня и пишет «фмемориз» вашей заметке. знаете почему рад? такие минусующие нюбы наиграются и уйдут. но кровушки и реноме бубунте попортят. а вы молодец, в принципе знаете о чем пишите и отстаиваете свою точку зрения, но вот ориентируетесь вы на сомнительную публику в написании и на сомнительные техники администрирования системы. всем удачи.
                  • 0
                    Так можно много чего придумать, есть конечно еще /opt, стоит ли рассматривать его как кошерный? Я бы скорей написал так: Некоторые фирмы используют для установки софта директорию /opt. Но вот вопрос, стоит ли ставить туда самому? Нет, пускай туда ставит установщик этих фирм.

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

                    Ваш метод хорош, но слишком турдоемкий. Кстати при сбрке пакета .deb Вы в какую иерархию хотите ставить? В /usr? Вот это источник потенциальной опасности и весьма реальной.
          • +1
            Да конечно, нужно читать доки. Но все доки читать — жизни не хватит. Поэтому ленивые (мудрые) люди читают тогда, когда что-то идет криво.
  • 0
    Я так понял пост затрагивает Ubuntu и используется GUI тогда, почему не пользоваться простым Synaptic Package Manager для установки? Или хочется последние версии пакетов?
    • 0
      Нет, это без использования GUI, консольное решение. Иногда нужно:

      — Софт, которго нет в дистрибутиве вообще.
      — Новая версия
      — Старая версия
      — Самописный софт
      — Несколько версий одновременно
    • 0
      нет, вы не правильно поняли. это затрагивает любой дебиан и консоль
  • +1
    советую также посмотреть в сторону paco, на хабре про нее как то писали
    • 0
      Глянул, в дистрибутив Ubuntu 9.04 нет.
      • 0
        а вы гляньте по ссылке ;)
      • 0
        от себя могу добавить, что выигрывает она в том случае когда у вас нет возможности(или возможность слишком нудная заключающаяся в правке вручную Makefile) установить софтину в --prefix
  • 0
    Как альтернативу xstow использую paco (pacKAGE oRGANIZER). Обзор можно посмотреть тут.
    • 0
      1. Заметил что уже упомянули.
      2. Пардон, хабр по каким-то причинам съел тег. Вот та самая ссылка itfreak.ru/software/unix-linux-source-code-package-management/
  • –6
    Собственно и забросил линукс, т.к. не смог ничего поставить.
    • +1
      За три года на Ubuntu ни разу ничего не ставил из исходников. Просто все самое новое уже есть либо в репах, либо в дебах. :) До этого в suse регулярно компилил.
      • +1
        Да, есть такая тенденция, все меньше и меньше приходится ставить мимо репозитариев. Но бывает и ставлю. Вот мой /usr/local/stow:

        eik-admin
        emacs-escreen
        emacs-html-helper-mode
        emacs-psvn
        mc-4.6.3
        python-cherrypy3
        skype-static-2.0.0.72
        
      • +1
        Хотел высказаться, но это не правильно в теме про Линукс. Вообще знаете, каждому свое. Вот мне не понравился сей факт и я не стал переходить на unix-like системы, хотя с выходом нового VirtualBox 3 решил попробовать еще раз.
        • +1
          Одного не понял, какой факт?
          • 0
            Как сказал Tonna очень сложно сломать привычки. Я начинал с мандривы, а потом и убунты, смог настроить сеть в вмваре, расшарить интернет и многое другое, но вот меня убивало то, что я так и не смог разобраться самостоятельно с установкой программ. Те, что устанавливались с помощью менеджера пакетов все было замечательно, с остальным приходилось мучатся. Это меня и отпугнуло в последний раз и сейчас когда я вижу статьи по установки софта под линукс с 3 листами мануалов я только в этом убеждаюсь (вспомнил статью про торрент-клиенты под линукс на хабре).
            • 0
              Ну, не все так печально. Разобраться вполне можно. Тем более в последнее время на Ubuntu почти не приходится ничего ставить не при помощи пакетного менеджера.
        • +1
          >каждому свое
          Безусловно. Сломать привычки очень трудно. Поэтому не минусовал.
          Я перешел на линукс раза с пятого, правда тогда дистрибутивы были куда менее удобны (не отмаунтишь CD, не откроет CD-ROM).
  • +1
    вообще считаю хорошим тоном при промышленном использовании дистрибутива создавать собственную ветку портов/пакаджей с системой автосбора и получать на выходе пакеты для родного пакетного менеджера, с помощью которого и обслуживаемого.

    не вижу смысла разводить десяток пакетных менеджеров и поэтому ненавижу всякие cpan'ы, pear'ы и т.д. а уж описанный тут xstow совсем жесть. но впрочем кому что нравится.
    • 0
      Ваш метод хорош тогда, когда у вас времени дофига и администрирование — это основное ваше занятие. А случаи как известно бывают разные. Я бы не стал применять такое сильное слово как ненависть. Вы, когда Вам нужно поставить на один компьютер какой-нибудь режим для emacs, которого нет в дистрибутиве, собираете для него пакет?
      Мне кажется, что при самостоятельной сборке пакета, который ставит в /usr/, Вы сами отвечаете за конфликты и это источник опасностей.
      • 0
        "… когда у вас времени дофига и администрировани...", — в моему псто ключевое слово «промышленном», это означает что требования к ПО не могут быть удовлетворены «готовыми» продуктами и для каких-то целей (не устраивают опции с которыми скомпилировано в репозитарии, не устраивает версия, нужно наложить собственный патч или что-то еще) требуется собственная сборка программы. случаи, да, бывают разные. никто не говорил что для 15 минутного всандаливания под пиво товарищу из соседнего офиса линуфрюкса требует обязательной самосборки пакетов.

        «Я бы не стал применять такое сильное слово как ненависть.», — дело твое, нынче модно быть толлератным ко всякой гомосятине. подчеркну еще раз _НЕНАВИЖУ_ цпаны, пиры и прочий шлак. у меня на это есть причины, которые вобщем-то очевидны.

        «Вы, когда Вам нужно поставить на один компьютер какой-нибудь режим для emacs, которого нет в дистрибутиве, собираете для него пакет?» — я не пользуюсь емакс. на самом деле эта ваша жизненная ситуация для меня не знакома и не только потому что я не пользуюсь емаксом. просто вот как-то у меня не было такого что ради того чтобы получить программу с нужными опциями надо было заморачиваться. видно оттого что я любитель *bsd и archlinux.

        «Мне кажется…… источник опасностей.» — мне кажется надо думать головой. и никаких источников опасности и паранои.
        • 0
          Для каждого случая — свой инструмент. Когда начинающим рекомендуют по каждому чиху собирать пакеты и устанавливать их в систему пакетным менеджером, это явный перебор, к тому же потенциально опасный.

          Это Волюнтаризм! (С) Кавказская пленница.

          Я вот пользуюсь вот этим молотком (xstow) для забивания гвоздей. Считаю его вполне адекватным своим задачам инструментом.
    • 0
      Поддерживаю. Если используешь debian-based то лучше следовать debian-way, пользуешь gentoo, то логично использовать gentoo-way, а тут на примере Дебиан показывается не пойми-какой-вей или попробуй-те-такой-вей который изначально подойдет только для собственных LFS, так как в остальных случаях нарушает логику работы менеджеров пакетов/исходников/чего-то-там еще в конкретно взятой системе. т.е. просто глупо начинать плодить сущности.
      • 0
        Только что приводил ссылку из Дебиан полиси. Это и есть кошерный Дебиан-вэй для самосборного софта. И как раз именно такой способ НЕ НАРУШАЕТ логику работы менеджера пакетов.
        Еще раз привожу цитату и ссылку.

        www.debian.org/doc/manuals/reference/ch12.en.html#_compile_and_install_a_program

        Debian does not touch files in "/usr/local/" or "/opt". So if you compile a program from source, install it into "/usr/local/" so it will not interfere with Debian.
        • 0
          «НЕ НАРУШАЕТ ЛОГИКУ», — это такая очевидная мелочь, что прямо даже как-то смешно. любой идиот понимает что надо ставить свои горепрограммки в отдельный каталог. рискну предположить что оно и /ololorealne каталог не будет трогать. только почему то мне от этого не легче когда речь заходит действительно о менеджменте пакетов.

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

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

          вы вольны поступать как хотите, нравится вам так, пожалуйста. я вас ни к чему не принуждаю. я просто высказываю мнение. а я за такой «юниксвей» бью линейкой по пальцам.
          • 0
            Странное какое-то мнение. Вы похоже статью не читали и понятия не имеете о чем она. Она как-раз о наведении порядка в «куче».
            Кстати, с такой методикой тоже есть некоторые проблемы/пробелы, но большинство критиков почему-то про них даже не подозревает.
  • +3
    это одна из тех статей, которая сбивает людей столку, особенно новичков.
    убунту — это система с пакетным менеджментом, поэтому софт нужно ставить в порядке убывания «правильности» так
    1) репозитории — это убунту-way
    2) через deb пакеты
    3) из исходников создавать deb пакеты, используя
    ./configure
    make
    sudo checkinstall.

    в дальнейшем следующий deb хотя бы корректно заменит предыдущий
    4) очень не рекомендуется из исходников ./configure && make install

    мое мнение на этот счет подробно forum.ubuntu.ru/index.php?topic=42599.0
    • 0
      Знаете, есть полиси, в котором ясно написано, какие программы, в каких случаях и куда ставить. Это надо понимать, что, когда, куда и в каких случаях. Я уже тут писал несколько раз. Вы считаете, что лучше ставить из пакетов и только из пакетов. Я по другому. Мое мнение, оно не просто так, оно в соответствии с полиси. Порядок путей установки софта по приоритетам:

      1. Из пакетов. Пакетным менеджером. Если есть нужный софт нужной версии.
      2. Из исходников в директорию /usr/local путем описанным в статье. Если нужно поставить софт, которого нет в дистрибутиве, версию, которой нет в дистрибутиве. Самодельный софт.
      3. В домашнюю директорию. Свой самодельный софт, софт которым пользуется только один пользователь, если нет прав админа на машине.

      Пример случая N2. Когда устанавливать в /usr/local. Я разрабатываю софт. Мне нужен вебсервер на Python — CherryPy 3.1, В дистрибутиве есть CherryPy python-cherrypy 3.0.
      Что лучше, установить в /usr/local, или собрать пакет и установить менеджером пакетов. Однозначно в этом случае лучше в /usr/local. Если собирать пакет, мне придется отвечать за зависимости и не факт, что это будет легко. Причем вылезти конфликт может в самом неожиданном месте.

      Когда нужно собирать пакет? Когда вы собираетесь распространять его. Но тогда Вы должны проверить перед сборкой пакета зависимости и возможные конфликты. И не факт, что это будет легко и Вы сможете разрулить конфликты без общения с другими мэйтенерами пакетов.
  • 0
    Мне кажется не лишнее упомянуть что в убунте легко сделать пакет, и вопросы с установкой/удалением исчезнут.
    Всего-то
    mkdir -p куда-то/DEBIAN
    touch куда-то/DEBIAN/control
    make DESTDIR=куда-то install
    dpkg-build -build куда-то
    и пакет есть ;)
    • 0
      Бабах и конфликтует с другим софтом. Не все, что легко — хорошо.
      • 0
        Если собрано на текущей машине, то с чего бы????
        • 0
          Как с чего? Вы установили софт не прожедший процедуру проверки зависимостей/конфликтов Debian/Ubuntu в иерархию /usr. Теперь устанавливаете какой-то совсем другой софт пакетным менеджером. И у Вас внезапно конфликт имен. Т.е. два файла, из Вашего пакета и вновь устанавливаемый имеют одно и то же имя. Или конфликт зависимостей.
          • 0
            Это вполне решаемая проблема, раз уж решиться на самосборку.
        • 0
          Я уже три раза к полиси разных граждан отсылал, там как раз про это написано.
          • 0
            Вообще размещение файлов дело наживное, абсолютно четких границ, скажем заданных в single unix guide, нет. В каких-то дистрибутивах есть какие-то предпочтения, но это только предпочтения. Есть деление по типу комманд (системные и нет). Есть рекомендации по размещению библиотек в гибридных системах типа (x86/x86_64), которые достаточно часто нарушаются.
            Вы предлагаете использовать несколько менеджеров пакетов, что вообще говоря совсем нехорошо.
            • 0
              Не вижу другого приемлемого решения. Менеджер пакетов дистрибутива и иерархия /usr — ИМХО не годится по приведенным мною неоднократно причинам. Полиси за меня.
              Какие будут Ваши доказательства? (С) Красная жара.
              • 0
                Я не говорю, что надо обязательно устанавливать и /usr, это дело, в основном, личных предпочтений, но до тех пор, пока не захочется делиться софтами с другими, вот тут полиси важно как никогда.
                Менеджеру пакетов, в принципе, все равно куда распаковывать, от него требуется знать что установлено для последующего удаления или обновления. Более провинутые варианты могут что-то делать с зависимостями.
                Совсем по-другому обстоит дело когда требуется иметь разные наборы библиотек и комманд, но это совсем не для новичков.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Имхо в pkg-based дистрибутивах надо собирать пакет из исходников — и тогда проблема контроля версий, контроля файлов — начинает отсутствовать как факт.
  • 0
    Проблема 1 — полная фигня. Раздули непонятно что из того, что можно решить одной командой, уж хотя бы man'ы почитали, чесслово.

    #apt-get build-dep

    Работает, если в sources.list прописан хотя бы один deb-src-репозитарий и в нём есть сырцы собираемого пакета. Намного быстрее и удобнее.
    PS Кромер xstow и paco есть ещё ipkg.
    • 0
      *#apt-get build-dep имя_собираемого_пакета
      PS Ох уж этот парсер
    • 0
      Способом, описанным в статье собираются программы, которых нет в репозиториях, поэтому apt-get build-dep не подойдёт.
      • 0
        Скажите, вы часто устанавливаете такие программы? Я видел такое всего один раз.
        PS Если в репозитариях нет бинарной версии — это не значит, что в репозитария нет исходных кодов.
        • 0
          Вопрос интересный. Попробуем ответить.

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

          С переходом на Убунту, необходимость уменьшилась, хотя и не исчезла совсем.

          Что устанавливаю теперь? Как и тогда, кое чего нет в дистрибутиве, кое-что нужно свежее, чем в дистрибутиве.

          Вот мой текущий список программ, установленных из исходников:

          | eik-admin              | Мои админские скрипты      |
          | emacs-escreen          | Нет в дистрибутиве         |
          | emacs-html-helper-mode | Нет в дистрибутиве         |
          | emacs-psvn             | Нет в дистрибутиве         |
          | mc-4.6.3               | Свежее, чем в дистрибутиве |
          | python-cherrypy3       | Свежее, чем в дистрибутиве |
          | skype-static-2.0.0.72  | Нет в дистрибутиве         |
          

          • 0
            Да, кроме этого есть еще несколько пэкиджей для emacs, установленных в домашней директории.
          • 0
            Вы не поняли. Для того, чтобы эта команда сработала нужен всего лишь список необходимых пакетов из deb-src-репозитария. Если нет в просто репозитари пакета, то это не означает, что нет его в репозитарии исходников. И версия там чаще всего значения абсолютно не имеет.
            • 0
              Опять я не понял. Как это версии не имеют значения? Тогда вообще ничего не имеет значения. Версия деб-пакета состоит, кстати из двух составляющих:

              — Версия софта, из которого сделан пакет
              — Версия пакета

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