1. Серії пакетів Slackware: замість введення
2. репозиторії Salix
3. Малюнок 1. Кореневий каталог сховища для 64-розрядної архітектури
4. Малюнок 2. Гілка сховища Salix, запозичена з прабатьківської дистрибутива
5. Малюнок 3. Дистрибутив-специфічна гілка сховища Salix
6. Малюнок 4. Основні каталоги гілки Slackware
7. Налаштування slapt-get
8. Таблиця. Час відгуку дзеркал офіційного репозиторію Salix
9. додаткові репозиторії
10. Ресурси для скачування

В п'ятої частини циклу , Розглянувши роботу з пакетами взагалі і утиліту slapt-get особливо, ми виявили, що успішне її застосування в дистрибутиві Salix багато в чому визначається специфікою його репозиторіїв. Розгляд яких і буде предметом частини шостої.

Серії пакетів Slackware: замість введення

Перш ніж перейти до опису пристрою репозиторіїв Salix, необхідно сказати кілька слів про існуючим у Slackware і її клони понятті серій пакетів.

У всіх розвинених системах пакетного менеджменту існує поняття так званих метапакетов (metapackages), хоча вони носять різні імена, під FreeBSD, з якої і пішло це поняття, вони називаються метапакетамі і метапортамі, в дистрибутивах, які використовують формат пакетів deb - завданнями (tasks), в openSUSE - шаблонами (patterns), в Fedora - групами (groups). Однак суть залишається одна і та ж. Метапакет - це список тим чи іншим чином пов'язаних пакетів, які можуть бути встановлені, оновлені і, в деяких випадках, видалені однією командою.

В Slackware і її клони (в тому числі і в Salix) аналогом метапакетов є серії або набори пакетів (series або sets). Класичний список таких серій, сформований в незапам'ятні часи зародження прабатьківській системи, включає наступні компоненти:

• a - мінімальний набір пакетів для функціонування системи в режимі консолі;
• ap - консольні додатки і утиліти, що виходять за межі необхідного мінімуму;
• d - інструментарій для розробки і збірки програм;
• e - GNU Emacs і все, що має до нього відношення;
• f - різна загальносистемна документація, включаючи FAQ та HOWTO;
• k - вихідні тексти ядра Linux;
• kde - пакети, в сумі утворюють однойменну інтегровану середу і необхідні для її роботи бібліотеки;
• kdei - пакети інтернаціоналізації для середовища KDE та її додатків;
• l - бібліотеки загального призначення, від загальносистемної glibc до Qt і Gtk;
• n - програми для роботи з мережею;
• t - TeX і все, що з ним пов'язано;
• tcl - інтерпретатор мови TCL і пов'язаний з ним інструментарій;
• x - віконна система X, тобто Xorg, включаючи X-сервер, драйвери пристроїв введення-виведення і відеопідсистеми і так далі;
• xap - додатки графічного режиму, що не входять в базову систему Xorg, включаючи віконні менеджери;
• xfce - однойменний інтегрований десктоп і його штатні додатки;
• y - стародавні консольні ігри, що йдуть ще з BSD-систем.

У Salix'е дієві все набори материнської системи, проте є і деякі власні:

• games - гри, які замінять доісторичний набір f (якого тут немає);
• gnome - додатки для однойменної середовища, кілька років тому виключений з офіційного репозиторію самої Slackware;
• locale - пакети локалізації для LibreOffice, Firefox і Thunderbird;
• lxde - робоче середовище LXDE і її штатні додатки;
• mate - сучасний клон GNOME 2.

Будь-яка з серій пакетів може бути встановлена однією командою - для цього в slapt-get передбачена спеціальна мета:

