Журнал LinuxFormat - перейти на главную

LXF169:Ре­по­зи­то­рии

Материал из Linuxformat
Перейти к: навигация, поиск

Содержание

Ре­по­зи­то­рии: Хра­ним па­ке­ты

Андрей Пономаренко и Владимир Рубанов ис­сле­дуют тон­ко­сти под­держ­ки па­кет­ных ре­по­зи­то­ри­ев в ди­ст­ри­бу­ти­вах Linux.

(thumbnail)
> Ви­зуа­ли­за­ция про­цес­са раз­ра­бот­ки ре­по­зи­то­рия с по­мо­щью CodeSwarm.

Клю­че­вым на­прав­лением раз­ви­тия лю­бо­го со­вре­мен­но­го ди­ст­ри­бу­ти­ва Linux яв­ля­ет­ся пре­достав­ление поль­зо­ва­те­лям наи­боль­ше­го раз­но­об­ра­зия про­грамм на лю­бой вкус. Для бы­ст­рой и удоб­ной уста­нов­ки про­грамм в ди­ст­ри­бу­ти­вах ис­поль­зу­ют­ся RPM- или Deb-па­ке­ты, ко­то­рые хра­нят­ся в спе­ци­аль­ных ре­по­зи­то­ри­ях на уда­лен­ных сер­ве­рах в ин­тернете или на уста­но­воч­ном дис­ке. Ка­ж­дый па­кет пред­став­ля­ет со­бой за­ранее со­б­ран­ную из ис­ход­ных ко­дов про­грам­му, го­то­вую к ис­поль­зо­ванию. Ко­ли­че­­ст­во па­ке­тов в ре­по­зи­то­рии мо­жет быть бо­лее 10000! Сбор­кой же па­ке­тов занима­ют­ся так на­зы­вае­мые мейн­тейнеры ди­ст­ри­бу­ти­ва. Это мо­гут быть как эн­ту­зиа­сты из ми­ро­во­го со­об­ще­ст­ва, так и штат­ные спе­циа­ли­сты ком­пании – по­став­щи­ка ди­ст­ри­бу­ти­ва. И неле­гок их труд.

Ви­ды ре­по­зи­то­ри­ев

Об­щее ко­ли­че­­ст­во про­грамм в ти­пич­ном со­вре­мен­ном ди­ст­ри­бу­ти­ве Linux – по­ряд­ка де­ся­ти ты­сяч. Боль­шин­ст­во из них хра­нят­ся в ре­по­зи­то­ри­ях, и толь­ко часть наи­бо­лее востре­бо­ван­ных про­грамм идет на уста­но­воч­ных дис­ках. Для соз­дания, сбор­ки и дальней­ше­го об­нов­ления та­ко­го боль­шо­го ко­ли­че­­ст­ва па­ке­тов отводят­ся су­ще­ст­вен­ные че­ло­ве­че­­ские ре­сур­сы. Тем не менее, на под­держ­ку всех па­ке­тов в ре­по­зи­то­ри­ях, как пра­ви­ло, ре­сур­сов все рав­но не хва­та­ет. По этой при­чине ре­по­зи­то­рии раз­де­ля­ют на две фун­да­мен­таль­ные час­ти: глав­ный (main) и вто­ро­сте­пен­ный (contrib). За ка­ж­дым па­ке­том в глав­ном ре­по­зи­то­рии дол­жен быть за­кре­п­лен оп­ре­де­лен­ный мейн­тейнер, ко­то­рый бу­дет сле­дить за его со­стоянием. Па­ке­ты же из вто­ро­сте­пен­но­го ре­по­зи­то­рия под­дер­жи­ва­ют­ся не по­сто­ян­но – лю­бы­ми чле­на­ми со­об­ще­ст­ва ди­ст­ри­бу­ти­ва, у ко­то­рых по­яв­ля­ет­ся на это сво­бод­ное вре­мя.

Вы­де­ля­ют так­же еще два ви­да спе­циа­ли­зи­ро­ван­ных ре­по­зи­то­ри­ев: для про­грамм с за­кры­тым ко­дом (non-free) и на­ру­шаю­щих па­тен­ты неко­то­рых стран (restricted). Па­ке­ты в этих ре­по­зи­то­ри­ях, как и в глав­ном ре­по­зи­то­рии, долж­ны под­дер­жи­вать­ся яв­но на­зна­чен­ны­ми мейн­тейнера­ми, что­бы из­бе­жать воз­мож­ных про­блем по рас­про­странению ди­ст­ри­бу­ти­ва.

