[devel] I: overlays

thecrux на gmail.com thecrux на gmail.com
Пт Дек 23 15:48:42 MSK 2011


On Fri, Dec 23, 2011 at 02:18:44PM +0400, Paul Wolneykien wrote:
> 
>   Мне кажется, что слово «оверлей» означает, что эти объекты должны
> пересекаться, т.е. частично иметь одинаковый набор пакетов — совсем как
> разные чруты в хешере разделяют один базовый набор пакетов.
>   Но можно ещё раз кратко: чем «оверлей» отличается от «компоненты»?

Наверно я путаю терминологию. Но AFAIK есть два варианта разделения монолитного
репозитория:

 * компоненты в виде такой записи в source.list:
   rpm path/to/rpms arch comp1 comp2 comp3

 * дополнительные репозитории:
   rpm path/to/repo arch comp
   rpm path/to/another/repo arch comp

Существует ли между ними большая разница (в плане работы apt) - не знаю.
Но в плане организации репозиториев разница большая.

Компоненты позволяют разбить большой репозиторий на части и пользователь
подключает только нужные ему части. Пакетная база в компонентах не
пересекается.

Дополнительные репозитории подключаются в дополнении к основному, они
несамостоятельны и требуют подключённого какого-то базового репозитория.
Кроме того они могут содержать пакеты уже имеющиеся в базовом репозитории,
но имеющие другую эпоху:версию - именно поэтому я говорю о таком
репозитории как о наложении ( overlay - перекрывать )
И в отличие от компонентного разбития, дополнительный репозиторий может
находится на другом ресурсе и быть подписан другой подписью.

> Основная претензия к компонентам, насколько мне помниться, сводилась к
> тому, что их трудно/невозможно сделать замкнутыми. В случае оверлеев это
> не так?

Кто, где и когда это говорил? Я пока не смог найти обсуждение.

Думаю в плане контроля замкнутости оверлеи и компоненты ничем не
отличаются. С другой стороны путём нихитрых манипуляций с симлинками, можно
их смержить и превратить в classic репозиторий. И проводить с ним дальше
нужные проверки.

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

>   И ещё. Как технически ты видишь процедуру разделения Сизифа на оверлеи?

Создать роботов )
Сначала прикинуть список базовых пакетов и добиться его замкнутости. Потом
обсудить список компонентов и начать их наполнение по тому же принципу,
т.е. каждый компонент имеет зависимости в себе или в базовом компоненте.
Или идти от обратного, вытаскивать пакеты по одному в отдельные компоненты.

-- 
Vladimir Lettiev aka crux ✉ theCrux на gmail.com


Подробная информация о списке рассылки Devel