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

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Главное в мире Linux

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

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

> Ви­зуа­ли­за­ция про­цес­са раз­ра­бот­ки ре­по­зи­то­рия с по­мо­щью 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), на ко­то­рых со­б­ра­на ин­фор­ма­ция о пра­ви­лах ра­бо­ты с па­ке­та­ми в дан­ном ди­ст­ри­бу­ти­ве, ис­поль­зо­вании ин­ст­ру­мен­тов, ав­то­ма­ти­че­­ских тес­тах, воз­мож­ных ошиб­ках и спо­со­бах их пре­дот­вра­щения и ис­прав­ления. Та­кие знания на­ря­ду с соб­ст­вен­но сред­ст­ва­ми ав­то­ма­ти­за­ции про­цес­сов раз­ра­бот­ки и тес­ти­ро­вания по­мо­га­ют су­ще­ст­вен­но улуч­шить ка­че­­ст­во ди­ст­ри­бу­ти­ва. |