19.2.4.4. Проектирование с учетом обновлений
По мере выхода новых версий, программы изменяются. Некоторые изменения обратно не совместимы. Соответственно, следует серьезно продумать проектирование схемы инсталляции, для того чтобы несколько установленных версий кода могли сосуществовать в одной системе. Это особенно важно в отношении библиотек — нельзя рассчитывать на то, что все клиентские программы будут обновляться по мере изменения вашего API-интерфейса.
Проекты Emacs, Python и Qt имеют хорошее соглашение для реализации этого принципа: каталоги с номерами версий (другой практический прием, который, вероятно, становится установившейся практикой благодаря FSF). Ниже показано, как выглядит установленная библиотека Qt (${ver} — номер версии).
/usr/lib/qt /usr/lib/qt-${ver}
/usr/lib/qt-${ver}/bin # Расположение moc
/usr/lib/qt-${ver}/lib # Расположение .so
/usr/lib/qt-${ver}/include # Расположение заголовочных файлов
При наличии такой организации сосуществование нескольких версий вполне возможно. Клиентские программы должны указывать необходимую версию библиотеки, однако это небольшая цена, которую приходится уплатить, чтобы не иметь сбоев в интерфейсах. Данная практика позволяет избежать печально известного 'ада DLL', характерного для Windows.
19.2.4.5. В Linux создавайте RPM-пакеты
Де-факто стандартным форматом для устанавливаемых бинарных пакетов в Linux является формат, используемый диспетчером пакетов Red Hat Linux, RPM (Red Hat Package manager). Он имеется в большинстве популярных дистрибутивов Linux и поддерживается фактически всеми остальными дистрибутивами (кроме Debian и Slackware; а в Debian можно устанавливать программы из RPM-пакетов). Следовательно, хорошей идеей для сайта проекта будет предоставление устанавливаемых RPM-пакетов наряду с архивами исходных кодов.
Также хорошей идеей будет включение в архив с исходным кодом файл RPM-спецификации, из которого правило в makefile позволяет создавать RPM-пакеты. Файл спецификации должен иметь расширение .spec; по данному расширению команда rpm -t обнаруживает его в архиве.
Для особых целей рекомендуется генерировать файл спецификации с shell-сценарием, который автоматически вставляет корректный номер версии, анализируя файлы makefile или version.h проекта.
Следует отметить, что в случае поставки исходных RPM-пакетов необходимо использовать тег BuildRoot, для того чтобы программа компилировалась в каталоге /tmp или /var/tmp. Если этого не сделать, то во время выполнения инсталляционной части компиляции файлы будут установлены в действительно конечный каталог. Это произойдет, даже если обнаружатся файловые коллизии, а также если пользователь вообще не хочет инсталлировать пакет. После завершения процедуры инсталляции файлы будут установлены, но в системной базе данных RPM сведения о них не появятся. Такие неверно работающие SRPM-пакеты являются 'минным полем' и их следует избегать.
19.2.4.6. Предоставляйте контрольные суммы пакетов
Сопровождайте бинарные файлы (архивы, RPM и др.) контрольными суммами. Они позволяют пользователям проверить, не повреждены ли файлы при загрузке и не содержат ли они код 'троянского коня'.
Хотя существует несколько команд, которые можно использовать с данной целью (такие как sum и cksum), лучше применить криптографически безопасную хэш- функцию. Пакет GPG предоставляет данную возможность посредством параметра --detach- sign; аналогичную работу выполняет GNU-команда md5sum.
Для каждого поставляемого бинарного пакета Web-сайт проекта должен содержать контрольную сумму и команду, которая требуется для ее генерации.
19.2.5. Практические приемы хорошей коммуникации
Программа и документация не сделают мир лучше, если никто, кроме разработчика, не знает об их существовании. Разработка визуального присутствия проекта в Internet будет способствовать привлечению пользователей и других разработчиков. Ниже описаны стандартные способы реализации данной идеи.
19.2.5.1. Публикация на сайте Freshmeat
Проект можно анонсировать на сайте Freshmeat <http://www.freshmeat.net>. Кроме того что данный сайт читают широкие круги заинтересованных лиц, группа проекта является крупным источником информации для Web-каналов технических новостей.
Не надейтесь, что аудитория читает объявления о выходе новых версий программы с момента ее появления. Всегда включайте как минимум одну строку, описывающую функции программы. Пример неудачного объявления: 'Announcing the latest release of FooEditor, now with themes and ten times faster' (Анонсируется последняя версия FooEditor, теперь с темами и работает в десять раз быстрее). Удачное объявление: 'Announcing the latest release of FooEditor, the scriptable editor for touch-typists, now with themes and ten times faster' (Анонсируется последняя версия FooEditor, редактора для профессиональных наборщиков, который можно использовать в сценариях, теперь с темами и работает в десять раз быстрее).
19.2.5.2. Публикация в соответствующих группах новостей
Найдите группу новостей Usenet, непосредственно относящуюся к разработанному приложению, и анонсируйте в ней проект. Анонсировать проект следует только там, где
Если (например) выпускается версия программы, написанной на Perl, которая опрашивает IMAP- серверы, то определенно о программе следует объявить в группе comp.mail.imap. Однако, вероятно, не следует отправлять объявление в группу comp.lang.perl, если программа не является также полезным примером передовых Perl-технологий.
Объявление должно включать в себя URL-адрес Web-сайта проекта.
