Slax
Среда, 27.11.2024, 03:48
Меню сайта

Категории каталога
Для пользователей [8]
Для разработчиков [4]

Форма входа

Поиск

Друзья сайта

Статистика
счетчик посещений





Анализ сайта


Онлайн всего: 1
Гостей: 1
Пользователей: 0

Наш опрос
Как вам мой сайт?
Всего ответов: 27

Реклама



Главная » Статьи » Для разработчиков

Как правильно создавать модули Slax

Вы можете создавать модули для Slax каким угодно образом до тех пор пока пользуетесь ими сами. Однако, если вы хотите поделиться модулями с другими, вам придётся следовать правилам, описанным на данной странице. Правила составлены, в первую очередь, для удобства пользователя; если вы не будете следовать этим правилам, то Ваш модуль никогда не попадёт в официальную базу модулей Slax.

Технический обзор

Модуль Slax - это сжатая файловая система squashfs с расширением .lzm. Модуль создан утилитой mksquashfs и может быть извлечён (распакован), используя unsquashfs. Оба этих инструмента должны быть пропатчены (изменены) для поддержки алгоритма сжатия LZMA. Эти утилиты уже включены в Slax.

Каждый модуль Slax содержит все файлы и директории с полным путём. Например, модуль с bash (бинарником и несколькими страницами man) должен выглядеть наподобие этого:

/bin/
/bin/bash
/usr/
/usr/man/
/usr/man/man1/
/usr/man/man1/bash.1

 

Правила


1) Все директории в вашем модуле должны быть доступны для обычного пользователя. Сбросьте все разрешения на 755 (drwxr-xr-x), пока не будет значимой причины использовать отличные разрешения для отдельной директории.

find ./ -type d | xargs chmod -v 755;

2) Сохраняйте размер вашего модуля наименьшим. Распакуйте все архивы, которые могут быть безопасно распакованы (например, страницы man, потому что LZMA сожмёт их гораздо лучше), удалите все файлы, в которых нет необходимости для запуска программы (например, ненужную документацию, неиспользуемые звуки, изображения png/jpg, ненужные переводы из /usr/share/locale) и вырежьте (strip) все ненужные символы из бинарников.

find ./usr/man/ -type l -name "*.gz" | xargs -r gunzip -f
find ./usr/man/ ! -type l -name "*.gz" | xargs -r gunzip
find . | xargs file | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded

3) Если вы скомпилировали модуль из исходных кодов, то предоставьте скрипт, который был использован для сборки. Скрипт должен обеспечивать полноценную сборку модуля. Любая ручная работа (копирование/удаление файлов и пр.) кроме как скриптом не допускается. Скрипт построения модуля служит как документация для создания вашего модуля; более того он упрощает поддержку вашего модуля в случае, если вы его забросите. Скопируйте скрипт в ваш модуль в:

/usr/src/slaxbuilds/your_module_name.slaxbuild

4) Когда вы компилируете программу, убедитесь, что используете правильные флаги компилятора (cflags) и параметры. Далее, рекомендуется использовать i486 инструкции (которые обеспечивают наилучшую обратную совместимость), но и настройте производительность кода так, как если бы целевой была архитектура i686. В Slax, вы можете запустить configure-for-slax как ярлык. Он делает то же самое:

CFLAGS="-O3 -march=i486 -mtune=i686" ./configure --prefix=/usr --build=i486-Slackware-linux

5) Никогда не включайте какие-либо существующие файлы из Slax в свой модуль, даже если вы их изменили. Другими словами, ваш модуль никогда не должен "перезаписывать" никакие файлы в Slax, пока не появится значимой причины для этого. Это может сделать ваш модуль несовместимым с более новыми версиями Slax и может стать причиной проблем с модулями других пользователей. Если вам действительно нужно заменить файл в Slax, (например, чтобы прописать новый путь в /etc/ld.so.conf), напишите вместо этого скрипт запуска, который будет изменять (обновлять) отдельный файл, вместо переписывания его вашим модулем.

Пример скрипта запуска для удаления одной строки из ld.so.conf и добавления новой в конец:

#!/bin/bash
sed -i -r '\;/usr/local/lib;d' /etc/ld.so.conf
echo '/opt/kde/lib' >> /etc/ld.so.conf
Вот пример списка из нескольких файлов, которые никогда не должны быть включены в ваш модуль:
/etc/init.d
/etc/rc.d/rc.S
/etc/rc.d/rc.M
/etc/rc.d/rc.K
/etc/rc.d/rc.local
/lib/modules/2.6.x/modules.dep
/lib/modules/2.6.x/modules.alias
/etc/ld.so.conf
/etc/ld.so.cache
/etc/passwd
/etc/group
/etc/shadow

6) Если вам нужно исполнить что-то во время активации модуля, или запуск или выключение системы, то используйте директории sysvinit-типа. Передовая практика сделать всеобщий сценарий в директории /etc/rc.d/init.d/, которая поймет ' start' и ' stop' аргументы. Все сценарии в той директории будут начаты с ' start' аргумент во время активации модуля, и с ' stop' аргумент во время выключения. Выборочно, вы можете установить символические соединения начиная с uppercase s (начать) и uppercase k (убить) в директориях sysvinit соответствие ваше пожеланное runlevel, например /etc/rc.d/rc3.d/. Каждое время runlevel изменено, Slax исполняет все сценарии начиная с k от предыдущей директории runlevel (убить), и все сценарии начиная с s от настоящей директории runlevel.

