Гуру велосипедостроения
0,2
рейтинг
21 октября 2011 в 11:51

Администрирование → Хочется взять и расстрелять, или ликбез о том, почему не стоит использовать make install

К написанию сей заметки меня сподвигло то, что я устал делать развёрнутые замечания на эту тему в комментариях к статьям, где в качестве части инструкции по сборке и настройке чего-либо для конкретного дистра предлагают выполнить make install.
Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

Лирическое отступление


Как известно, для нормальной работы большинство софта должно быть не только скомпилировано, но и правильно установлено в системе. Программы ожидают найти нужные им файлы в определённых местах, и места эти в большинстве *nix-систем зашиты в код на этапе компиляции. Помимо этого аспекта основным отличием процесса установки в linux/freebsd/whatever от таковой в Windows и MacOS является то, что программа не просто складывает кучу файлов в отдельную директорию в Program Files или /Applications, а «размазывает» себя по всей файловой системе. Библиотеки идут в lib, исполняемые файлы в bin, конфиги в etc, разного рода данные в var и так далее. Если вам вдруг понадобится её обновить, то всё это надо сначала как-то вычистить, т. к. при использовании новой версии остатки файлов от старой могут привести к совершенно непредсказуемым последствиям, зачастую нехорошим. Вероятность этого события не так велика, но оно вам надо на боевом сервере?

И что с того?


Так вот, если вы делали установку напрямую через make install, то нормально удалить или обновить софтину вы, скорее всего, не сможете. Более того, установка новой версии поверх старой, скорее всего, затрёт ваши изменения в конфигах. make install делает ровно то, что ему сказано — производит установку файлов в нужные места, игнорируя тот факт, что там что-то уже есть. После этого процесса совершенно никакой информации о том, что и куда ставилось, получить в удобоваримом виде невозможно. Иногда, конечно, Makefile поддерживает действие uninstall, но это встречается не так часто, да и не факт, что корректно работает. Помимо этого хранить для деинсталяции распакованное дерево исходников и правил сборки как-то странно.

Как бороться?


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

  1. берётся определённым образом сформированный архив
  2. из него извлекается информация о том, что это вообще такое, какой версии, от чего зависит, с чем конфликтует, надо ли для установки/удаления/настройки запускать какие-то скрипты, etc
  3. Выполняются действия по непосредственной установке
  4. Все данные о том, куда и что было поставлено добавляются в базу данных пакетного менеджера.


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

Если вы по незнанию/лени скопипастили make install из инструкции, то в системе появляются файлы, о которых пакетный менеджер не знает. Со всеми вытекающими, если вам мало того, что было перечислено ранее.

Что делать?


Можно, конечно, сконфигурировать дерево исходников так, чтобы установка всего и вся шла куда-нибудь в /opt/mycoolapp/, а потом при необходимости руками удалить, но тут может вылезти масса неприятных вещей, начиная с того, что программа ожидает, что сможет загрузить свои библиотеки, а загрузчик о директории, где они лежат ничего не знает, заканчивая тем, что автор программы может рассчитывать, что например, если он кладёт файл, скажем в $prefix/share/xsessions/, то его подхватит менеджер дисплея. Не говоря уже о путях для pkgconfig и прочем.

Так что надо собирать пакет.

У меня нет времени, чтобы ***ться с этим, лучше ещё раз сделаю make install, всё просто и понятно!


Спокойно, спокойно. Он у нас за ноги привязан. Всё не так уж страшно и сложно, как кажется на первый взгляд.

checkinstall

Данная чудесная утилита, будучи запущенной вместо make install задаст несколько вопросов, после чего сама соберёт и установит пакет. Всё, при обновлении никаких проблем с вычисткой старого хлама у вас не будет.

Сборка deb-пакета вручную

Если вы не склонны доверять такой автоматике (которая иногда всё же косячит) или же хочется внести пару изменений, но разбираться с нормальным процессом сборки пакетов всё же лениво, то можно собрать пакет ручками. Я привожу способ, как соорудить его для систем на базе Debian, т. к. лучше всего знаком именно с ними. Он не является идеологически правильным, но на выходе получается вполне корректный пакет без задействования дополнительных сущностей. Делается это следующим образом.
Для начала собираем софт с предварительно указанными для configure или autogen.sh параметрами --prefix=/usr и --exec-prefix=/usr.
Далее производим установку во временную директорию. Пишем:

fakeroot
make install DESTDIR=`pwd`/tempinstall

После чего получаем в свежесозданной директории весь тот набор файлов. Кстати, мы сейчас находимся в fakeroot-окружении, т. е. можно невозбранно менять владельца и права доступа файлов, но физически в системе владельцем останетесь вы сами. Софт же внутри fakeroot-сессии будет получать изменённую информацию, что позволит упаковать в архив файлы с корректными правами.
Далее создадим в «корне пакета» директорию DEBIAN и сложим в DEBIAN/conffiles список всех файлов, которые должны попасть в /etc:

cd tempinstall
mkdir DEBIAN
find etc | sed "s/^/\//" > DEBIAN/conffiles

После чего создаём файл DEBIAN/control следующего содержания:
Package: имя_пакета
Version: 1.2.3
Architecture: amd64/i386/armel/all
Maintainer: Можете вписать своё имя, можете дребедень, но если оставить пустым, то dpkg будет ругаться
Depends: Тут можно вписать список пакетов через запятую.
Priority: optional
Description: Тоже надо что-нибудь вписать, чтобы не кидало предупреждения


При необходимости там же можно создать скрипты preinst, postinst, prerm и postrm.

Всё, делаем dpkg -b tempinstall и получаем на выходе tempinstall.deb, на который можно натравить dpkg -i и который корректно установится, обновится или удалится.

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

Заключение



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

