 |
от Hapkoc(29-03-2006)
рейтинг (29)
[  добре ]
[  зле ]
 Вариант за отпечатване
Лиценз: CC Attribution-ShareAlike
0. Някои пояснения
* терминът пакет се използва в смисъл на файл или съвкупност от файлове, служещи за инсталиране на дадено приложение;
* символът # (диез) в примерите означава две неща:
1) когато е в началото на командния ред, означава, че командата трябва да се изпълни с права на root. Самият символ # не се въвежда от потребителя;
2) когато не е в началото на реда, означава, че текста до края на реда е коментар и принципно няма нужда да се въвежда от клавиатурата, нито текста, който е след самия символ;
* символът $ (долар) обозначава, че командата, която следва се изпълнява с права на нормален потребител на системата (разбирай не-root). Самият символ също така не се въвежда. В различните дистрибуции този символ може да се различава, а също така преди него да има допълнителен текст (например потребителското име
и текущата директория);
* нотацията 'command [options]' в командния ред обозначава незадължителен/и параметър/и за командата 'command', т.е. "[options]" трябва да се замени с празен низ или поредица от валидни параметри на съответната команда;
* ВАЖНО: за успешна работа с описаните средства се препоръчва четенето на официалната документация на съответните команди/програми/системи/etc.
1. Повод за статията и какво представлява
Поводът за тази статия е огромния брой въпроси, възникващи у начинаещите потребители, относно това как се инсталира софтуер в операционната система Linux. Статията е насочена именно към начинаещите потребители на Linux дистрибуции.
Статията не е ръководство за използване на конкретен пакетен мениджър и няма за цел да обхване цялото многообразие от такива в различните дистрибуции. Въпреки това в статията ще дам примери с пакетния мениджър на Debian GNU/Linux dpkg и инструмента APT, т.к. това е което използвам най-активно.
2. Въведение
Начините за инсталиране на софтуер в Linux са много и в по-голямата си част зависят от дистрибуцията, която се използва. Тук бих искал да отбележа един основен момент - почти всяка дистрибуция предлага инструменти за менажиране на пакети (пакетен мениджър). Културния начин за инсталиране/деинсталиране и прочие менажиране на софтуера в една система е именно посредством използването на пакетния мениджър на системата.
А защо именно това е така? Много просто - за улеснение. Функцията на пакетния мениджър е именно да менажира пакетите, инсталирани на системата.
3. Инсталиране на софтуер от изходен код
Това е мисля най-универсалния начин за инсталиране на софтуер, т.к. е необходимо единствено да имаме инсталиран компилатор за езика, на който е написано приложението, което искате да инсталирате.
При инсталиране от изходен код има няколко неща, които е добре да се знаят.
* В дървото с изходен код на всяко приложение би следвало да присъстват файловете INSTALL и README. Задължително четете тези файлове винаги при наличието им.
В INSTALL файла обикновено има инструкции за инсталиране на съответното приложение. В повечето случаи инструкциите са унифицирани и ще бъдат описани накратко тук. В някои случаи в INSTALL файла има специфични за даденото приложение инструкции, които е добре да се прочетат, за да бъдат избегнати по-нататъшни проблеми.
В README има обща информация за приложението, но в много случаи именно там са описани особеностите при инсталацията.
В общия случай е добре най-малкото да се прегледат и двата файла.
* Инсталирайте от изходен код само в краен случай.
Под краен случай тук разбирам две неща:
1) когато няма готов пакет за вашата дистрибуция;
2) когато готовите пакети за вашата дистрибуция не предлагат функционалността, която ви е необходима.
Защо трябва да се инсталира от изходен код само в краен случай? Защото в дългосрочен план този ход ще ви донесе мир и спокойствие. :-)
3.1. Обща процедура за инсталиране на софтуер от изходен код
Тук ще приемем, че искаме да инсталираме приложение наречено program-x. Процедурата по инсталиране на приложението е горе-долу следната:
* изтегляне на изходния код - обикновено той е във .tar.gz или .tar.bz2 архив. В нашия случай подходящо име за архива би било program-x_0.1.3.tar.gz. Изтегляме архива в подходяща директория (например /tmp).
* разархивиране. В случая с нашия пример това ще стане със следната команда:
| Примерен код |
$ cd /tmp
$ tar zxf program-x_0.1.3.tar.gz |
След тази стъпка обикновено получаваме директория, която носи името на архива без .tar.gz разширението. В случая program-x_0.1.3.
* конфигуриране на приложението:
| Примерен код |
$ cd program-x_0.1.3
$ ./configure [options] |
С командата:
| Примерен код |
$ ./configure --help |
можем да прегледаме различните опции, които можем да подаден на скрипта configure.
Има някои опции, които могат да се подадат на configure скрипта и са общи за всички приложения. Основна опция е --prefix - чрез нея се задава къде да се инсталира приложението. Например:
| Примерен код |
$ ./configure --prefix=/usr/local |
ще инсталира приложението в /usr/local (това значи, че изпълнимите файлове на приложението ще бъдат поставени в /usr/local/bin, библиотеките в /usr/local/lib, и т.н.).
По подразбиране повечето приложения, се инсталират в /usr/local. По този начин се получава разделение между приложенията инсталирани от изходен код и приложенията инсталирани със средствата на дистрибуцията (които се инсталират в общия случай в /usr).
* компилиране на приложението:
* инсталиране:
Забележете, че промпта при последната команда е #, а не $, което идва да подскаже, че командата трябва да се изпълни с права на root. Трябва да се отбележи, че това не е 100% вярно, т.к. всеки потребител може да инсталира приложения в своята домашна директория. За целта трябва да се подаде опция --prefix=$HOME/local на configure скрипта, ако приемем, че искаме да инсталираме приложението в $HOME/local ($HOME е домашната директория на потребителя).
4. Проблеми на подхода с инсталиране от изходен код
Дотук видяхме какви стъпки са необходими за да се инсталира дадено приложение от изходен код. Сега да видим какви проблеми могат да възникнат при инсталиране на софтуер по гореописания начин.
4.1. Зависимости
В съвременните софтуерни системи само най-простите приложения не зависят от външни за тях библиотеки (най-общо казано). При инсталиране от изходен код могат да се получат доста засукани проблеми със зависимостите, които трябва да се решават ръчно. Това значи (ако приемем, че ще инсталираме всички зависимости от изходен код) да изтеглим архивите с изходен код на всички приложения/библиотеки, от които зависи инсталираното от нас приложение и да приложим процедурата за всяко от тях.
4.2. Деинсталиране на софтуер
Ако имаме приложение инсталирано от изходен код и искаме да го деинсталираме най-лесния вариант е от директорията с кода на приложението да пуснем:
Тук обаче има следния проблем - може да сме затрили същата тази директория. В такъв случай можем наново да разархивираме кода на приложението и от новополучената директория да пуснем:
| Примерен код |
$ ./configure [options]
|
Да, но ако сме инсталирали приложението с --prefix=/niakude/po/failovata/sistema, първо ще трябва да си спомним къде точно сме го инсталирали и да подадем съответния --prefix на configure. А какво става ако сме затрили и архива с изходния код? Ами отиваме и го дърпаме наново.
Всички тези проблеми разбира се могат да се решат, но въпроса е нужно ли за тяхното решение да се грижим ние? Не, не е. Разработчиците на различните Linux дистрибуции са помислили за нас и са ни предоставили инструменти за автоматизирано управление на софтуера за нашите системи, които инструменти решават именно тези проблеми.
4.3. Обновяване на софтуер
Ако сме инсталирали приложението от изходен код, при излизане на нова версия на дадено приложение ще трябва да повторим описаните по-горе стъпки за инсталация. Ако приложението има сравнително сложни зависимости можете да си представите колко време би отнела такава задача.
5. Инсталиране на софтуер посредством пакетен мениджър
... или как гореспоменатите проблеми се решават културно.
Статията, както вече беше уточнено, няма за цел да бъде ръководство за конкретен инструмент. За по-лесно излагане на материала е удобно да се работи с примери. Тук ще използвам за примерите пакетния мениджър на Debian GNU/Linux, а именно dpkg, както и APT, който е инструмент за управление на dpkg (неформално казано).
5.1. Инсталиране на пакет с dpkg
Инструмента dpkg работи с пакети в DEB формат. И така, ако приемем че имаме пакет, наречен program-x_0.1.3.deb, той се инсталира по следния начин:
Дори в този момент вече сме си улеснили живота, т.к. тази команда съответства на:
| Примерен код |
$ tar zxf program-x_0.1.3.tar.gz
$ cd program-x_0.1.3/
$ ./configure [options]
$ make
|
от горното описание, а да не забравяме, че ни спестява и известно количество четене на инструкции за инсталация. Тези инструкции са били прочетени от човека, поддържащ пакета и спрямо тях той е изготвил готовия .deb пакет за наше удобство.
5.2. Проблема със зависимостите
Ако изпълним:
но program-x_0.1.3.deb зависи от библиотеки, които не са инсталирани, dpkg ще изведе съобщение, че липсват съответните библиотеки и приложението не може да бъде инсталирано.
Единият вариант за решаване на проблема е да изтеглим съответните библиотеки/приложения и да ги инсталираме с dpkg, след което да изпълним отново:
Този вариант определено не ни улеснява особено, т.к. се налага ръчно да намерим и изтеглим съответните библиотеки (и то със съответните версии, които се изискват).
За целта има инструменти като APT. APT работи с хранилища за пакети. За всяко хранилище има описание на пакетите, които то съдържа. В описанието на всеки пакет има описание от кои други пакети зависи съответния пакет. APT, имайки образно казано цялостен поглед върху хранилището, може да се погрижи за зависимостите вместо нас.
За да функционира APT е нужно на локалната машина да се изтегли списък с описанията на всички пакети, които фигурират в хранилищата, с които е конфигуриран да работи APT. Това се прави по следния начин:
Тази стъпка е добре да се прави периодично, като процеса може да се автоматизира с помощта на cron например.
И така, как протича инсталацията на пакета program-x_0.1.3.deb:
Тук APT ще ви обясни, че пакетът package зависи от други пакети и ще ви предложи да инсталира пакета заедно със зависимостите му. Добре е всеки път при инсталация на пакети внимателно да се преглеждат съобщенията на APT. Един пакет може, освен да зависи от друг пакет, и да влиза в конфликт с трети. Това значи, че за да се инсталира дадения пакет, трябва предварително да се деинсталира конфликтния пакет.
5.3. Деинсталация на пакети
При употреба на пакетен мениджър, всеки инсталиран на системата пакет се регистрира от мениджъра, като по този начин се осигурява коректното премахване и обновяване на пакетите.
Деинсталацията с помощта на APT става по следния начин:
5.4. Обновяване на софтуер
Обновяването на софтуер с помощта на пакетен мениджър е тривиална (в повечето случаи) задача. При APT се свежда до следното:
По горе в статията беше коментирано как тази задача би се решила при инсталиране от изходен код.
При обновяване на системата APT изтегля последните версии на пакетите, съобразно информацията която има, и с тези версии обновява текущо инсталираните версии на пакетите. Това значи, че версиите, които ще инсталира APT при upgrade са тези, които фигурират в локалното копие на описанието на пакетите. Ако искате при upgrade да инсталирате послените версии налични в хранилищата, които ползвате, е добре преди apt-get upgrade да изпълните apt-get update.
5.5. Компилиране от изходен код с помощта на инструменти на пакетната система
Ако ви се налага да компилирате даден пакет от изходен код, т.к. бинарните пакети за вашата дистрибуция не са компилирани с поддръжка на дадена функционалност, все още можете да решите задачата с помощта на пакетния мениджър.
Повечето пакетни системи съдържат инструменти за създаване на бинарен пакет от изходен код. Създавайки такъв пакет, вие го инсталирате по стандартния за дистрибуцията начин, запазвайки всички произтичащи от това предимства. Можете да създадете собствено локално хранилище за такива пакети. Последното е особено полезно при поддръжка на повече от една машини.
5.6. Пакетни системи базирани на компилиране от изходен код
Съществуват пакетни мениджъри, които автоматизират компилирането на софтуер от изходен код. При тях към оригиналния изходен код на дадено приложение се прилагат кръпки, нанасящи промените, необходими за компилиране в обкръжението на дадената дистрибуция.
Естествено компилирането на софтуер от изходен код и последващото му инсталиране е доста по-времеемко и изисква сериозно натоварване на системата.
6. Информация за други пакетни системи и инструменти за управление на пакетите
6.1. RPM
RPM е пакетния мениджър при дистрибуциите, базирани на Fedora Core и RedHat. Пакетната система поддържа зависимости.
yum (включен в дистрибуцията Fedora) е инструмент, автоматизиращ работата с RPM пакети.
6.2. pkgtools
pkgtools е набор от инструменти за управление на пакети в Slackware и базираните на Slackware дистрибуции. Пакетната система на Slackware не поддържа зависимости в базовия си вариант.
Има няколко инструмента, които автоматизират работата със Slackware пакети - slapt-get, swaret, SlackPkg. slapt-get и swaret поддържат зависимости, по различен една от друга, но малко заобиколен начин, т.к. самата пакетна система не поддържа зависимости.
6.3. Portage
Пакетна система, базирана на компилиране от изходен код. Поддържа зависимости. Използва се в дистрибуцията Gentoo.
6.4. *BSD ports/packages/pkgsrc
Трите свободни BSD дистрибуции имат много сходни пакетни системи.
Във FreeBSD и OpenBSD пакетната система се нарича ports. Ports системата работи с изходен код. Компилирайки пакет от ports, вие създавате package (отново представляващ .tgz архив).
Трябва да се отбележи, че въпреки сходството в имената на FreeBSD ports/packages и OpenBSD ports/packages, това са две отделни пакетни системи, разработвани независимо една от друга.
В OpenBSD се предпочита инсталирането на бинарни пакети (packages), докато във FreeBSD двете възможности са по-скоро на равни начала.
pkgsrc е пакетната система на NetBSD. Чрез нея също така се създават package-и от изходен код.
И трите системи поддържат зависимости.
6.5. YaST
YaST е графичен инструмент за конфигуриране на системата в дистрибуцията SuSE, който включва и възможност за инсталиране на пакети. SuSE работи с RPM пакети.
Препоръчва се инсталирането на софтуер в тази дистрибуция да става именно през YaST.
7. Заключение
Пакетните системи са създадени за улеснение на управлението на софтуер в една дистрибуция и използването им значително улеснява тази задача. Поради това смятам, че е добра идея пакетната система да се използва по предназначение, свеждайки до минимум инсталирането на софтуер по други начини.
Приемат се всякакви критики и забележки, стига да са добре обосновани.
<< КАК ДА печатаме от Windows на CUPS принтер/опашка | SonyEricsson и Линукс >>
|
|