В следующем примере, Slax будет выполнять 'apache.sh start' на уровне выполнения 3 (что означает запуск системы), и будет выполнять 'apache.sh stop' на уровне выполнения 0 или 6 (это означает, что Slax выключает или перезагружает систему).

# Пример универсального скрипта: /etc/rc.d/init.d/apache.sh

#!/bin/bash
if [ "$1" = "start" ]; then
echo "start apache @ startup"
... start apache here ...
fi
if [ "$1" = "stop" ]; then
echo "stop all apache @ shutdown"
... stop apache processes here ...
fi

# Когда ваш универсальный скрипт будет создан, добавьте следующие символические ссылки:

ln -s ../init.d/apache.sh /etc/rc.d/rc3.d/S-apache
ln -s ../init.d/apache.sh /etc/rc.d/rc0.d/K-apache
ln -s ../init.d/apache.sh /etc/rc.d/rc6.d/K-apache

7) Если ваше ПО может запускаться в каком-либо графической среде (KDE, XFCE и пр.), то вы должны вложить иконку и добавить файл с пунктом меню в ваш модуль, для того, чтобы пользователь смог легко запустить приложение найдя его в меню. Для добавления пункта меню, просто создайте два файла:

/usr/share/applications/your-application.desktop
/usr/share/pixmaps/your-applications-icon.png
Первый файл (*.desktop) описывает пункт меню. Он может выглядеть так:
[Desktop Entry]
Encoding=UTF-8
Exec=firefox %u
Icon=/usr/share/pixmaps/firefox.png
Type=Application
Categories=Application;Network;
Name=Firefox
Name[cs]=Firefox
GenericName=Web Browser
GenericName[cs]=Webovy prohlizec
MimeType=text/html
X-KDE-StartupNotify=true

8) Когда ПО вашего модуля запускается, оно должно просто начать работать, без ненужных диалогов, подсказок дня или лиценционных соглашений. Помните, что если пользователь добавил ваш модуль на CD-R, то у него не будет возможности запомнить настройки модуля (выключить подсказки, согласиться с лицензионным соглашением, и т.д.), так что модуль не должен ему докучать.

9) Зависимости вашего модуля должны быть настолько минимальными, насколько это возможно. Это означает, что лучше не иметь зависимостей на другие модули, но стоит стремиться к уменьшению размера вашего модуля. Например, если ваш модуль может безпроблемно работать без python-а, то удалите все скрипты на языке Python, вместо включения самого Python-а в модель и т.д.

Если ваш модуль требует каких-либо библиотек, которые необходимы только для вашего модуля, то вам следует включить такие библиотеки в сам модуль, а не загружать их по отдельности. Как пример, XFCE требует большое количество xfcelib* библиотек, которые больше нигде не требуются. Так что включите их в модуль XFCE.

С другой стороны, если для вашего модуля необходимы библиотеки, которые могут потребоваться кому-то еще, то такие библиотеки стоит загружать отдельно от самого модуля. Например, бинарные файлы Python-а должны всегда загружаться отдельно от какого-либо модуля.

 

Загрузите ваши модули


Когда ваш модуль соответствует правилам, вы можете делиться им с другими людьми. Официальный репозитарий модулей должен быть как можно более полезен для конечных пользователей; для этой цели очень важно, чтобы каждый модуль имел симпотичную иконку, скриншот, показывающий как выглядит запущенной ПО на свежем SLAX (используя стиль KDE по умолчанию), а также содержать полноценное описание, которое даст пользователям исчерпывающую информацию о модуле.

Некоторые библиотеки или программы не имеют графического пользовательского интерфейса, в этом случае скриншот не требуется. Однако должны присутствовать иконка приложения, желательно TrueColor. Модули без иконок редко принимаются. Если вы думаете, что найти иконку для вашего модуля невозможно, то подумайте еще раз. Она не должна быть уникальной, но пользователь должен отличить по иконке текстовый редактор от почтового клиента просто глянув на иконку.

Название не должено содержать все ненужные тире и подчеркивания, просто укажите название приложения, и затем номер версии. Например: vim 7.1. А так неверно: vim_7.1-112-i486-15

Описание должно быть длиной достаточно сделать взгляд обзора категории славно, но должно содержать только полезное сведение для потребителя. Значены, что описывает модуль для кто-то которое не имеет совершенно никакую идею что внутренн и что оно полезное для. Отсутствие фиктивных текстов, отсутствие соединений, отсутствие ошибок грамматики или правописания, отсутствие восклицательных знаков и отсутствие changelogs. Порекомендованная длина 40 слов или больше.

Категория: Для разработчиков | Добавил: slax (26.11.2008)
Просмотров: 8140 | Рейтинг: 0.0/0 |
Всего комментариев: 0

Имя *:
Email *:
Код *:


Copyright MyCorp © 2024
Сделать бесплатный сайт с uCoz