А авторам статей на хабре просьба: пишите checkinstall вместо make install. Не надо давать вредные советы.
Никита Цуканов @kekekeks
карма
31,5
рейтинг 0,2
Гуру велосипедостроения
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +25
    Судя по заголовку, действительно наболело)
    • +4
      И судя по тегам тоже :)
    • +6
      судя по количеству людей, которые добавили в избранное, некоторые знания на поверхностном уровне, даешь ликбез в народ
      • +1
        я добавил в избранное, потому что комменты в таких статьях, не менее интересны чем сама статья и когда будет нужно, я смогу поднять исчерпывающие сведения по этому вопросу, тупо проглядев комменты и открыв ссылки
  • +6
    deb и checkinstall это хорошо. Вопрос. Подскажите теперь аналогичную тулзу для ArchLinux-а и CentOS-и
    • +4
      Так в центосе, емнип, тоже ж чекинсталл есть, который весьма успешно собирает rpm'ки.
    • +7
      checkinstall и rpm умеет, в арче — писать (или править любой готовый) pkgbuild.
    • +1
      RPM-ки checkinstall собирать умеет, так что ищите его в репах. А вот насчёт особого, принципиального нового формата пакетов арча ничего сказать не могу.
    • +1
      ArchLinux: PKGBUILD's + makepkg
      • 0
        Или yaourt который проверит есть ли готовый PKGBUILD для пакетa в aur.
        to kekekeks Новый формат пакетов а арче xz? Если да, то внутри тоже самое что и было просто более сильно пожатое.
        • 0
          Это такой намёк на то, что он отличается от остальных популярных бинарных дистров, использующих rpm/deb.
      • 0
        Я к тому, что, быть может, есть тулзы, которые автоматом генерят PKGBUILD?
        • +2
          На основе чего? PKGBUILD — shell-script c минимальным описанием пакета, я с трудом представляю, что в нём можно генерить.
          • 0
            Я знаю, что такое PKGBUILD. Вот только checkinstall вообще генерит пакет с нуля. Вот я хочу чтоб нечто генерило PKGBUILD (хотя бы базовый) с нуля.
            • +2
              checkinstall генерирует пакет посредством перехвата make install.
              А PKGBUILD — это инструкция по сборке пакета. Поэтому сгенерировать его нельзя.
          • 0
            Согласен с вами на все 110%.
            Проще чем сборка пакета в арче из PKGBUILD — при помощи makepkg вообще не в одном дистрибутиве не видел. Простой bash-скрипт поэтапной сборки пакета — начисто лишенный обращения к каким либо макросам, из всего что нужно знать — это названия переменных с которыми работает makepkg(архитектура, корневой каталог, каталог с исходниками, каталог с файлами пакета и т.д.). Потому: если, даже в общих чертах, знаешь bash — научиться писать PKGBUILD-ы дело 30-ти минут, тем более готовых «шпаргалок» огромное количество в ABS и AUR.
            пс:
            Тоже по сути наболело: раньше часто приходилось писать spec-файлы для «синтеза» rpm пакетов. Так вот писать PKGBUILD-ы после spec-ов: все равно что есть руками после использования кучи бесполезных и неудобных, но специализированных, костылей для каждого блюда.
    • +1
      checkinstall есть в репо rpmforge. Подключайте и пользуйтесь ;)
    • +1
      Для ArchLinux checkinstall есть в community репозитории. (во всяком случае, для 64-bit'ной

      community/checkinstall 1.6.2-1
    • 0
      Сначала Москва была Default City, потом Linux почему-то стал Default OS, а теперь стали забывать и о том, что кроме «любимого» ещё и другие дистрибутивы существуют :)
      • +2
        checkinstall покрывает все deb и rpm-based дистры, которых подавляющее большинство. Гентушники и сами разберутся, генту без долгого курения мануалов о том, как всё работает, не ставят. Остаётся только арч и совсем уж малоизвестные дистры, про которые можно даже не вспоминать.
    • 0
      Посмотрите в сторону pacinstall/wocka — аналоги checkinstall для Arch.
      • 0
        Wocka мертва с 2007 года, pacinstall как зависимость требует installwatch, которого уже ни в репозиториях, ни в АУРе. Есть ещё какие-нибудь альтернативы?
  • +7
    Да, видно, не только я переживаю за сотни захламленных систем этим мейк инсталлом. (:

    зы. Какой у вас сложный и интересный способ сборки DEBIAN'овских пакетов. (:
    Я всю жизнь собирал через dh_make и dpkg-buildpackage -rfakeroot. На мой взгляд, гораздо удобнее, разве что иногда приходится повозиться с некоторым софтом, потому что часть файлов забывает включаться в пакет.
    • +1
      dh_make генерирует довольно таки толстый debian/rules, который может на определённом этапе выдать ошибку или же вообще собрать нерабочий пакет, я, к сожалению, уже с этим не раз уже сталкивался. Описание же подводных камней выходит за рамки статьи. Так что описан 100%-рабочий способ с минимумом телодвижений.
      • 0
        У вас слишком старый dh_make. Теперешние debian/rules состоят зачастую из 4 строк, одна из который — шебанг, вторая пустая, третья из двух символов, а чётвёртая длиной меньше 10.
        • +1
          Ага, а разворачивается это в ту же самую простыню команд на 2 страницы.
          • 0
            Оно не разворачивается. Просто всё нужное запускает сам dh. Да и ломаться-то там нечему. Обычные пакеты, собирающиеся по ./configure && make соберутся там с такой же лёгкостью.
            • +1
              Были случаи, когда dh_shlibdeps отваливался.
    • +1
      Поподробнее напишите про ваш метод плиз.
      Спасибо.
      • +1
        dh_make — это такая штука, которая позволяет быстро получить заготовку пакета исходного кода, которой достаточно в 80% случаев. Ниже ссылку давали на дебиановкий мануал по сборке пакетов, если интересно узнать, как это идеологически правильно делается, можете ознакомиться.
  • +6
    В мемориз! Отличная статья)

    Давно в курсе что make install зло — но вот как-то руки не доходили до сборки пакетов собственноручно, хотя оказываеться все гораздо проще чем я предполагал.
  • +1
    Вообще, советы ваши несколько неправильные: пакеты из исходников сейчас собираются через dh_make -> debchange -> debuild -> debrelease с минимальным напряжением

    www.debian.org/doc/manuals/maint-guide/index.en.html
    • +4
      Отличный план, Жозе! А теперь вспоминаем, зачем обычно собирают из исходников. Правильно, чтобы изменить что-то в конфигурации сборки. Вам напомнить, какой debian/rules генерит dh_make?
      export DH_OPTIONS
      %:
      dh $@
      Вы мне предлагаете в статье объяснять, где что и как править, чтобы добавить туда свои опции?
      • +4
        Суть в том, что ничего править не нужно, Хуан!

        Тем более файл debian/rules

        На этапа dh_auto_build автоматически вызовется make -f Makefile в родительской директории с уже правильно установленной переменной окружения DISTDIR и все файлы соберуться в нужной директории и будут упаковы
        • +2
          Ладно, не будем спорить из-за того, какие именно 3.5 команды надо копипастить, тем более, что у вы описываете идеологически правильный способ. Для статьи же была выбрана методика, задействующая минимум дополнительных сущностей.
  • +4
    Спасибо, я научился :)
  • 0
    Как раз таки checkinstall умеет создавать rpm пакеты, хотя по оф сату только для слаки, но думаю разница не столько большая, чтобы он в CentOs не установился
  • +6
    Откройте для себя силу OpenSuSE Build Service (https://build.opensuse.org/), собирает RPM и DEB пакеты, имеет уже кучу собранных.
    Нужно только немного напрячься и почитать man`ы по SPEC файлам ;)
    • –1
      Откройте для себя силу OpenSuSE Build Service (https://build.opensuse.org/), собирает RPM и DEB пакеты, имеет уже кучу собранных.
      Слушайте, у меня 3 ppa-шки на ланчпаде, не надо мне рассказывать, как правильно писать сценарии сборки пакетов. В статье предложен упрощённый способ, как это сделать быстро, имея результаты сборки из дерева исходников и не включая лишний раз мозг, что и нужно в большинстве случаев.
      • +9
        оО откуда столько агрессии?
        Я не сказал что Ваш метод плох, я Вас не критиковал и не пытался Вас оскорбить.

        Цель моего комментария — дать ссылку на отличный сервис, более комплексно решающий данную проблему.
        • +9
          Воспринял комментарий как наезд, извините.
      • –3
        А ново сгенерированные RPM конфиги не затирают?
        • –3
          * А ново сгенерированные RPM, конфиги не затирают?
          • 0
            не должны, по идее, rpm новые конфиги, при наличии в системе файла с тем же именем, переименовывает в %name%.rpmnew
  • 0
    В Arch'е тоже отличная штука есть: makepkg называется, грузит исходники и собирает пакет по простенькому скрипту (PKGBUILD).
    Тоже пользуется fakeroot'ом, об этом даже задумываться не надо.
    Умеет готовить скрипт сборки для загрузки в AUR (репозиторий пользовательских пакетов Arch'а) и сама доложит в архив всё, что надо (если есть какие-то сторонние патчи, которые нельзя стянуть с интернета во время установки).
  • +1
    Если бы ещё и был краткий обзор создания пакетов в разных популярных системах, было бы совсем шикарно. Но и так злободневно :)
    • 0
      Да, даешь slackbuild'ы и ebuild'ы!
  • +3
    А для MacOS X при использовании brew/fink/ports что-то подобное есть? Иногда возникает необходимость в консольных утилитах, которых нет в репозиториях
    • 0
      Fink является портом дебиановского менеджера пакетов. Так что собирать под него можно по инструкции из статьи.
    • 0
      Для MacPorts есть инструкция про то, как создавать Portfile.
    • 0
      В brew можно brew edit aria2, к примеру (подойдет что угодно, что устанавливается по make install без патчей), и поправить url, md5 и homepage. Не «само», но работы на 5 минут от силы.
  • +5
    А ещё можно не особенно важные сторонние программы устанавливать, пусть даже make install'ом, в домашний каталог, куда-нибудь в ~/bin (указывая его как --prefix/PREFIX вместо /usr/local). Систему не затрагивает, удаляется легко.
  • 0
    Мне нравятся арчевские PKGBUILD'ы. Это даже немного на checkinstall похоже, можно в package() написать make DESTDIR=$pkgdir install и все.
  • +2
    Бывают ситуации когда как раз нужно чтобы о ПО не знал пакетный менеджер, чтобы оно не втискивалось в существующую систему, и чтобы стояла конкретная версия не соответствующая последней.

    Если есть голова на плечах и конкретная задача, то использовать make install можно.
    Если ты чайник и хочется толики экстрима, то лучше собирать пакет.
    • +4
      и чтобы стояла конкретная версия не соответствующая последней.
      В дебиане есть такая штука как dpkg --set-selections, с помощью которой можно запретить обновлять пакет без явного на то указания. В других дистрах есть аналоги. Не надо делать грязных хаков в виде make install, курите мануалы по своему пакетному менеджеру.
      • –2
        Т.е. вы считаете лучшим делать грязные хаки пакетному менеджеру, функционал которого будет только мешать в задаче?
        Вам не кажется это, мягко говоря, странным подходом?
        • +5
          Это не грязные хаки, а вполне обычный функционал, не передёргивайте. И чем вам помешает пакетный менеджер, интересно? Объясните, что ненормального в такой последовательности действий:
          — Установить пакет нужной версии.
          — Запретить пакетному менеджеру обновлять этот пакет.
          — Когда понадобиться свежая версия пакета, снять запрет и обновиться.

          Грязный хак — это использовать ручную установку в обход менеджера пакетов, точно так же, как использовать недокументированные функции в обход открытого API.
          • +2
            Пример:
            Нужно протестировать новую версию ПО, которого нет в репах, но уже есть у разработчика.
            Варианты:
            1. Можно поставить его в /opt обычным make install двумя командами и одной удалить.
            2. Можно выпендриться с созданием пакета и ставить все в живую систему при этом не имея гарантии что ПО не испоганит существующие настройки. Это займет 3 команды на установку в RPM-подобных и 6-7 в deb, плюс риск порчи данных.

            2-й вариант получается пакетный менеджер ради пакетного менеджера.
            Т.к. его функции только создадут дополнительные шаги.

            Соответственно вопрос: Зачем?
            • +1
              На «потестировать» я держу отдельное чистое chroot-окружение, поверх которого перед установкой «свежатинки» монтируется временная файлуха через aufs. Быстро поднимается, нет риска порчи данных.
              • +1
                А что делать если нужно тестировать его в работе?
                Или у вас только «сферические кони в вакууме»?
                • +1
                  Ну а в чём проблема тестирования в изолированном окружении-то? Зачем ставить параллельно со стабильной версией и запускать вместо неё? Давно не играли в русскую рулетку?
                  • +3
                    Задачи бывают разные, если у вас каких-то не было, не значит что их не бывает.
                    И все-таки вопрос — зачем придумывать себе лишнюю работу?
              • +1
                И опять таки, зачем лишние действия если можно их обойти без каких-либо рисков?
  • –4
    /usr/local, не?
    • +2
      Каким образом это решит перечисленные проблемы?
  • +4
    Авторы программ просят начала сделать configure, где можно указать префикс
    configure --prefix = /usr/local после этих действий будет Makefaile,
    где описан процесс сборки и установки и деинсталляции,
    так что потом можно легко сделать make uninstall.
    А ставить в бинарный дистр в /bin /usr/bin, самосбор — дурной тон :) получается действительно каша.

    И все таки рекомендую почитать доку по LFS и GNU configure and build system.
    Там еще очень много интересного :)
    • 0
      где описан процесс сборки и установки и деинсталляции
      Отлично, его надо хранить в сухом и недоступном для детей месте до того момента, когда понадобится обновиться?
      • +2
        Зачем? достаточно знать версию и префикс.
        Если хотите свои пакет часто обновлять, то рекомендуют сделать ebuild, rpm, deb, и тд
        Если все-таки нет желания разбираться с устройством *nix-ов,
        то могу предложить такой путь:
        распаковывайте установленную версию
        confugure --prefix=/usr/local; make; make uninstall
        распаковывайте новую
        confugure --prefix=/usr/local; make; make install
        • 0
          Зато как классно потом установить программу X версии 5.6.7 которая конфликтует с уже установленной подобным способом программой Y версии 3.2.1, а потом героически несколько суток разбираться почему же ничего не работает.
          • +1
            Что значит конфликтует?
            Если одна зависит от другой, то на это случай и нужны пакеты в дистрибутивах,
            там описаны требования (другие пакеты) необходимые устанавливаемой программе.
            • +1
              Простейший пример: для корректной работы пакет X, требуется пакет Y с версией старше 3.5.1, а у вас только 3.2.1.
              При использовании make install'a даже с префиксом в /usr/local от этой проблемы убежать достаточно сложно и ресурсозатратно.
              В конце концов лучше день потерять, за то потом за 5 минут долететь, чем сейчас за полсекунды отделаться, а потом неизвестно сколько расхлёбывать.
              • +1
                для корректной работы пакет X, требуется пакет Y с версией старше 3.5.1, а у вас только 3.2.1.
                Как раз на это будет ругаться configure.
      • +3
        Хинт:
        Можно иметь собранными и установленными несколько разных версий одной и той же программы.

        Никто не спорит с тем что пакетный менеджер это круто.

        Вызывают удивления части статьи про то, что якобы процесс установки контролировать практически невозможно. Не говоря уже о том, что за 10 лет работы с юникс системами я не видел ни одного исходника где не было бы правила make uninistal или make clean или make distclean

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

        • +2
          Вызывают удивления части статьи про то, что якобы процесс установки контролировать практически невозможно.
          Покажите место, где написано, что «процесс невозможно контролировать». И не стоит забывать, что Makefile не обязательно должен быть сгенерирован automake+autoconf, особенно если код не на C/C++. Внутри может вообще использоваться другая система сборки, а Makefile сделан для унификации внешнего интерфейса.

          Но, настаиваю, большинство проблем описанных в статье вызваны неумением пользоваться инструментом.
          Суть в том, что про эти проблемы надо знать. О них ведь нигде не пишут, а предлагают тупо скопипастить ./configure && make && make install, что и делает читающий статью, ведь она на хабре и ей понаставлено так много плюсов. И вот что делать человеку, когда проблемы таки вылезают? А вот если в статье вместо make install напишут checkinstall, это само по себе избавит от них воспользовавшегося инструкцией.
        • 0
          Можно иметь собранными и установленными несколько разных версий одной и той же программы.

          Вам никто не мешает собрать пакеты для разных версий одной и той же программы и одновременно их установить и наслаждаться всеми прелестями пакетного менеджмента.
          • 0
            Конечно. Я нисколько не спорю с тем что пакетный менеджер должен использоваться в первую очередь. Ведь именно для того чтобы автоматизировать рутину его и придумали. Это бесспорно.

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

            НЕВЕРНЫЙ. И говорит лишь о том, что у автора нет достаточного опыта в работе с исходниками.

            • +4
              И говорит лишь о том, что у автора нет достаточного опыта в работе с исходниками.
              Я рад, что вы живёте в идеальном мире, но у автора есть опыт работы с Makefile, в которых не было правила uninstall и с фактом затирания конфигурационных файл. И то и другое весьма неприятно и вылезает далеко не сразу.
              • –3
                Пожалуйста, приведите пример Makefile без uninstall
                • +2
                  Первое, что попалось под руку — THC-HYDRA. Самое забавное, что для gtk-шного гуя к ней правило uninstall есть.
                • +2
                  Тээээкс. Либа polarssl так же поставляется с Makefile без этого правила. Продолжать? Давайте, скажите, что у меня неправильный софт с неправильными Makefile.
        • 0
          некоторые пакетные менеджеры (portage) умеют держать одновременно установленными несколько версий. К apt, это, правда, не относится: в убунте даже разные пакеты одновременно иногда невозможно установить
          • 0
            они же оба «provides: imap-server». конечно, apt будет сносить один и ставить другой. а сделано затем, чтобы они один и тот же порт не делили непонятно как.
            • 0
              А почему тогда dropbear при установке рядом с openssh-server спокойно слушает другой порт (разумеется, предупреждая об этом, и указывая, где это можно отключить)?
              • 0
                да, действительно
                у них помимо provides: imap-server есть ещё conflicts: imap-server
  • +5
    Кто бы ещё сорвал покровы с пакета autotools.
    • 0
      этого человека зовут Чеусов, и он уже неоднократно это делал на LVEE и не только
  • +2
    Мне кажется, автор немного передёргивает. Просто всё надо делать с умом.
    • 0
      И передергивать тоже.
  • +1
    картинка с котятами просится быть напечатанной и повешенной над столом
  • –5
    Почему сразу DEB? Можно было и про RPМ написать…
  • 0
    Пока не видел ни одной нужной мне программы с отсутствующим make uninstall. Да и раз на то пошло, вы не сказали как будет вести себя checkinstall если вдруг какой-нибудь конфигурационный файл изменится или если программа создаёт какие-то свои базы данных с каким-нибудь кэшем, формат которых может меняться от версии к версии.
    У каждого пакета могут быть свои уникальные правила, по которым его необходимо обновлять, и если вы считаете что checkinstall — панацея, то вы ошибаетесь.
    • +1
      Пока не видел ни одной нужной мне программы с отсутствующим make uninstall.
      Да, давайте займём позицию страуса.
      вы не сказали как будет вести себя checkinstall если вдруг какой-нибудь конфигурационный файл изменится
      Оно включает всё, что в /etc в список конфигов, после чего вопрос о замене файлов будет задавать пакетный менеджер.
      и если вы считаете что checkinstall — панацея
      Панецея — это такая штука, которой не может быть в общем случае по определению. checkinstall же позволяет отработать 99% стучаев софта, ставящегося по ./configure && make && make install.
    • +2
      вам везло. Я встречал. И встречал такие, у которых установка DESTDIR не помогает. Приходится патчить мейкфайлы, исходники и т. п.
  • 0
    К ТС: судя по всему вы о опции --prefix не читали и о назначении директорий /opt и /usr/local понятия не имеете. Лучше сначала разберитесь толково в архитектуре POSIX-совместимых ОС, а потом уже советуйте.
    К читателям: почитайте «Введение в POSIX'ивизм.»© Алексей Федорчук, 2005 — там эта тема правильно и красиво расписана в Главе 10.
    • +1
      судя по всему вы о опции --prefix не читали и о назначении директорий /opt и /usr/local понятия не имеете.
      А вы заметку по-диагонали читали, видимо. Хотя, можете плодить кучу неподконтрольного пакетному менеджеру хлама где угодно, это ваше право.
      • 0
        А допустим если ты разрабатываешь какой-то программный продукт. По твоему мнению, надо собирать каждый билд в пакетики а потом их уже тестировать на машине?

        Что мешает пользователю с прямой рукой удалять все файлы через make uninstall, сохранив перед этим конфиги?

        Алсо, не каждый пользователь знает как собирать пакеты, а если мейнтейнер уснул на несколько лет и забил на пакет X, то ему думаю быстрее всего скачать сорсы с сайта и сделать make install.
        • 0
          А допустим если ты разрабатываешь какой-то программный продукт.
          Если я разрабатываю продукт, то я чётко знаю, что, куда и зачем он ставит. Чего не могу сказать о свежескачанных сырцах из интернета.
          быстрее всего скачать сорсы с сайта и сделать make install
          При написании checkinstall вместо make install количество нажатых клавиш не меняется, а пакетный менеджер узнаёт о софтине и она переходит под его управление.
      • +2
        Спасибо за минус в карму. Подавитесь. Толковую литературу читать вы тоже не собираетесь — отлично. А с какого перепугу вы решили, что то, что не контролирует пакетный менеджер — хлам? Каждый пользователь сам в ответе за свои действия, если он не понимает как работает make и что такое Makefile — это его проблемы. К тому-же ваши «советы» применимы только к deb-based бистрибутивам. То есть вы даете «подоконные» советы — вы рассказываете готовый рецепт о том как нужно делать в данном конкретном случае, применимом к нескольким дистрибутивам, вместо того, чтобы познакомить новичков с основами и прояснить им суть сборки пакетов из исходников.
        Раз: директория /opt предназначена как раз для самосборных сложных програм, тоесть создаем там, например, /opt/kde и делаем make install --prefix=/opt/kde, после чего получаем собранный, работоспособный, большой пакет, который в случае чего можно без проблем удалить.
        Два: /usr/local — аналог / для маленького самосбора, который можно без проблем повычищать руками из поддиректорий.
        Три: предложенный вами вариант неплох, но он не всегда удобен и работает далеко не везде.
        • +2
          Спасибо за минус в карму. Подавитесь
          Эм. Вы меня с кем-то спутали. Я минусов в карму за мнение, отличающееся от моего никогда не ставлю. Как писал Вольтер, «мне ненавистны ваши убеждения, но я готов отдать жизнь за ваше право их высказывать».
          если он не понимает как работает make и что такое Makefile — это его проблемы.
          Это не повод создавать проблемы тем, кому адресуется статья про установку %softwarename% на %distroname%.
          К тому-же ваши «советы» применимы только к deb-based бистрибутивам.
          Они применимы ко всему, что использует бинарные пакеты.
          Раз: директория /opt предназначена как раз для самосборных сложных програм, тоесть создаем там, например, /opt/kde и делаем make install --prefix=/opt/kde, после чего получаем собранный, работоспособный, большой пакет, который в случае чего можно без проблем удалить.
          Я уже, кажется, писал, что софтина может ожидать того, что там, куда её ставят, её увидит кто-то ещё. Даже пример с /usr/share/xsessions привёл. Иногда установщики могут что-то в /etc/modprobe.d добавлять.
          Два: /usr/local — аналог / для маленького самосбора, который можно без проблем повычищать руками из поддиректорий.
          Вы сейчас призываете к тому, что противоречит самой идее, ради которой создавались ЭВМ — автоматизировать всё то, что можно автоматизировать.

          • +1
            Я понял вашу точку зрения. Я просто любитель более общего подхода, когда люди сначала изучают основы, а в частностях после этого разобраться не проблема. Ни в коем случае не против автоматизации, просто я считаю, что перед тем как автоматизировать нужно знать как это делается руками, как это устроено и как это вообще работает. Простите за наезд.
  • +4
    [sarcasm]Судомейкинсталлил, судомейкинсталлю, и буду судомейкинсталлить. Не переубедите...[/sarcasm]
  • 0
    в чем принципиальная разница c aptitude install?
    • +1
      Собирается из исходников.
      • 0
        спасибо
  • +5
    А что мешает устанавливать с помощью

    ./configure --prefix=/home/%username%/
    make install
    • 0
      Да, на самом деле — я, к примеру, все, что не устанавливается автоматически apt-get-ом, спокойно ставлю в /opt/product_name-version/ и все. Потом это сносится простым удалением каталога.

      Понятно, что голый «make install» бесконтрольно замусоривает систему. Об этом просто нужно знать (ну, обучать там), а если всех расстреливать за незнание — люди быстро кончатся :)
      • 0
        Я тоже так когда-то делал. Перестал после того как убил 4 часа на выяснение того, почему wimaxd отказывается нормально работать. Выяснилось, что install кладёт файлик в /etc/modprobe.d, который из-за установки в префикс куда надо не попал.
      • 0
        > Понятно, что голый «make install» бесконтрольно замусоривает систему.

        Кому понятно? Почему замусоривает? Чем замусоривает? Статья с комментами — куча каких-то невнятных обобщений.

        Есть софт с хреново прописанными скриптами сборки и целями установки. Пользуюсь парой программ, собираемых CMake, у которых нет целей uninstall в принципе. Меня лично это не особо колышет, потоиу что они а) в /opt и б) я давным-давно выяснил, что и куда они пишут. Остальные почти всего устанавливаются и удаляются корректно.

        Половина софта для музыкантов сейчас собирается вообще через waf. Чекинсталл уже научился его питонский скрипт читать?
        • 0
          > почти всего

          почти всегда :)
        • 0
          Например, я собираю программу из исходников, запускаю дефолтный «make install», и он записывает часть файлов в /etc, часть в /usr/local/lib, часть в /var, часть еще фиг знает куда.

          Я мог-бы запустить «make uninstall», но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки. Так что корректно де-инсталлировать уже ничего нельзя.

          Поэтому, как автор статьи и написал, нужно ставить софт из стандартных репозиториев, которые отслеживают зависимости и корректно обновляют пакеты.
          Или, если стандартный репозиторий не подходит, ставить в выделенный каталог в /opt, чтобы удалять простым одним движением — точно как вы написали :-)

          Так что статья вполне имеет право на жизнь, в качестве ликбеза.
          • 0
            > но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки

            Зачем? :)

            > Так что корректно де-инсталлировать уже ничего нельзя.

            Это называется ССЗБ :)

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

            В идеале — да. Но на практике это не всегда возможно.

            > Так что статья вполне имеет право на жизнь, в качестве ликбеза.

            Это само собой. Мне просто совершенно непонятны эмоции, которыми это сопровождается :)
            • 0
              >> но в 99% случаев исходники вместе со всеми временными файлами удаляются после сборки

              > Зачем? :)

              Так они дикое место занимают, как правило. К тому же это нелогично — оставлять кучу временных файлов и исходников ради отдного скрипта деинсталляции.

              >> Так что корректно де-инсталлировать уже ничего нельзя.

              > Это называется ССЗБ :)

              ИМХО, это недостаток дизайна инструмента сборки. Я бы даже сказал, что это из области usability. Но все эти инструменты были созданы очень давно, когда требования очень сильно отличались от нынешних. Вообще automake сильно отстал от жизни. Каждый раз об этом задумываюсь, когда запускаю ./configure в Apache и час или больше жду его завершения на каком-нибудь AIX-e или HP-UX-e, потому-что он тупо повторяет одни и те же тесты для каждой из библиотек.
              • 0
                > Так они дикое место занимают, как правило.

                Мы говорим о десктопе или о сервере?

                > К тому же это нелогично — оставлять кучу временных файлов…

                От make clean ещё никто не умирал :)

                > ИМХО, это недостаток дизайна инструмента сборки. Я бы даже сказал, что это из области usability.

                А вот здесь соглашусь. Я бы хотел видеть более простые и надёжные инструменты сборки.
  • 0
    mkdir DEBIAN
    find etc|sed "s/^/\//"|DEBIAN/conffiles


    Эм, а почему debian заглавными буквами? Да и второе «|», пожалуй, стоит заменить на «>»;.
    • 0
      Эм, а почему debian заглавными буквами?

      -b, --build directory [archive|directory]
                    Creates  a  debian  archive from the filesystem tree stored in directory. directory must have a DEBIAN subdirectory, which contains the control information
                    files such as the control file itself. This directory will not appear in the binary package's filesystem archive, but instead the files in it will  be  put
      
      • +1
        Спасибо. Для тех, кто также как и я удивился, поясню: в debian/ лежат source package control files, а в DEBIAN/ — binary package control files.
        • 0
          Точнее в «debian/» лежат ресурсы для файлов
          а в в «DEBIAN/» лежат бинарные файлы
          • 0
            Эм. А чем это отличается от того, что написано выше?
            • +1
              Тем, что BVN2 под какими-то веществами судя по тому, что он в треде пишет.
  • +3
    FreeBSDшники вздохнули.
    • +1
      О чём вздохнули то? У нас portupgrade один раз собирается и особых проблем при обновлении нет :)
      Да и фряхой, как рабочей машинкой пользуются единицы, так что увязнуть в софте — почти не реально, ИМХО.
      • 0
        Ну, наверное, имелось в виду, что многие пользователи FreeBSD ставят софт примерно так:

        cd /usr/ports/category/portname
        make config
        make install clean

        Так аутентичней, что ли.

        Ну так вот, я при прочтении заголовка немного напрягся. :)
  • 0
    И ещё драйверы на видео ставят из *.run файлов, скачанных с официальных сайтов производителей… (((
    • 0
      Так с драйверами, по крайней мере в дебианах, все совсем шоколадно и даже что-то качать, а потом еще и собирать самому ничего не надо.
      Все делается само в 1 команду (первые 2 делаются лишь в самый первый раз, так что не в счет). Например с нвидиа это выглядит так:
      aptitude install module-assistant
      m-a prepare
      m-a a-i nvidia-kernel

      Правда сейчас понабежит толпа народу, у которых еще за неделю до релиза драйвер уже считается морально устаревшим и ждать, пока он появится в дистрибутиве совсем нету времени. Но тут уж каждый сам выбирает, шашечки или ехать (:
  • –2
    Спасибо за статью, она отлично мне подойдет, чтобы отпугивать от линуха незадачливых перебежчиков, которые думают, что make install — это все, что им может потребоваться для инсталляции.
    • +1
      Для инсталляции перебежчику в 99% случаев достаточно написать что-то типа «sudo apt-get install super-duper-software», а то и вовсе сделать пару кликов мышкой в гуе.
      • –2
        хм, нет. Юзеры обычно хотят свежий, недавно вышедший софт, а не его проверенную десятилетиями и поколениями бородатых одминов версию.
        Менеджеры пакетов зачастую не готовы предоставить последние версии многих продуктов. Размеры проблемы зависят от дистрибутива, тем не менее, проблема присутствует даже в убунте с федорой.
        И да, как правило, каждому хотя бы один раз требуется что-то из этого 1%.
        • 0
          > Юзеры обычно хотят свежий, недавно вышедший софт, а не его проверенную десятилетиями и поколениями бородатых одминов версию.

          Пусть ставят Gentoo, размаскировывают ~x86/~amd64 и радуются :)

          А вообще, непонятно такое желание юзеров, разве недостаточно того, что пакеты достаточно свежие, хоть и не самые свежие?
        • 0
          В убунте всё, чего нет в основном дистре, есть в ppa-шках.
    • +1
      не понимаю, чем для юзеров make install отличается от checkinstall

      что одно — тайная магия в форме иероглифов, что другое
  • –13
    Спасибо за развёрнутую статью. Но есть как минимум две проблемы. Большинство не в курсе на какие темы вы давали комментарии и что в них написано. И ещё большинство людей не в курсе что такое «make install».

    Если и используете какие-то английские слова (что безумно позорно для русского человека), то постарайтесь их объяснить (а лучше вообще заменить) в самом начале публикации.
    • +5
      На Хабрахабре большинство людей знает что такое «make install». Это IT-ресурс все-таки.
      • 0
        ага, а ещё я знаю что в цели install: может быть всё что угодно написано.
        Например добавление строк в какой нибудь конфиг файл.
        • 0
          только массовые расстрелы спасут систему от таких мейкфайлов
    • –5
      Не расстраивайтесь, так принято, написать много умных слов, не объяснив их смысл, так круче выглядит.
      Кто уже всё знает и так поймёт и + поставит, ибо коррелятор в мозгу сработал, а кто не знает, пройдёт подавленный «интеллектом» автора мимо.
      • +2
        Эм. Если человек не знает, что такое make install, то эта статья адресована вообще не ему, так что можно спокойно проходить мимо.
      • +3
        Да что Вы пристали к троллю человеку. У него у самого пост с кучей каких-то непонятных предложений на английском, половина из которых начинается с SELECT. И хоть бы где объяснил, что это такое, я уж не говорю про замену. Большинство ж людей не в курсе (:
      • +4
        Почему desenix может писать комментарии, а срать ему в карму нельзя?
    • 0
      Очень интересно вы говорите от имени большинства. При том, что большинство заминусовало ваш единственный пост.

      Что такое «make» можно нагуглить за полминуты. Первая ссылка.
  • +2
    Для юзеров-гентушников есть emerge <пакет> и emerge --unmerge <пакет>. Собирает из исходников, пользуясь общим /etc/make.conf с флагами компиляции и т.д., где можно соптимайзить софт под ваши задачи и оборудование. А если софта нету в portage, можно сделать свой ebuild. Пакеты маскируются/демаскируются по желанию.
  • +1
    А сборка checkinstall через make install сильно портит карму?
    • 0
      Очень, очень сильно портит, поскольку make install ничего не собирает и сборка с его помощью есть из области чёрной магии.

      На самом деле у правила install есть в зависимостях правило, по которому производится сборка
  • +31
    Все против меня((((
  • 0
    Хм… На сервере установлен php 5.2, мне нужно установить 5.3, но 5.2 не должен быть удален! Как быть? :)
    • –5
      Если вам нужно ставить два языка на один и тот же сервер — то это фантазии. С таким же успехом можно пытаться тратить деньги и при чём, что бы они сохранялись.

      Если нужно на одну и туже машину поставить php двух версий, то ставьте ещё один апач (или какой-либо другой сервер) и цепляйте к нему php 5.2.
      • –2
        Извиняюсь
        — не два языка, а две ПХП'шки
        — … и цепляйте к нему php 5.3
      • 0
        Молодой человек, большинство шаред хостингов могут вам предоставить на одним и том же сервере php 5.2 и 5.3 одновременно.

        Более того, при желании сюда можно воткнуть еще и пых четвертой ветки, для особых извращений.
    • 0
      Выставить префиксом /opt/newphp, далее по инструкции. После чего сами разбираетесь с тем, как и куда его прописать, чтобы веб-сервер увидел.
      • 0
        А почему не /usr/local
        ведь папка пустая же в большинстве дистрибутивов,
        но в отличии от /opt/newphp/bin/ /usr/local/bin уже есть в переменной path
        • 0
          И какой из бинарников будет запускаться из консоли? Нет уж, мухи отдельно, котлеты отдельно.
          • 0
            тот, к которому пропишите полный путь :) Не поддерживаю /usr/local идею, просто мимо проходил.
    • 0
      В Gentoo можно использовать слоты и переключаться между версиями при необходимости.

      Удобно бывает.
    • 0
      ставьте gentoo, там можно так сделать
  • 0
    dh_make?
  • 0
    А не вы ли в недавнем посте писали об этом в комментариях? :) Вспомнилось просто.
  • 0
    Отправите статью еще в редакцию LXF. Авторы постоянно рекомендуют устанавливать новые программы из исходников через make install. Я сам, перед тем как устанавливать пакеты из исходников, ищу на лаутчпаде.
  • –3
    Эти чекинсталлы, fakeroot (да и сам make install — пакет не должен сам себя устанавливать) — это костыли, которыми пытаются подпереть изначально кривую архитектуру. Каждое приложение должно находиться в своей папке, а устанавливаться/удаляться созданием симлинка в /bin.
    • 0
      Специально для Вас есть GoboLinux.
      • –2
        это слишком кардинальное решение, не отменяющее кривой подход современых Linux дистрибов.
        Тысячи папок, везде что-то лежит, столько мусора в голове не удержу, необходимо место и для полезной информации.
    • 0
      Ага, а ещё должно быть что-то типа GAC, но для so-шек. Давайте пропатчим загрузчик с компилятором и сделаем свой, принципиально новый дистрибутив.
    • 0
      как же быть с приложением calc.exe? Что же оно не в своей папке?

      или это не приложение?
      • 0
        А что мешает положить его в отдельную папку? Экономия на спичках?
  • 0
    Опечатка, я полагаю: «dpkb -b tempintall»
  • –1
    Вредный совет.
    Если принять стандарт, обязывающий весь пакет с его содержимым (деревом подпапок, ибо могут быть права разные) держать в одной папке /opt/пакет
    А в нужные места разбрасывать симлинки, то и голова за это болеть не будет, надо удалить пакет, удалил папку, а дохлые симлинки потом удали сборщиком мусора.
  • +1
    Лёгким движением make install превращаем нормальный дистрибутив в Slackware. ;)
    • 0
      Вы либо никогда не пользовались, либо просто не разбирались в Slackware. Вы не поверите, но там есть пакетный менеджер, который позволяет потом при удалении вычистить все установленные с пакетом файлы. makepkg и написание SlackBuild-ов никто не отменял.
      • 0
        Вы не поверите. Но я знаю про пакетные менеджеры в Slackware. Я вам даже по секрету скажу, что их там больше, чем один. И SlackBuild'ы для сборки пакетов я тоже писал. А ещё для Slackware есть репозитории с уже собранными пакетами, а также небезысвестный slackbuilds.org/ с множеством уже готовых слакбилдов под разные версии Slackware. Обвинить в некомпетентности человека это самое простое, а вот увидеть шутку наверное дано не всем.
        • 0
          Да ладно, не серчайте. И про репы и про остальные пакетные менеджеры я тоже знаю. Слака была моим первым дистром. На slackbuilds.org даже мной присланные слакбилды когда-то были. И про то что это была шутка я тоже знаю. Но эту шутку лично я считаю глупой. Я просто не ожидал что такую вот «шутку» может выдать человек, который, что называется, «в теме».
          • 0
            Ну есть же распространённое мнение о том, что файлопомойка в слаке начинается с /
          • 0
            Слака тоже была моим первым дистрибутивом, на ней в принципе и учился. А шутка направлена на тех кто «не осилил» слаку. Самоирония практически. =)
  • 0
    Слова, конечно, очевидные. Но, к сожалению, не всегда получается обойтись только менеджером пакетов, а собирать из тарбола пакет для своего дистрибутива — задача довольно муторная.
    У самого на работе предостаточно всякой всячины из тарболов (модули ядра для «нестандартных» железяк), кое-какие библиотеки…
    • 0
      deb-пакет по инструкции в статье собирается из дерева файлов примерно за полторы минуты, включая копирование шаблона, правку полей описания и саму установку. Арчевские пакеты, судя по комментариям, и того быстрее. Не надо оправдывать свою лень, а?
      • 0
        Арч у меня дома, там у меня пока чистота и порядок (в aur достаточно много необходимого, а редкое железо я дома не держу). На работе же мандрива и собирать rpm'ы просто лень.
  • +1
    я еще бы посоветовал бы так сначала
    sudo auto-apt update && auto-apt -y run ./configure
    


    Команда auto-apt автоматом будет доставлять пакеты с необходимыми файлами, всякие там заголовочные файлы .h подробнее 5.3 Установка пакетов «по запросу»
    Этот шаг позволит автоматически удовлетворить зависимости компилируемой программы и меньше будете пытать людей на форумах, типа чего надобно программе на слове stdio.h NOT FOUND

    потом
    checkinstall -D
    
    • 0
      Этот шаг позволит автоматически удовлетворить зависимости компилируемой программы и меньше будете пытать людей на форумах, типа чего надобно программе на слове stdio.h NOT
      Я обычно иду на packages.ubuntu.com и ищу там. Как будет разруливать проблемы с повторяющимися именами заголовочных файлов сия утилита — не знаю, вручную как-то надёжнее.
    • 0
      за auto-apt большое спасибо. не знал.
  • –1
    А почему в статье говорится только про checkinstall и сборку deb-пакета, и ВООБЩЕ никак не упоминается, что это не единственные существующие в мире форматы пакетов и способы установки софта?

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