240 lines
20 KiB
TeX
240 lines
20 KiB
TeX
\Title{Гудов Д.О.}{Исследование алгоритма разрешения зависимостей в ALT RPM}
|
||
|
||
\section*{Введение}
|
||
|
||
Одной из задач пакетного менеджера является проверка совместимости устанавливаемого программного обеспечения с уже имеющимися или одновременно устанавливаемыми библиотеками. Традиционная зависимость от имени библиотеки и номера её версии не всегда достаточна: отдельный экспортируемый символ может быть удалён без изменения SONAME, а библиотеки с одинаковым SONAME могут предоставлять различные программные интерфейсы. В результате формально удовлетворённая зависимость от версии ещё не гарантирует, что динамический загрузчик найдёт все символы, необходимые программе.
|
||
|
||
В ALT RPM эта задача решается при помощи специальных версий зависимостей вида \texttt{set:<encoded-set>} [\Ref{SETC}]. Для отношения \texttt{Provides} такая строка описывает множество символов, экспортируемых библиотекой, а для отношения \texttt{Requires} --- символы, требуемые программой от конкретной библиотеки. При проверке зависимости обычное сравнение версий заменяется проверкой включения множеств. Полные имена символов при этом не сохраняются: они заменяются усечёнными хеш-значениями, сортируются и кодируются в компактную строку, допустимую как версия RPM.
|
||
|
||
Цель настоящей работы --- исследовать алгоритм построения и сравнения \texttt{set:}-строк, оценить вероятностные свойства хэша и вычислительную сложность алгоритма, а также определить направления оптимизации реализации.
|
||
|
||
%% В первых разделах формализуется решаемая задача, рассматриваются реальные данные репозитория Sisyphus, формат строки и путь её построения в исходной реализации \texttt{lib/set.c}.
|
||
|
||
\section{Постановка задачи и данные ALT Linux}
|
||
\label{PROBLEM}
|
||
|
||
Пусть $P$ --- множество символов, предоставляемых библиотекой, а $R$ --- множество символов, требуемых от неё программой. Обозначим $p=|P|$ и $r=|R|$. Зависимость выполнима тогда и только тогда, когда
|
||
\[
|
||
R\subseteq P.
|
||
\]
|
||
|
||
Списки символов формируются механизмом автоматического определения зависимостей \texttt{rpm-build}. Для \texttt{Provides} из динамической таблицы библиотеки выбираются доступные извне определённые символы. Для \texttt{Requires} утилита \texttt{ldd --bindings} устанавливает соответствие между требуемым символом и конкретной библиотекой-поставщиком; слабые неопределённые символы исключаются. Таким образом, одна строка \texttt{Requires} содержит только множество, связанное с данным поставщиком.
|
||
|
||
Явное хранение имён увеличивало бы RPM-метаданные пропорционально их суммарной длине. Поэтому используется усечённая хеш-функция c целым $b$, называемого в реализации \texttt{bpp},
|
||
\[
|
||
h_b(x)=h_{32}(x)\bmod 2^b,
|
||
\qquad
|
||
H_b(S)=\{h_b(x)\mid x\in S\},
|
||
\]
|
||
где $h_{32}$ --- 32-битная функция Jenkins one-at-a-time. Фактически \texttt{lib/set.c} проверяет условие
|
||
\[
|
||
H_b(R)\subseteq H_b(P).
|
||
\]
|
||
|
||
Такое представление сохраняет включение: из $R\subseteq P$ следует $H_b(R)\subseteq H_b(P)$. Следовательно, коллизия хешей не создаёт ложного отказа для корректной зависимости. Обратное утверждение неверно: отсутствующий символ из $R\setminus P$ может получить то же усечённое значение, что и один из символов $P$, и привести к ложному принятию зависимости. Тем самым предоставляемая гарантия имеет вероятностный характер.
|
||
|
||
Для оценки реальной нагрузки был исследован срез репозитория Sisyphus для архитектур \texttt{x86\_64} и \texttt{noarch}. Объём рассмотренных метаданных на момент 2026-08-20 приведён в табл.~\Ref{CORPUS}.
|
||
|
||
\begin{table}[H]
|
||
\begin{center}
|
||
\caption{\label{CORPUS}Объём исследованного среза Sisyphus}
|
||
\small
|
||
\begin{tabular}{|l|r|}
|
||
\hline
|
||
Объект & Количество \\
|
||
\hline
|
||
Пакеты & 47\,654 \\
|
||
\hline
|
||
Отношения \texttt{Provides} с \texttt{set:}-версией & 14\,859 \\
|
||
\hline
|
||
Отношения \texttt{Requires} с \texttt{set:}-версией & 69\,153 \\
|
||
\hline
|
||
Сопоставленные пары $P,R$ & 68\,492 \\
|
||
\hline
|
||
\end{tabular}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
661 отношений удовлетворены обычным неверсионированным \texttt{Provides}.
|
||
|
||
Для каждой сопоставленной пары декодировались мощности множеств $p$ и $r$, а также вычислялось индивидуальное отношение $p/r$. Квантили этих величин показаны в табл.~\Ref{CARDINALITIES}. Квантили отношения вычислялись непосредственно по парам.
|
||
|
||
\begin{table}[H]
|
||
\begin{center}
|
||
\caption{\label{CARDINALITIES}Мощности множеств в парах \texttt{Provides}/\texttt{Requires}}
|
||
\small
|
||
\begin{tabular}{|c|r|r|r|}
|
||
\hline
|
||
Квантиль & $p$ & $r$ & $p/r$ \\
|
||
\hline
|
||
0,50 & 480 & 13 & 28,1 \\
|
||
\hline
|
||
0,75 & 1\,886 & 37 & 80 \\
|
||
\hline
|
||
0,90 & 6\,219 & 104 & 257 \\
|
||
\hline
|
||
\end{tabular}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
В 92,4\% сопоставленных пар выполняется $p/r\geq 4$. Следовательно, типичный проверяемый набор требований существенно разрежен относительно множества предоставляемых символов. Это наблюдение важно для алгоритма сравнения: последовательный симметричный просмотр двух массивов не всегда использует характерное различие их мощностей.
|
||
|
||
\section{Устройство существующей \texttt{set:}-строки}
|
||
\label{FORMAT}
|
||
|
||
Построение \texttt{set:}-строки выполняется как последовательность преобразований
|
||
\[
|
||
\begin{aligned}
|
||
\text{имена символов}
|
||
&\longrightarrow \text{усечённые хеши}
|
||
\longrightarrow \text{сортировка},\\
|
||
&\longrightarrow \text{удаление повторов и вычисление дельт},\\
|
||
&\longrightarrow \text{код Голомба--Райса}
|
||
\longrightarrow \text{Base62-представление}.
|
||
\end{aligned}
|
||
\]
|
||
Итоговая версия имеет вид
|
||
\[
|
||
\texttt{set:}\langle b\rangle\langle m\rangle\langle payload\rangle.
|
||
\]
|
||
Префикс \texttt{set:} распознаётся RPM как признак специальной версии. Следующие два символа кодируют параметры $b=\texttt{bpp}$ и $m=\texttt{Mshift}$ по правилу $c=v-7+\texttt{'a'}$. Допустимы $10\leq b\leq32$, $7\leq m\leq31$ и $m<b$. Оставшаяся часть строки содержит закодированный в \texttt{Base62} битовый поток.
|
||
|
||
\subsection{Хеширование и вероятность коллизий}
|
||
|
||
Для каждого имени вычисляется 32-битный Jenkins one-at-a-time [\Ref{JENKINS}], после чего сохраняются только $b$ младших бит. Пусть $n$ различных имён независимо и равномерно отображаются в пространство из $N=2^b$ значений. Тогда математическое ожидание числа столкнувшихся пар равно
|
||
|
||
\[
|
||
\mathbb{E}C=\binom{n}{2}\frac{1}{2^b}
|
||
=\frac{n(n-1)}{2^{b+1}},
|
||
\]
|
||
а вероятность хотя бы одной коллизии имеет вид
|
||
\[
|
||
\P(C>0)=1-\prod_{i=0}^{n-1}\left(1-\frac{i}{2^b}\right)
|
||
\approx 1-\exp\left(-\frac{n(n-1)}{2^{b+1}}\right).
|
||
\]
|
||
Эти выражения являются модельными: Jenkins OAAT не является случайным оракулом, поэтому окончательная оценка должна дополняться измерением коллизий на реальном корпусе символов.
|
||
|
||
Эвристическую верхнюю оценку ложного принятия при $k=|R\setminus P|$ отсутствующих символов можно записать как
|
||
\[
|
||
\Pr\bigl(H_b(R)\subseteq H_b(P)\mid R\nsubseteq P\bigr)
|
||
\lesssim
|
||
\left(\frac{|H_b(P)|}{2^b}\right)^k.
|
||
\]
|
||
Увеличение $b$ снижает вероятность ошибки, но увеличивает кодируемые значения и длину строки. Поэтому выбор \texttt{bpp} представляет собой компромисс между компактностью метаданных и риском коллизий; при формировании \texttt{set:}-строки для \texttt{Requires} набора используется точность, определённая по числу символов соответствующего \texttt{Provides}, а не по обычно намного меньшему числу требований.
|
||
|
||
\subsection{Кодирование Голомба--Райса}
|
||
|
||
После сортировки уникальных значений
|
||
\[
|
||
0\leq x_1<x_2<\dots<x_n<2^b
|
||
\]
|
||
они заменяются дельтами
|
||
\[
|
||
\delta_1=x_1,
|
||
\qquad
|
||
\delta_i=x_i-x_{i-1},\quad i=2,\dots,n.
|
||
\]
|
||
Для равномерных хешей средний промежуток имеет порядок $2^b/n$, поэтому дельты значительно меньше абсолютных значений и хорошо подходят для кодирования Голомба--Райса [\Ref{GOLOMB-RICE}].
|
||
|
||
В реализации модуль $M$ равен степени двойки $M=2^m$. Для каждой дельты вычисляются
|
||
\[
|
||
q_i=\left\lfloor\frac{\delta_i}{M}\right\rfloor,
|
||
\qquad
|
||
r_i=\delta_i\bmod M.
|
||
\]
|
||
Частное $q_i$ записывается унарно как $q_i$ нулей и завершающая единица, после которой следуют $m$ младших бит остатка $r_i$. Длина кода одного значения равна
|
||
\[
|
||
\ell_i=q_i+1+m.
|
||
\]
|
||
Параметр выбирается приближённо как
|
||
\[
|
||
m=b-\lfloor\log_2 n\rfloor-1
|
||
\]
|
||
и ограничивается диапазоном формата $7\leq m\leq31$. При принятой модели суммарная длина битового потока оценивается как
|
||
\[
|
||
B=\sum_{i=1}^{n}\ell_i
|
||
=O\!\left(n\left(1+\log_2\frac{2^b}{n}\right)\right).
|
||
\]
|
||
|
||
\subsection{Base62-представление}
|
||
|
||
Битовый поток нельзя непосредственно поместить в поле версии RPM: необходима строка из допустимых символов. Исходная реализация использует алфавит \texttt{0--9}, \texttt{a--z}, \texttt{A--Z}. Значения от 0 до 60 записываются обычным символом, а \texttt{Z} служит escape-символом и позволяет представить также шестибитные значения 61, 62 и 63. Их различают два старших бита следующего символа: \texttt{00}, \texttt{01} или \texttt{10}. Комбинация \texttt{11} не используется, поэтому escape-последовательности не могут образовать неоднозначную цепочку. Вследствие этого один символ несёт от пяти до шести бит, и длина текстовой части приближённо пропорциональна $B/6$.
|
||
|
||
Рассмотрим небольшой пример с $b=10$. Для пяти имён Jenkins OAAT после усечения даёт значения, приведённые в табл.~\Ref{ENCODING_EXAMPLE}.
|
||
|
||
\begin{table}[H]
|
||
\begin{center}
|
||
\caption{\label{ENCODING_EXAMPLE}Пример хеширования символов при $b=10$}
|
||
\small
|
||
\begin{tabular}{|l|r|r|}
|
||
\hline
|
||
Символ & 32-битный хеш & $h_{10}$ \\
|
||
\hline
|
||
\texttt{fclose} & \texttt{0x6743def6} & 758 \\
|
||
\hline
|
||
\texttt{fopen} & \texttt{0x0e984918} & 280 \\
|
||
\hline
|
||
\texttt{free} & \texttt{0xa5bbbac7} & 711 \\
|
||
\hline
|
||
\texttt{malloc} & \texttt{0x07c1b8ff} & 255 \\
|
||
\hline
|
||
\texttt{printf} & \texttt{0xfd1ad5cc} & 460 \\
|
||
\hline
|
||
\end{tabular}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
После сортировки получается массив $(255,280,460,711,758)$, а после вычисления разностей --- $(255,25,180,251,47)$. Для $n=5$ формула даёт $m=7$; полученный 43-битный поток преобразуется в payload \texttt{ZvpACXZy}. Параметрам $b=10$ и $m=7$ соответствуют заголовочные символы \texttt{d} и \texttt{a}, поэтому итоговая строка равна \texttt{set:daZvpACXZy}.
|
||
|
||
\section{Построение \texttt{set:}-строк в \texttt{set.c}}
|
||
\label{CONSTRUCTION}
|
||
|
||
Благодаря сценариям автозависимостей \texttt{rpm-build} утилита \texttt{mkset} получает символы из ELF-файлов и далее импользует \texttt{lib/set.c}, вызывая интерфейс построения множества:
|
||
\[
|
||
\texttt{set\_new()}\ \longrightarrow\
|
||
\texttt{set\_add()}\ \longrightarrow\
|
||
\texttt{set\_fini()}.
|
||
\]
|
||
|
||
Функция \texttt{set\_new()} создаёт пустую структуру \texttt{struct set}. В исходной реализации она представляет собой растущий массив пар «указатель на строку --- хеш». Функция \texttt{set\_add()} увеличивает ёмкость массива блоками по 1024 элемента и копирует каждое имя отдельным вызовом \texttt{xstrdup()}. На этом этапе хеши ещё не вычисляются, поэтому один объект можно финализировать с заданным значением \texttt{bpp}.
|
||
|
||
Основную работу выполняет \texttt{set\_fini()}. Её действия следуют в фиксированном порядке:
|
||
\begin{enumerate}
|
||
\item проверяется непустота множества и условие $10\leq b\leq32$;
|
||
\item для каждого имени вычисляется Jenkins OAAT и применяется маска из $b$ младших бит;
|
||
\item массив пар сортируется стандартной функцией \texttt{qsort()} по хеш-значению;
|
||
\item для равных хешей различных имён выводится предупреждение о коллизии;
|
||
\item хеши копируются в числовой массив, а повторяющиеся значения удаляются;
|
||
\item массив кодируется последовательно как дельты, код Голомба--Райса и Base62;
|
||
\item сформированная строка копируется в динамическую память и возвращается вызывающей стороне.
|
||
\end{enumerate}
|
||
|
||
Удаление повторов необходимо в двух случаях. Во-первых, одно имя может несколько раз попасть во входной поток. Во-вторых, различные имена могут совпасть после усечения хеша. Для семантики $H_b(S)$ оба случая означают один элемент множества. При этом предупреждение о коллизии формируется до удаления повторов, пока реализации ещё доступны исходные строки и можно различить совпадение имён от совпадения их хешей.
|
||
|
||
Оценим вычислительную сложность. Пусть $L$ --- суммарная длина всех входных имён, $n$ --- их количество, а $B$ --- длина потока Голомба--Райса в битах. Хеширование требует $O(L)$ операций, сортировка --- $O(n\log n)$ сравнений, линейные проходы сортированного массива --- $O(n)$, кодирование --- $O(B)$. Поэтому для исходного варианта
|
||
\[
|
||
T_{\mathrm{build}}=O(L)+O(n\log n)+O(B).
|
||
\]
|
||
Хранимые копии строк, массив пар, массив уникальных хешей, битовый буфер и результирующая строка дают дополнительную память порядка
|
||
\[
|
||
M_{\mathrm{build}}=O(L+n+B).
|
||
\]
|
||
Главным асимптотическим слагаемым для больших наборов остаётся \texttt{qsort()}, тогда как большое число отдельных копирований строк и наличие промежуточного битового массива влияют на постоянные затраты. Это определяет два независимых направления дальнейшего улучшения: замена сортировки для крупных множеств и потоковое кодирование без промежуточных представлений. При этом любые изменения должны сохранять байтовую совместимость формата.
|
||
|
||
\References
|
||
\begin{enumerate}
|
||
\item
|
||
\Label{SETC}
|
||
Tourbin A.
|
||
\emph{set.c --- base62, Golomb and set-string routines}.
|
||
ALT RPM source code, 2010--2012.
|
||
[Электронный ресурс] URL: \url{https://git.altlinux.org/gears/r/rpm.git?a=blob;f=lib/set.c}.
|
||
|
||
\item
|
||
\Label{JENKINS}
|
||
|
||
\item
|
||
\Label{GOLOMB-RICE}
|
||
|
||
\end{enumerate}
|