Ещё один отчёт с завершившегося недавно хакатона g2k14, от Марка Эспи:

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

Что до самого хакафона, я прибыл на него вскоре после крупного изменения (переупорядоченные пакеты), и был практически готов исправлять проблемы в случае необходимости. К моему удивлению, всё работало как часы... Если я что-то и сломал, то никто этого не заметил; зато всем должно понравиться ускорение процесса обновления пакетов.

После продолжительного подпинывания, Вадим Жуков таки закоммитил digikam-kde4 [порт Digikam для KDE4, - В.Ж.]. Я провёл креш-сборку и информировал его о найденных проблемах, которые он быстро исправил.

Я работал над немногочисленными мелочами... столкнулся же со многими, и исправил чуть меньше после обычного слома дерева портов, связанного с нашими бесстрашными ломателями исходников (в основном негативные последствия были из-за libressl, endian.h и обновления mesa).

Я работал над новым механизмом, обеспечивающим лучшую целостность репозиториев пакетов. Пакет "quirks" теперь сообщает о дате своего подписывания (которая в свою очередь проверяется, поэтому подделать её не получится), благодаря чему теперь можно знать, что срез пакетов достаточно свеж, или же что кто-то помешал ему попасть на ваше любимое зеркало...

... а ещё пакет "quirks" содержит в себе список уязвимых версий пакетов, благодаря чему вы получите сигнал опасности, если вам требуется обновиться из-за уязвимости в старой версии и при этом новой версии пакета на зеркале нет.

Всё это лишь уведомляет пользователя, так как срезы пакетов требуют определённого времени для расползания по зеркалам... У нас есть идеи, как побороть ЭТУ проблему, но после обсуждения с вовлечёнными сторонами было принято решение отложить внедрение до следующего релиза в связи с необходимостью чересчур серьёзных переделок.

Я также пытался решить проблему с необходимостью наличия исходных текстовой базовой ОС для сборки пакета "pkglocatedb". К моему большому удивлению, Тео согласился, и мы зашли даже дальше, чем изначально планировалось, благодаря чему снапшоты теперь будут включать locate-базы как для базовой системы, так И для иксов.

Я провёл немало времени, играя с этими базами: теперь и pkg_check использует их, позволяя проверить систему полностью. По-прежнему слишком много лишних сообщений, но прогресс налицо.

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

Ещё я должен упомянуть о отдельном cpp [препроцессоре C - прим. ред.] для calendar и xrdb, теперь иксы не потребуют для своей работы установки базового набора comp.

Как обычно, встречаться лицом к лицу собратьев по разработке очень помогло некоторым проектам продвинуться вперёд.

Спасибо OpenBSD Foundation за спонсирование этого мероприятия, а также Мите за место, всё было организовано настолько хорошо, что нам даже не приходилось о чём-то задумываться.

Знающие люди, подскажите, пожалуйста, почему в OpenBSD управление пакетами реализовано так, как реализовано. Без индекса / базы на другом конце, с запросами один за другим при обновлении?

Обновлять установленные пакеты с pkg_add -u больно и тяжко. На NetBSD и SmartOS пользовался pkgin (сверхбыстрая штука поверх sqlite) - не планируется ли в опенке такого?

Или дело, как всегда, в поддержке Vax?

а, по-моему, pkg_add - лучший пакетник, после aptitude. :) и то, потому что aptitude визуальный.

и работает у меня оно точно быстрее, чем разные штуки с индексами.

Установить 1 пакет - да, pkg_add делает это до безобразия просто и быстро. А вот обновления без индексов очень медленные, т.к. на каждый установленный пакет делается отдельный запрос к зеркалу. После pkgin / pacman и даже yum / apt на стенку лезть хочется. А ведь, пользуясь current, пакеты обновляешь все время.

Достоинства pkg_tools, на мой взгляд, - понятный интерфейс и полезные функции.

>> aptitude визуальный

Открыл я один раз UI на нём... ужаснулся и закрыл.. и теперь не открываю, пользуюсь паттернами

aptitude вообще потрясающая вещь. по заветам билла г., "информация на кончиках пальцев".

>> билла г.

Кто все эти люди?

> Знающие люди, подскажите, пожалуйста, почему в OpenBSD управление пакетами реализовано так, как реализовано. Без индекса / базы на другом конце, с запросами один за другим при обновлении?

Потому что репозиторий для OpenBSD - это просто каталог файлов. С ним банально просто и удобно работать. Любой индекс - заметное усложнение системы. Что в свою очередь усложнит жизнь и мейнтейнерам зеркал, и тем, кто собирает пакеты самостоятельно.

Можно, в принципе, сделать кеширование списка пакетов в репозитории на время pkg_add -u... Patches are welcome. ;)

> Обновлять установленные пакеты с pkg_add -u больно и тяжко. На NetBSD и SmartOS пользовался pkgin (сверхбыстрая штука поверх sqlite) - не планируется ли в опенке такого?

Обновление в OpenBSD ещё отчасти "тяжело" из-за того, что скачивается всегда пакет полностью, даже если изменилась лишь часть. Как раз во время хакатона espie@ прикрутил переупорядочивание пакетов, благодаря чему в начало пакета кладутся последние изменившиеся по сравнению с прошлыми билдами файлы, так что проблема уже частично решена. К сожалению, это пока не отменяет создание хардлинков для всех файлов уже установленного пакета во время обновления - насчёт этого есть пока лишь планы - но всё же заметный прирост заметен уже сейчас, особенно при не слишком быстром канале в Интернет.

> Можно, в принципе, сделать кеширование списка пакетов в репозитории на время pkg_add -u... Patches are welcome. ;)

Отличная идея, просто и эффективно!