Пакет
Переходим к пакетам. Это двольно забавная штука. Откуда взялся пакет. Он завёлся не от сырости, и в подавляющ. числе случаев вы не ск. с сайта прдукта, а с сайта дистр. Он случился птому, чт есть ментейнер, котрому инт. пргрю продукт, скачал его, оформил его в соотв. с полиси и положил в репозитрий. В итоге появились в репзитории две вещи --- src.rpm с исх. пргр. продуктом, патчами, дополн. картинками... и пакет с бинарниками. Пакет, который вы нашли в хранилище, адаптирван к семейству ОС, сделанных на сотв. ветке. Это озн., что люди, кгда планируют пакет, могут восп. тем, чт все каталоги стандартизирваны. Есть FHS, где прписано, что где должно лежать. Для того, чотбы уст. прогр. продукт., усл. говоря, дост. его разархивировать неглядя. В первую чередь, для уст. продукта дст. его просто рахзархивировать (cpio). Что мы сделали: мы скачали пакет с сайта, натравили утилиту, которая преб. его в cpio-архив, которая его разжимает и уд. доп. инф, и пакет. предст. сбй просто архив. Для того, чтобы уст. прогр. продукт, его надо разарх. Это сделает уст. Сразу возн. впрс, что делать, если есть ещё дин прогр. продукт, если там тже есть /usr/bin/zip? На данном этапе лектор отв. вопросом на вопрс: а как такое случилось? У нас есть хранилище, в котором два конфл. пакета, и мы мжем отследить, что два прогр. продукта кладут дин прогр. файл. Блее того, есть ситуации, когда конфл. предпочтителен, пск. такие прдукты делают дно и то же. Было бы норм., если пкет это архив, более того, есть slackware, где именно так. Чего не хватает в утв., что уст. это разархивация. А что такое удаление? Это разрахивация. Т есть, при уст. надо регистрировать сам факт уст. и уст. файлы. Эту функцию делает программа rpm: rpm query -f /usr/bin/zip. Обратите внимание, чт в репзитории уже более новый пакет. Куда rpm смтрит? В каую-то бд, где она это записывет.
В момент регистр. для каждго файла зап. контр. сумма. Это нужно затем, чтбы прверить, изм. файл или нет? Идея проверки в след.: предп., что файл конфигурационный. В этм случае внутр. пакета помеч., чт файл конф., и если при уд. пакета выясн, что файл изменился, то он не удаляется, а переименовывается (в *.rpmsafe). При обн. новые конф. файлы кладутся как (*.rpmnew). На самм деле, этго ещё ндеост., поск. часто бывает, чт при уст. и уд. пакета надо вып. не только действия с файлами, но и доп. действия с системой. НапримеР, уст. mod_php. Было бы непл. ег не только уст, но и перезап. вебсервер. Или при уст. ведсервера надо добавить польз. apache. Бывает, чт онадо вып. специф. для пакеты действия. Это называется предуст. и постуд. сценарии. В альте их 4 (перед уст., после уст., перед уд., после уд.), в дебиане 7. Пример: rpmquery --scripts dhcp-server
На самом деле, свйства пакетов кк сущн. заканчиваются и нач. не менее важные. Пакет это такой архив, который рег. в системе при уст и вып. сценарии. Здесь возн. два вопроса: про конфл. и зависимости. Неск. раз гворилось за этот блок лекций, что допустим при исп. дин. библ. резко повышается убство для разрабтчика. В-первых, файл занимает меньше места, во-втрых, n файлов занимают меньше места, в-третьих, все ни польз. дной и тй же библ.. Это имеет обр. св-во --- при наличии ошибки вероятность нахожд ошибки в сотв. кол. раз выше. Но становится вопрос --- в какой пакет длжна вхдить дин. библитека, которой польз. много прогр. продуктов? Поск. мы можем пост. то один продукт, то другой, то логично включить его в каждый прогр. прдукт, но это ведёт к тому же, что и при статическй сборке. Особенно, если мы знаем, что нет никаких огр. к доступу к пакетам. Поэтому ндао в кач. осн. вариант принимать второй -- если некая группа библ. исп. рядом разного по, то он кладётся отд. пакетом.
# В мастер входит порядка 400 пргр. прдуктов, которые рег. иконки.
Вт у нас неск. тысяч пакетов в исизифе, неск. тысяч в дистр. Всё это замечательно, но как же быть с установкой? чтбы уст. гимп, надо уст. кучу пакетов, кторые ему нужны, а им в свю чередь тоже нужны и так далле. Да, есть такое понятие как зависимсть пакетов, и пакет, имеющ. зависимсти, не мжет быть уст., пока зависимости не удовл.
Осталась проблема кнфликтов. Этот конфликт паразитный --- было бы непл, чтобы два ментейнера договорились, как они сит. будут разруливать. Есть инструмент, наз. альтернативы, которые делает слкдующее: ... . Наиболее частый пример --- cdrecordю Он сущ. в двух ипостасях, один кторый пишет ..., и cdrecord, которое пишет сообщество. Проблема в том, что у этих программ уже разный синт. ключей. Осталось тольк выясн., кто есть cdrecord. Если в сист. стоят оба пакета, то в /usr/bin лежит симлинк. Симлинк всегда смотрит на альтернативы, а спец. утилита в alternatives позв. переключать либо туда, либ туда.
Пр конфликты. Бывает, чт конфл. над обеспечить. Вот есть два почт. сервера, и ба хотите устанвить. По-хорошему, этго делать не надо. При этом, предп. ситуацию, что конф. по файлам не сущ. Было бы неплохо этот конфл. вписать в пакеты заранее. Это делается след. образом: каждый пакет объявл, какие функции он обеспечивает. Если вы попытаетесь уст. два пакета, кторые обесп. один. функц., вам ничег не дадут сделать.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
0 |
1 |
1 |
1 |
|
1 |
|
|