Сто­ит за­ме­тить, что кон­крет­ные на­звания ре­по­зи­то­ри­ев мо­гут раз­ли­чать­ся в раз­ных ди­ст­ри­бу­ти­вах. На­при­мер, main-ре­по­зи­то­рий в Fedora на­зы­ва­ют core-ре­по­зи­то­ри­ем, а restricted-ре­по­зи­то­рий в ди­ст­ри­бу­ти­ве Mageia на­зы­ва­ют tainted-ре­по­зи­то­ри­ем.

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

Что­бы мож­но бы­ло бы­ст­ро счи­ты­вать основ­ную ин­фор­ма­цию о доступ­ных па­ке­тах, в ре­по­зи­то­ри­ях хра­нят­ся так на­зы­вае­мые ме­та­фай­лы. В них со­дер­жит­ся ин­фор­ма­ция о на­званиях, вер­си­ях, за­ви­си­мо­стях и со­дер­жании па­ке­тов. Ис­то­ри­че­­ски фор­мат та­ких фай­лов раз­ли­ча­ет­ся в раз­ных ди­ст­ри­бу­ти­вах. На­при­мер, в ди­ст­ри­бу­ти­ве ROSA это hdlist-фай­лы, а в Fedora – repodata-фай­лы.

Пра­ви­ла па­ке­ти­ро­вания

Что­бы под­дер­жи­вать струк­ту­ру ди­ст­ри­бу­ти­ва и уп­ро­стить про­цесс раз­ра­бот­ки, вво­дят­ся спе­ци­аль­ные правила (policy) для соз­дания и об­нов­ления па­ке­тов. На­при­мер, они опи­сы­ва­ют пу­ти уста­нов­ки раз­ных ти­пов фай­лов про­грам­мы в сис­те­ме, пра­виль­ный вы­бор имен па­ке­тов в за­ви­си­мо­сти от их со­дер­жи­мо­го, и т. д. Все это в дальней­шем по­зво­ля­ет лег­че ори­ен­ти­ро­вать­ся в сис­те­ме и ра­бо­тать про­дук­тивнее.

Тес­ти­ро­вание па­ке­тов

К со­жа­лению, не все про­цес­сы по соз­данию па­ке­тов доста­точ­но ав­то­ма­ти­зи­ро­ва­ны, что­бы не возника­ло оши­бок в па­ке­тах. Для их по­ис­ка ис­поль­зу­ют­ся ав­то­ма­ти­че­­ские тес­ты, про­ве­ряю­щие со­от­вет­ст­вие со­дер­жи­мо­го па­ке­тов уста­нов­лен­ным по­ли­ти­кам. Одним из наи­бо­лее из­вест­ных и универ­саль­ных ин­ст­ру­мен­тов для тес­ти­ро­вания RPM-па­ке­тов яв­ля­ет­ся Rpmlint [1]. Этот ин­ст­ру­мент про­ве­ря­ет со­дер­жи­мое и ат­ри­бу­ты па­ке­тов на со­от­вет­ст­вие несколь­ким сот­ням пра­вил. Пра­ви­ла мо­гут быть от­клю­че­ны, до­полнены или из­менены, что­бы со­от­вет­ст­вать по­ли­ти­ке кон­крет­но­го ди­ст­ри­бу­ти­ва. В за­ви­си­мо­сти от ко­ли­че­­ст­ва на­ру­шен­ных пра­вил па­ке­ту при­сваи­ва­ет­ся оп­ре­де­лен­ный уро­вень негод­но­сти (badness). Ес­ли негод­ность па­ке­та боль­ше неко­то­рого за­ранее оп­ре­де­лен­но­го уров­ня, то па­кет необ­хо­ди­мо ис­прав­лять. До­пусти­мый же уро­вень негод­но­сти мож­но варь­и­ро­вать в за­ви­си­мо­сти от доступ­но­го ко­ли­че­­ст­ва мейн­тейнеров, сро­ков вы­пуска ди­ст­ри­бу­ти­ва и ко­ли­че­­ст­ва под­дер­жи­вае­мых па­ке­тов. Ана­ло­гом дан­но­го ин­ст­ру­мен­та для ди­ст­ри­бу­ти­вов, ис­поль­зую­щих Deb-па­ке­ты, яв­ля­ет­ся Deblint [2]. Для ре­по­зи­то­рия глав­ное, что­бы все па­ке­ты в ре­по­зи­то­рии со­би­ра­лись, уста­нав­ли­ва­лись и ра­бо­та­ли.

Замк­ну­тость ре­по­зи­то­рия

