Хочеться взяти і розстріляти, або лікнеп про те, чому не варто використовувати make install - linux
Хочеться взяти і розстріляти, або лікнеп про те, чому не варто використовувати make install
Суть зводиться до того, що цю команду у вигляді «make install» або «sudo make install» використовувати в сучасних дистрибутивах не можна.
Ліричний відступ
Як відомо, для нормальної роботи більшість софта повинно бути не тільки скомпільовано, але і правильно встановлено в системі. Програми очікують знайти потрібні їм файли в певних місцях, і місця ці в більшості * nix-систем захисту в код на етапі компіляції. Крім цього аспекту основною відмінністю процесу установки в linux / freebsd / whatever від такої в Windows і MacOS є те, що програма не просто складає купу файлів в окрему директорію в Program Files або / Applications, а «розмазує» себе по всій файлової системи. Бібліотеки йдуть в lib, виконувані файли в bin, конфіги в etc, різного роду дані в var і так далі. Якщо вам раптом знадобиться її оновити, то все це треба спочатку якось вичистити, т. К. При використанні нової версії залишки файлів від старої можуть привести до абсолютно непередбачуваних наслідків. часто поганим. Імовірність цієї події не так велика, але воно вам треба на бойовому сервері?
І що з того?
Так ось, якщо ви робили установку безпосередньо через make install, то нормально видалити або оновити софтину ви, швидше за все, не зможете. Більш того, установка нової версії поверх старої, швидше за все, затрёт ваші зміни в конфігах. make install робить рівно те, що йому сказано - виробляє установку файлів в потрібні місця, ігноруючи той факт, що там щось уже є. Після цього процесу абсолютно ніякої інформації про те, що і куди ставилося, отримати в легкотравному вигляді неможливо. Іноді, звичайно, Makefile підтримує дію uninstall, але це зустрічається не так часто, та й не факт, що коректно працює. Крім цього зберігати для деінсталяції розпаковане дерево початкових кодів та правил складання якось дивно.
Як боротися?
Оскільки в дистрибутивах пакети мають властивість іноді все-таки оновлюватися, для вирішення цієї проблеми придумали таку штуку як пакетний менеджер. При його використанні установка відбувається приблизно так:
- береться певним чином сформований архів
- з нього витягується інформація про те, що це взагалі таке, якої версії, від чого залежить, з чим конфліктує, чи треба для установки / видалення / встановлення запускати якісь скрипти, etc
- Виконуються дії по безпосередньої установки
- Всі дані про те, куди і що було поставлено додаються в базу даних пакетного менеджера.
В цьому випадку при оновленні можна безболісно поудалять зайве, а заодно подивитися, залишилися незмінними чи в системі файли, відмічені як конфігураційні і запитати, що робити, якщо в новій версії їх вміст відрізняється. Крім цього, пакетний менеджер не дасть затерти файли одного пакета при установці іншого. Загалом, багато корисних штук він може зробити.
Якщо ви через незнання / ліні скопіпастілі make install з інструкції, то в системі з'являються файли, про які пакетний менеджер не знає. З усіма наслідками, що випливають, якщо вам мало того, що було перераховано раніше.
Що робити?
Так що треба збирати пакет.
У мене немає часу, щоб *** ться з цим, краще ще раз зроблю make install, все просто і зрозуміло!
Спокійно, спокійно. Він у нас за ноги прив'язаний. Все не так вже й страшно і складно, як здається на перший погляд.
checkinstall
Дана чудова утиліта, будучи запущеною замість make install задасть кілька запитань, після чого сама збере і встановить пакет. Все, при оновленні ніяких проблем з вичищення старого мотлоху у вас не буде.
Збірка deb-пакету вручну
Якщо ви не схильні довіряти такій автоматики (яка іноді все ж косячіт) або ж хочеться внести пару змін, але розбиратися з нормальним процесом складання пакетів все ж ліниво, то можна зібрати пакет ручками. Я привожу спосіб, як спорудити його для систем на базі Debian, т. К. Найкраще знаком саме з ними. Він не є ідеологічно правильним, але на виході виходить цілком коректний пакет без задіяння додаткових сутностей. Робиться це в такий спосіб.
Для початку збираємо софт з попередньо зазначеними для configure або autogen.sh параметрами --prefix = / usr і --exec-prefix = / usr.
Далі виробляємо установку в тимчасову директорію. пишемо:
Після чого отримуємо в свіжостворений директорії весь той набір файлів файлів. До речі, ми зараз перебуваємо в fakeroot-оточенні, т. Е. Можна безперешкодно міняти власника і права доступу файлів, але фізично в системі власником залишитеся ви самі. Софт ж всередині fakeroot-сесії буде отримувати змінену інформацію, що дозволить упакувати в архів файли з коректними правами.
Далі створимо в «корені пакету» директорію DEBIAN і складемо в DEBIAN / conffiles список всіх файлів, які повинні потрапити в / etc:
Після чого створюємо файл DEBIAN / control такого змісту:
При необхідності там же можна створити скрипти preinst, postinst, prerm і postrm.
Все, робимо dpkb -b tempintall і отримуємо на виході tempinstall.deb, на який можна нацькувати dpkg -i і який коректно встановиться, оновиться або віддалиться.
«Правильний» процес з попереднім створенням пакета вихідного коду виходить за рамки даної замітки, а тому описаний не буде, але для ваших цілей воно зазвичай і не потрібно.
висновок
Як бачите, тут немає абсолютно нічого складного, але виконання цих дій позбавить вас від величезного числа проблем в майбутньому.