$ Sudo slapt-get --install-set [ім'я серії]

Принцип комплектування серій пакетів в Slackware дещо інший, ніж, скажімо, завдань в Ubuntu: подібно шаблонами в openSUSE, це скоріше тематичні групи, ніж цільові набори типу ubuntu-desktop. І, крім «канонічних» серій Slackware, таких, як a, ap і так далі, власні набори пакетів можуть створюватися досить довільно: для цього досить помістити відповідні пакети в один каталог, який доповнюється так званим файлом тегів (tagfile), що містить їх перелік . Однак slapt-get оперує не серіями пакетів, а їх репозиторіями, до розгляду яких ми нарешті і переходимо.

репозиторії Salix

Застосування до репозиторіїв Salix множини кілька умовно. По суті, тут ми маємо справу з єдиним сховищем пакетів (і його офіційними дзеркалами), а не такими складно структурованими конструкціями, як офіційні і напівофіційні (semi-official) репозиторії openSUSE або репозиторії main, universe, restricted і multiverse в Ubuntu, не кажучи вже про її незліченних PPA-репозиторіях. Втім, щось на зразок аналога останніх (або «домашніх» репозиторіїв openSUSE) в Slackware і в Salix теж є, але про це мова піде в одній з наступних статей циклу.

А поки розглянути пристрій сховища Salix найпростіше на конкретному прикладі - наприклад, майстер-сервера проекту . Тут можна бачити складання пакетів для кожної з архітектур - x86 (іменованої i486) і x86_64. Є ще й збірка для процесорів ARM, але це річ специфічна, і я про неї говорити не буду. Далі мова піде про лінії x86_64, як більш актуальною.

Усередині кожної «архітектурної лінії» відокремлюються дві гілки - репозиторії власне Salix і репозиторії Slackware, кожна з поділом на версії (від першої, 13.0 до поточної, 14.1 - надалі буде матися на увазі остання).

Малюнок 1. Кореневий каталог сховища для 64-розрядної архітектури

Оскільки розробники Salix, як вони самі підкреслюють в згадуваному в першій частині циклу інтерв'ю, розвиток базової системи передовірили «головної організації», основна частина пакетів дистрибутива зберігається в каталозі /salix/x86_64/slackware-14.1/ - його однойменному підкаталозі slackware64 і extra. Він же є майже точне дзеркало відповідних гілок офіційного сервера батьківського дистрибутива - за двома важливими винятками.

Перше - «здубльовані» не всі пакети Slackware, а тільки ті, які задіюються в дистрибутиві Salix. Про другий же виключення я скажу трохи пізніше.

В основній частині «головний» гілки сховища, тобто в каталозі /x86_64/slackware-14.1/slackware64, можна бачити ті самі серії пакетів, про які йшлося в попередньому розділі, а також кілька службових файлів:

CHECKSUMS.md5 CHECKSUMS.md5.asc FILE_LIST MANIFEST.bz2 PACKAGES.TXT

Малюнок 2. Гілка сховища Salix, запозичена з прабатьківської дистрибутива

Найважливішим із них є файл PACKAGES.TXT, що містить перелік усіх пакетів з характеристикою кожного - тієї самої, яка виводить команда slapt-get при вказівці мети show і назви пакунка. Наприклад, для пакета zsh вона виглядає так:

PACKAGE NAME: zsh-5.0.2-x86_64-1.txz PACKAGE LOCATION: ./slackware64/ap PACKAGE SIZE (compressed): 2428 K PACKAGE SIZE (uncompressed): 9340 K PACKAGE REQUIRED: gdbm, ncurses PACKAGE CONFLICTS: PACKAGE SUGGESTS: PACKAGE DESCRIPTION: zsh: zsh (the Z shell) zsh: zsh: Zsh is a UNIX command interpreter (shell) which of the standard shells zsh: most resembles the Korn shell (ksh), although it is not completely zsh: compatible. It includes enhancements of many types, notably in the zsh: command-line editor, options for customizing its behavior, filename zsh: globbing, features to make C-shell (csh) users feel more at home and zsh: extra features drawn from tcsh (another 'custom' shell). Zsh was zsh: written by Paul Falstad. zsh:

Інші файли каталогу, а їх може бути більше, ніж наведено на скрішноте, також важливі. Так, файл, CHECKSUMS.md5 містить контрольні суми файлів, що підтверджують їх «незмінність», файл GPG-KEY, розташований в батьківському каталозі, включає ключі, що засвідчують їх «справжність», і так далі. Однак саме наявність файлу PACKAGES.TXT чарівним чином перетворює звичайний каталог з файлами пакетів на локальному диску або віддаленому сервері в їх репозиторій.

Переходимо глибше, в підкаталог одній із серій - і там бачимо вже власне файли пакетів і по два файли зі службовою інформацією. Наприклад, для того ж пакету zsh (в серії ap) вони такі:

• zsh-5.0.2-x86_64-1.txz - архів з бінарним виконуваним файлів, документацією та іншими компонентами пакета;
• zsh-5.0.2-x86_64-1.txt - короткий опис пакету;
• zsh-5.0.2-x86_64-1.txz.asc - контрольна сума для перевірки цілісності архіву.

Все - більше ніякої інформації в репозиторії Slackware начебто не міститься. У тому числі - і ніякої інформації про залежності пакетів.

Тепер звернемося до дистрибутив-специфічною гілці сховища Salix, тобто до каталогу /x86_64/14.1. Він містить пакети, або відсутні в офіційному репозиторії Slackware (наприклад, slapt-get, описаний в п'ятій частині циклу, його графічну оболонку Gslapt, про яку мова піде в частині сьомій, і деякі інші), або пакети, які розробники дистрибутива з тих чи інших причин визнали за необхідне зібрати за своїм (наприклад, mozille-firefox). Тут ми бачимо ті ж службові файли PACKAGES.TXT з «анотований» списком пакетів, GPG-KEY з колючим, ChangeLog.txt з описом оновлень сховища, і інші.

Малюнок 3. Дистрибутив-специфічна гілка сховища Salix

Відправившись «глибше», в підкаталог salix, можна виявити серії пакетів, в тому числі і специфічні для дистрибутива, наприклад, серію mate, а в ній - окремі пакети. Але тут на кожен індивідуальний пакет доводиться вже п'ять файлів. Наприклад, для пакета caja (файловий менеджер - форк Nautilus з GNOME2) це будуть:

caja-extensions-1.8.0-x86_64-1gv.dep caja-extensions-1.8.0-x86_64-1gv.md5 caja-extensions-1.8.0-x86_64-1gv.meta caja-extensions-1.8.0-x86_64-1gv .txt caja-extensions-1.8.0-x86_64-1gv.txz

Вміст трьох з них (* .txz, * .txt і * .md5) ми вже знаємо, а що ж таке файли * .dep і * .meta? Дізнатися це легко, якщо їх переглянути. Перший - це опис тих самих горезвісних залежностей для пакета:

atk, bzip2, cairo, cxxlibs | gcc-g ++, dconf ...

А файл * .meta - результуюча метаінформація:

PACKAGE NAME: caja-extensions-1.8.0-x86_64-1gv.txz PACKAGE LOCATION: ./salix/mate PACKAGE SIZE (compressed): 78 K PACKAGE SIZE (uncompressed): 312 K PACKAGE REQUIRED: atk, bzip2, cairo, cxxlibs | gcc-g ++, dconf, expat, fontconfig, freetype, gcc, gdk-pixbuf2, glib2, gtk + 2, harfbuzz, icu4c, libX11, libXau, libXcomposite, libXcursor, libXdamage, libXdmcp, libXext, libXfixes, libXi, libXinerama, libXrandr , libXrender, libXxf86vm, libdrm, libffi, libpng, libxcb, mate-desktop, mate-file-manager, mesa, pango, pixman, startup-notification, udev, xcb-util, zlib PACKAGE CONFLICTS: PACKAGE SUGGESTS: ...

Можна бачити, що вона включає в себе не тільки «жорсткі» залежності (PACKAGE REQUIRED), але може описувати і залежно опціональні ( «м'які» - PACKAGE SUGGESTS), а також конфліктуючі пакети, якщо ті і інші є (в прикладі їх немає) . Саме завдяки цій метаінформації slapt-get може не тільки відстежувати залежності пакетів при їх установці, але і вирішувати їх автоматично.

І тут читач має право поставити питання: якщо «специфічна» частина сховища охоплює меншість пакетів Salix, а більшість їх береться з дзеркала сховища Slackware, то як залежності контролюються для них? Адже там в серіях пакетів ми не бачили і натяку на опису залежностей.

Для відповіді на це питання досить звернутися до каталогу /x86_64/slackware-14.1, батьківського по відношенню до того, що був приведений на рис. 2. І там звернути увагу на підкаталог dep.

Малюнок 4. Основні каталоги гілки Slackware

Зайшовши в нього, можна виявити безліч файлів з маскою * .dep - за сумарною кількістю пакетів в гілці Slackware. У них-то і описані залежності для пакетів, запозичених з прабатьківської сховища, ні про які залежностях і не підозрює. Наприклад, у файлі zsh.dep можна побачити наступне:

gdbm, ncurses

Наявність підкаталогу з файлами залежностей - друге (поряд зі складом пакетів) відміну гілки Slackware в репозиторії Salix відміну останнього від офіційного репозиторію «головного» дистрибутива.

Ну а винесені ці файли в окремий підкаталог з міркувань, можна сказати, етичних: щоб зберегти структуру гілки, запозиченої з Slackware, в недоторканності. Тобто підкаталог /x86_64/slackware-14.1/deps - свого роду мега-патч для сховища, що забезпечує контроль залежностей в сховище пакетів, спочатку на це не розрахованому.

Заодно можна відповісти і на інше питання: чому slapt-get не отримав широкого поширення в самій Slackware і, за деякими винятками, в її клонах? Перша частина відповіді очевидна: в офіційному репозиторії вихідного дистрибутива ніяких описів залежностей не міститься. І в цьому випадку slapt-get втрачає більшість своїх переваг - більш ефективною системою управління пакетами виявляється slackpkg. Для розробників же будь-яких клонів Slackware включити slapt-get в штатний комплект свого дистрибутива недостатньо: треба також створити сховище з підтримкою залежностей, а головне - підтримувати його в актуальному стані. Що, зрозуміло, є нелегкою і не дуже захоплюючою роботою, до якої мало хто з ентузіастів виявився готовий. Наскільки я знаю, єдиний, крім Salix, дистрибутив, де така робота ведеться - це Vector Linux. Але він і створювався спочатку як система, призначена, в тому числі, і для комерційного поширення.

Налаштування slapt-get

Тепер, знаючи, як влаштовані репозиторії Salix, можна повернутися до утиліти slapt-get - точніше, до її налаштування. Тому що велика частина останньої - як раз і є забезпечення доступу до репозиторіїв.

Всі настройки slapt-get зберігаються в файлі / etc / slapt-get / slapt-getrc. Це простий текстовий файл, який можна умовно розділити на три нерівні секції.

Перша секція найменша, і складається з одного рядка, що визначає каталог для локального кеша репозиторіїв і мета зберігання встановлюються пакетів. За замовчуванням це

WORKINGDIR = / var / slapt-get

І міняти її без вагомих підстав не слід (я таких підстав не бачу). А от подивитися на її вміст не шкідливо:

$ Ls / var / slapt-get package_data patches / salix / slackware64 /

Найголовніше тут - файл package_data: це «інтегрована» локальна копія файлів PACKAGES.TXT всіх підключених репозиторіїв, створювана командою

$ Sudo slapt-get -update

Той самий файл, без якої slapt-get відмовляється виконувати будь-які інші дії.

Призначення підкаталогів очевидно: в них зберігаються завантажені при установці пакети з відповідних гілок сховища, з розбивкою на серії. Про що слід пам'ятати, якщо виникне необхідність перенесення пакетів на машину, яка не має підключення до мережі.

Друга секція також містить єдиний рядок, хоча й трохи довшу:

EXCLUDE = ^ aaa_elflibs, ^ aaa_base, ^ devs, ^ glibc. *, ^ Kernel -. *, ^ Udev, ^ rootuser-settings, ^ zzz-settings. *, - i? 86-

Це - ті самі винятки, тобто маски імен пакетів, які не торкаються оновленнями по команді

$ Sudo slapt-get -upgrade

А також - автоматичними оновленнями, про які йтиметься у частині сьомій. Видаляти з цього рядка нічого не слід. При необхідності оновити, наприклад, ядро системи це можна зробити, явно додавши опцію --ignore-excludes до команди установки пакета, наприклад:

$ Sudo slapt-get - install -ignore-excludes kernel-huge

А от необхідність поповнити список виключень може виникнути - наприклад, пакетам, наявними в штатному репозиторії, але власноруч пересобран з будь-якими специфічними опціями.

Нарешті, третя секція - це список доступних репозиторіїв. За замовчуванням він виглядає так (якщо при первинній установці не було вибрано інше дзеркало):

# The Slackware repositories, including dependency information SOURCE = http: //salix.hostingxtreme.com/x86_64/slackware-14.1/: OFFICIAL SOURCE = http: //salix.hostingxtreme.com/x86_64/slackware-14.1/extra/: OFFICIAL # The Salix repository SOURCE = http: //salix.hostingxtreme.com/x86_64/14.1/: PREFERRED # Local repositories # SOURCE = file: /// var / www / packages /: CUSTOM

І якщо, повторюю, при інсталяції не було вибрано дзеркало, відмінне від «умолчальне», цю секцію правити можна, а швидше за все, і потрібно: сервер HoaringXtreme в наших умовах не дивує швидкістю доступу до нього.

На сторінці Repository mirrors сайту проекту наведено список всіх дзеркал майстер-сховища Salix. Для тих, що доступні по протоколу HTTP, я за допомогою утиліти ping перевірив час відгуку - результати зведені в таблиці.

Таблиця. Час відгуку дзеркал офіційного репозиторію Salix

Примітка: сервера в таблиці наведені в порядку зростання часу відгуку; н. / с. - немає зв'язку.

Зрозуміло, дані в таблиці наведені тільки для загального орієнтування - вони залежать від багатьох факторів, і у читача можуть бути іншими. Однак в цілому можна констатувати, що для Росії все «заокеанські» сервера, включаючи і пропонований за замовчуванням, - не найкращий вибір. Я зазвичай вибираю Нідерландський або Бельгійський сервери - в умовах Москви вони добре показують себе і для дзеркал багатьох інших дистрибутивів.

додаткові репозиторії

Кількість пакетів в репозиторії Salix за визначенням обмежено - розробники цього дистрибутива принципово не прагнули осягнути неосяжний світ вільного програмного забезпечення. Тому цілком реальна ситуація, коли применителей не виявить життєво важливого або улюбленого пакета. І тут заповнити «недостачу» можна двома способами.

Один з них - збірка відсутніх пакетів з вихідних текстів. Зрозуміло, не в «лобовому» варіанті, за допомогою трьох магічних заклинань ./configure, make, make install: цей шлях дуже швидко приведе до захаращення системи, і вдаватися до нього слід в самому крайньому випадку. Так в ньому немає і необхідності: від Slackware дистрибутив Salix успадкував механізм роботи з так званими слакбілдамі (Slackbuilds) - сценаріями автоматизованого складання пакетів. І, більш того, зміцнив і розширив їх, в тому числі за допомогою графічної оболонки до консольним засобів. Але цей шлях буде розглянуто в одній з найближчих частин.

Тому що є шлях інший, який видається більш простим. Як неодноразово підкреслювалося на протязі всього циклу, Salix зберігає повну бінарну сумісність зі Slackware на рівні пакетів. Так що чому б не спробувати пошукати пакети, відсутні в штатному репозиторії дистрибутива, серед сховищ пакетів, які не мають офіційного статусу, тобто створених і підтримуваних ентузіастами для прабатьківській системи?

Неофіційні репозиторії Slackware - це свого роду податки PPA-репозиторіїв Ubuntu або «домашніх» репозиторіїв openSUSE. Вони не такі численні, як останні (і, тим більше, перші). Але мають місце бути, причому деякі з них розвиваються вже багато років, виникнувши задовго до створення PPA і OBS. Серед них можна бачити

• репозіторії «братніх» дістрібутівів, подібно Salix, Які зберігалі повну сумісність зі Slackware (например, репозіторій дистрибутива Slackel ;
• репозіторії для Збірки спеціалізірованнх систем - прикладом может послужити Microlinux Enterprise Desktop (або просто MLED ;
• сховища пакетів для окремих інтегрованих середовищ (наприклад, Ktown , Що містить збірки версій KDE, новіших, ніж включені в реліз) або віконних менеджерів (таких, як репозиторій пакетів для Enlightenment DR17 - Slack64e14 ;
• нарешті, особисті репозиторії ентузіастів - самим відомими є сховища пакетів, зібраних Еріком Хамелірсом (Eric Hameleers, також відомий як Alien Bob і Alien Pastures) для применителей з США и інших країн .

Більш докладно про неофіційні репозиторіях Slackware можна прочитати на цій сторінці .

Зрозуміло, всі знайдені репозиторії Slackware не слід відразу ж вписувати в / etc / slapt-get / slapt-getrc і негайно виконувати тотальне оновлення кеша, а потім і пакетів. Якраз навпаки, робити цього не слід: неофіційні репозиторії розвиваються самі по собі, часто містять різні версії одного і того ж пакету, та ще й їх залежності можуть бути трохи різними. Так що при такому огульному підключенні цілком вірогідні конфлікти.

Так що краще вписати неофіційні репозиторії з необхідними пакетами в альтернативний конфігураційний файл (наприклад, / etc / slapt-get / slapt-get-ktownrc для використання нових версій KDE), і для звернення до його вмісту використовувати slapt-get з опцією --config [ім'я файлу].

Втім, slapt-get в консольному виконанні не передбачає автоматичного, незалежного від дій применителей (як це зазвичай відбувається в Ubuntu), поновлення пакетів. Ця функція покладається на відповідну службу, яка використовує графічну оболонку Gslapt, яка буде предметом розгляду в сьомий частини циклу .

Ресурси для скачування

Підпишіть мене на повідомлення до коментарів