[[Файл: | right |thumb|300px| ]] Важ­нейшимм тре­бо­ванием к па­кет­ным ре­по­зи­то­рям яв­ля­ет­ся воз­мож­ность без­оши­боч­ной уста­нов­ки всех па­ке­тов на ком­пь­ю­тер поль­зо­ва­те­ля. Про­бле­мы с уста­нов­кой па­ке­тов мо­гут возникать по раз­ным при­чи­нам – на­при­мер, ес­ли один па­кет тре­бу­ет для ра­бо­ты несколь­ко дру­гих, при этом од­но­го из них по ка­кой-то при­чине нет в ре­по­зи­то­рии. Та­кое яв­ление на­зы­ва­ют нераз­ре­шен­ной за­ви­си­мо­стью. При­чи­ной их возник­но­вения мо­жет слу­жить как ошиб­ка мейн­тейнера, так и сбой в при­ме­няе­мых ин­ст­ру­мен­тах. Для кон­тро­ля та­ких оши­бок ис­поль­зу­ют­ся ста­ти­че­­ские ана­ли­за­то­ры замк­ну­то­сти ре­по­зи­то­рия, т. е. на­ли­чия всех па­ке­тов, тре­буе­мых дру­ги­ми па­ке­та­ми. К со­жа­лению, в си­лу су­ще­ст­вен­ных раз­ли­чий фор­ма­тов ре­по­зи­то­ри­ев у раз­ных ди­ст­ри­бу­ти­вов по­ка еще нет универ­саль­но­го ин­ст­ру­мен­та для про­вер­ки замк­ну­то­сти. На­при­мер, в та­ких ди­ст­ри­бу­ти­вах, как Mandriva или ROSA, ис­поль­зу­ет­ся ин­ст­ру­мент urpm-repoclosure [3], а в Debian и Ubuntu ис­поль­зу­ет­ся ин­ст­ру­мент под на­званием debcheck [4].

Кон­флик­ты по фай­лам

Еще одной при­чи­ной, пре­пят­ст­вую­щей уста­нов­ке па­ке­тов, мо­жет быть кон­фликт по фай­лам с дру­ги­ми уста­нов­лен­ны­ми па­ке­та­ми, т. е. когда один па­кет пы­та­ет­ся уста­но­вить файл с тем же имененем и по то­му же пу­ти, что и дру­гой па­кет. Иногда та­кая си­туа­ция бывает до­пусти­мой – на­при­мер, когда два па­ке­та пре­достав­ля­ют две раз­ные реа­ли­за­ции вир­ту­аль­ной Java-ма­ши­ны или две раз­ные реа­ли­за­ции од­ной из стан­дарт­ных биб­лио­тек. В та­ких слу­ча­ях на­ли­чие кон­флик­та долж­но быть от­ра­же­но в свой­ст­вах па­ке­та. Ина­че кон­флик­тую­щие фай­лы следует пе­ре­име­но­вать, обусловив кор­рект­ную од­но­вре­мен­ную уста­нов­ку па­ке­тов.

Коль­це­вые за­ви­си­мо­сти

Не­ма­ло­важ­ной про­бле­мой па­кет­ных ре­по­зи­то­ри­ев так­же яв­ля­ют­ся коль­це­вые за­ви­си­мо­сти, т. е. за­ви­си­мо­сти ви­да A → B → C → A. Опять же, та­кие за­ви­си­мо­сти мо­гут быть до­пусти­мы, когда од­но­му па­ке­ту дей­ст­ви­тель­но тре­бу­ет­ся для ра­бо­ты дру­гой, а то­му ну­жен пер­вый, но их нель­зя по­мес­тить в еди­ный па­кет из-за по­ли­ти­ки име­но­вания и раз­де­ления про­грамм на па­ке­ты. В дру­гих слу­ча­ях это мо­жет быть ин­ди­ка­то­ром непра­виль­но опи­сан­ных за­ви­си­мо­стей ме­ж­ду па­ке­та­ми. При­чи­ной тут мо­жет быть не толь­ко че­ло­ве­че­­ский фак­тор, но и некор­рект­ная ра­бо­та ав­то­ма­ти­че­­ско­­го генера­то­ра за­ви­си­мо­стей у ис­поль­зуе­мого па­кет­но­го менед­же­ра. Это при­во­дит к боль­шим до­полнитель­ным вре­мен­ным за­тра­там уста­нов­щи­ка па­ке­тов и, воз­мож­но, к непра­виль­но­му по­ряд­ку уста­нов­ки па­ке­тов из коль­ца.

Коль­це­вые за­ви­си­мо­сти мож­но на­хо­дить с по­мо­щью спе­ци­аль­ных ин­ст­ру­мен­тов ана­ли­за. На­при­мер, в ди­ст­ри­бу­ти­ве ROSA для это­го ис­поль­зу­ет­ся ин­ст­ру­мент urpm-repograph [5].

Чи­ст­ка ре­по­зи­то­рия

Ре­сур­сы на под­держ­ку па­ке­тов ог­раниче­ны, по­это­му на­до уметь оп­ре­де­лять наи­бо­лее важ­ные. Со вре­менем па­ке­ты в ре­по­зи­то­ри­ях на­чи­на­ют уста­ре­вать, и от них на­до по­сте­пен­но из­бав­лять­ся. У неко­то­рых па­ке­тов по­яв­ля­ют­ся но­вые вер­сии, и ста­рые на­до уда­лять. Дру­гие же мо­гут и во­все стать ненуж­ны­ми в ре­по­зи­то­рии. К та­ким от­но­сят­ся, на­при­мер, вспо­мо­га­тель­ные па­ке­ты для поль­зо­ва­тель­ских при­ло­жений. Про­цесс из­бав­ления от них про­ис­хо­дит по­сте­пен­но. Ес­ли ка­ко­му-то па­ке­ту ста­но­вит­ся не ну­жен дан­ный вспо­мо­га­тель­ный па­кет, то он от­ме­ча­ет­ся как уста­рев­ший (obsolete) в его свой­ст­вах. За­тем та­кие же из­менения про­из­во­дят­ся для осталь­ных па­ке­тов. Ес­ли же дан­ный па­кет бу­дет по­ме­чен как уста­рев­ший во всех за­ви­ся­щих от него па­ке­тах, то мож­но при­сту­пать к его уда­лению.

По­пу­ляр­ность па­ке­тов

Из-за ог­раничен­но­сти че­ло­ве­че­­ских ре­сур­сов, вы­де­ляе­мых на под­держ­ку па­кет­ных ре­по­зи­то­ри­ев, пе­ред мейн­тейнера­ми всегда сто­ит за­да­ча вы­бо­ра на­бо­ра па­ке­тов, ко­то­рым на­до уде­лять внимание в пер­вую оче­редь. Наи­бо­лее важ­ные па­ке­ты оп­ре­де­ля­ют­ся ли­бо по ко­ли­че­­ст­ву дру­гих па­ке­тов, за­ви­ся­щих от дан­но­го (об­рат­ных за­ви­си­мо­стей), ли­бо по ко­ли­че­­ст­ву поль­зо­ва­те­лей, ис­поль­зую­щих дан­ный па­кет (по­пу­ляр­но­сти па­ке­та). Ко­ли­че­­ст­во об­рат­ных за­ви­си­мо­стей всегда мож­но под­счи­тать на осно­ве ана­ли­за толь­ко ре­по­зи­то­рия. Для оцен­ки же по­пу­ляр­но­сти поль­зо­ва­те­лям пред­ла­га­ют уста­но­вить до­полнитель­ный па­кет, ко­то­рый бу­дет со­об­щать раз­ра­бот­чи­кам об ис­поль­зуе­мых ими про­грам­мах. На­при­мер, в сис­те­ме Debian этот па­кет на­зы­ва­ет­ся popcon [6].

За­клю­чение

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

Имен­но по­это­му для но­вых чле­нов со­об­ще­ст­ва и мейн­тейнеров раз­ра­бот­чи­ки ди­ст­ри­бу­ти­вов час­то соз­да­ют ввод­ные Wiki-страницы (см. на­при­мер [7] в ROSA или [8] в Debian), на ко­то­рых со­б­ра­на ин­фор­ма­ция о пра­ви­лах ра­бо­ты с па­ке­та­ми в дан­ном ди­ст­ри­бу­ти­ве, ис­поль­зо­вании ин­ст­ру­мен­тов, ав­то­ма­ти­че­­ских тес­тах, воз­мож­ных ошиб­ках и спо­со­бах их пре­дот­вра­щения и ис­прав­ления. Та­кие знания на­ря­ду с соб­ст­вен­но сред­ст­ва­ми ав­то­ма­ти­за­ции про­цес­сов раз­ра­бот­ки и тес­ти­ро­вания по­мо­га­ют су­ще­ст­вен­но улуч­шить ка­че­­ст­во ди­ст­ри­бу­ти­ва. |

Персональные инструменты
купить
подписаться
Яндекс.Метрика