[devel] Разделение репозитория

[devel] Разделение репозитория

[Андрей Черепанов]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

Рискую оказаться банальным, но хочу поднять вопрос о разделении classic на 
набор дистрибутивов/компонентов. Как минимум, народ с форума желает выделить 
игры отдельно 
(http://forum.altlinux.org/index.php/topic,10910.msg0/topicseen.html). Раз 
отделили p6/t6, может, вернёмся к обсуждению? Дело, как понимаю, в доточке 
наших скриптов сборочницы?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Разделение репозитория

[Yury A. Romanov]

On 06/21/2011 04:54 PM, Андрей Черепанов wrote:
> Рискую оказаться банальным, но хочу поднять вопрос о разделении classic на 
> набор дистрибутивов/компонентов. Как минимум, народ с форума желает выделить 
> игры отдельно 
> (http://forum.altlinux.org/index.php/topic,10910.msg0/topicseen.html). Раз 
> отделили p6/t6, может, вернёмся к обсуждению? Дело, как понимаю, в доточке 
> наших скриптов сборочницы?

Нет, Андрей, помимо скриптов сборочницы есть вопрос о целесообразности
существования таких репозитариев.

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

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

Re: [devel] Разделение репозитория

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 1820 bytes --]

21 июня 2011 Yury A. Romanov написал:
> On 06/21/2011 04:54 PM, Андрей Черепанов wrote:
> > Рискую оказаться банальным, но хочу поднять вопрос о разделении classic
> > на набор дистрибутивов/компонентов. Как минимум, народ с форума желает
> > выделить игры отдельно
> > (http://forum.altlinux.org/index.php/topic,10910.msg0/topicseen.html).
> > Раз отделили p6/t6, может, вернёмся к обсуждению? Дело, как понимаю, в
> > доточке наших скриптов сборочницы?
> 
> Нет, Андрей, помимо скриптов сборочницы есть вопрос о целесообразности
> существования таких репозитариев.
>
> Вообще понятие "компоненты/дистрибутивы" в терминах apt было сделано для
> разделения множества пакетов на группы по критерию свободно/несвободно
> для того, чтобы больные жепеэлием головного мозга могли отключить
> ненавистные им проприетарные пакеты и не мешать нормальным людям.
В отличие от Debian apt-rpm обладает очень неприятным эффектом резко 
возрастающих объёмов и скорости чтения индексов. На нынешнем Сизифе это 
особенно заметно. 

Для обновления дистрибутивов нужно порядка ~4 тыс. пакетов (из 30027 в Сизифе, 
13%). Индексы размером 15,4 МБ (против 4,7 МБ в p5) утроили (!) время загрузки 
и чтения. Я уж не говорю, что много по городам и весям СНГ обладателей слабых 
каналов что для единоличного обновления, что для зеркал. С наплевательским к 
ним отношением далеко мы не уедем.
 
> Для задачи сокращения объёма скачиваемого репозитария скорее всего нужно
> средство, которое позволяет синхронизировать всё множество установленных
> пакетов, либо пакетов по группам.
То есть проблема чисто организационная? Можно составить списки включаемых 
пакетов по именам и группам RPM/cекциям APT, а также исключениям из общих 
правил. Тогда распределение по компонентам можно автоматизировать.

--
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Разделение репозитория

[Yury A. Romanov]

On 06/21/2011 11:22 PM, Андрей Черепанов wrote:
> 21 июня 2011 Yury A. Romanov написал:
>> On 06/21/2011 04:54 PM, Андрей Черепанов wrote:
>>> Рискую оказаться банальным, но хочу поднять вопрос о разделении classic
>>> на набор дистрибутивов/компонентов. Как минимум, народ с форума желает
>>> выделить игры отдельно
>>> (http://forum.altlinux.org/index.php/topic,10910.msg0/topicseen.html).
>>> Раз отделили p6/t6, может, вернёмся к обсуждению? Дело, как понимаю, в
>>> доточке наших скриптов сборочницы?
>>
>> Нет, Андрей, помимо скриптов сборочницы есть вопрос о целесообразности
>> существования таких репозитариев.
>>
>> Вообще понятие "компоненты/дистрибутивы" в терминах apt было сделано для
>> разделения множества пакетов на группы по критерию свободно/несвободно
>> для того, чтобы больные жепеэлием головного мозга могли отключить
>> ненавистные им проприетарные пакеты и не мешать нормальным людям.
> В отличие от Debian apt-rpm обладает очень неприятным эффектом резко 
> возрастающих объёмов и скорости чтения индексов. На нынешнем Сизифе это 
> особенно заметно. 
Такова цена целостности репозитория. Собственно, репозиторий убунту куда
менее устойчив к разломам при смене версий библиотек.

> Для обновления дистрибутивов нужно порядка ~4 тыс. пакетов (из 30027 в Сизифе, 
> 13%). Индексы размером 15,4 МБ (против 4,7 МБ в p5) утроили (!) время загрузки 
> и чтения. Я уж не говорю, что много по городам и весям СНГ обладателей слабых 
> каналов что для единоличного обновления, что для зеркал. С наплевательским к 
> ним отношением далеко мы не уедем.
>  
>> Для задачи сокращения объёма скачиваемого репозитария скорее всего нужно
>> средство, которое позволяет синхронизировать всё множество установленных
>> пакетов, либо пакетов по группам.
> То есть проблема чисто организационная? Можно составить списки включаемых 
> пакетов по именам и группам RPM/cекциям APT, а также исключениям из общих 
> правил. Тогда распределение по компонентам можно автоматизировать.
> 
Вопрос тут примерно следующий: как будет обеспечиваться контроль
целостности каждого из этих огрызков сизифа?
Т.е., например, ставит некто текущий дистрибутив, решает обновляться до
сизифа, смотрит на список компонентов и говорит "чозаlibнах?" и
отключает. В результате система у него не ставится и не работает. Куда
он побежит? Правильно, срать на форумах "какое альтлинукс г..."

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

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

Вообще для того, чтобы не качать игры, можно использовать --exclude
"-data" (большинство игр имеют размер 10-15 мегабайт, а данные от них
дотягивают до гигабайта).

Re: [devel] Разделение репозитория

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 1923 bytes --]

21 июня 2011 Yury A. Romanov написал:
> Вопрос тут примерно следующий: как будет обеспечиваться контроль
> целостности каждого из этих огрызков сизифа?
> Т.е., например, ставит некто текущий дистрибутив, решает обновляться до
> сизифа, смотрит на список компонентов и говорит "чозаlibнах?" и
> отключает. В результате система у него не ставится и не работает. Куда
> он побежит? Правильно, срать на форумах "какое альтлинукс г..."
Во-первых, это решается распределением в дополнительные репозитории конечных 
"листьев", а не узловых (зависимых) пакетов. В качестве конечных пакетов, от 
которых ничего не зависит, могут выступать прикладные приложения (те же игры, 
к примеру).
Во-вторых, я не встречал особых воплей по поводу недоподключения компонентов в 
Debian/Ubuntu. В отличие от набившего оскомину непонимания неофитами 
разделения на i586 и noarch (что, кстати, вызвало больше криков, чем 
необязательные репозитории).
 
> Вопрос номер два - если целостность каждого из "репозиториев"
> обеспечена, как бороться с индексами, которых теперь стало несколько и
> имеющих дублированные пакеты?
Количество дублированных пакетов в индексах на конечных листьях будет 
минимальным и даже не стоит рассматривать.

> Поэтому скорее нужно средство, которое делает примерно следующее:
> подгружает индексы, берёт список пакетов (требуемый|системный или по
> категориям), строит дерево зависимостей, и скачивает все пакеты,
> потянутые по зависимостям из других категорий, потом создаёт локальные
> индексы.
Идея хорошая, но я не вижу героя, который перепишет apt-rpm для подобной 
реакции.

> Вообще для того, чтобы не качать игры, можно использовать --exclude
> "-data" (большинство игр имеют размер 10-15 мегабайт, а данные от них
> дотягивают до гигабайта).
Это кондовое решение, могущее привести к экономии места, но и к риску 
ненахождения файла (той же неконсистентности).

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Разделение репозитория

[Yury A. Romanov]

On 06/22/2011 12:03 AM, Андрей Черепанов wrote:
> 21 июня 2011 Yury A. Romanov написал:
>> Вопрос тут примерно следующий: как будет обеспечиваться контроль
>> целостности каждого из этих огрызков сизифа?
>> Т.е., например, ставит некто текущий дистрибутив, решает обновляться до
>> сизифа, смотрит на список компонентов и говорит "чозаlibнах?" и
>> отключает. В результате система у него не ставится и не работает. Куда
>> он побежит? Правильно, срать на форумах "какое альтлинукс г..."
> Во-первых, это решается распределением в дополнительные репозитории конечных 
> "листьев", а не узловых (зависимых) пакетов. В качестве конечных пакетов, от 
> которых ничего не зависит, могут выступать прикладные приложения (те же игры, 
> к примеру).
> Во-вторых, я не встречал особых воплей по поводу недоподключения компонентов в 
> Debian/Ubuntu. В отличие от набившего оскомину непонимания неофитами 
> разделения на i586 и noarch (что, кстати, вызвало больше криков, чем 
> необязательные репозитории).
>  
>> Вопрос номер два - если целостность каждого из "репозиториев"
>> обеспечена, как бороться с индексами, которых теперь стало несколько и
>> имеющих дублированные пакеты?
> Количество дублированных пакетов в индексах на конечных листьях будет 
> минимальным и даже не стоит рассматривать.
> 
>> Поэтому скорее нужно средство, которое делает примерно следующее:
>> подгружает индексы, берёт список пакетов (требуемый|системный или по
>> категориям), строит дерево зависимостей, и скачивает все пакеты,
>> потянутые по зависимостям из других категорий, потом создаёт локальные
>> индексы.
> Идея хорошая, но я не вижу героя, который перепишет apt-rpm для подобной 
> реакции.
apt-rpm это умеет. К нему достаточно написать какую-то обёртку.
Собственно, параметр --download-only скачивает пакеты, предварительно
считая зависимости. По идее, надо бы ещё сделать какой-то список
обязательных пакетов, которые не тянутся по умолчанию, но без которых
система не работает (например, ядра) и выполнить genbasedir на
загруженных пакетах из кеша.

> 
>> Вообще для того, чтобы не качать игры, можно использовать --exclude
>> "-data" (большинство игр имеют размер 10-15 мегабайт, а данные от них
>> дотягивают до гигабайта).
> Это кондовое решение, могущее привести к экономии места, но и к риску 
> ненахождения файла (той же неконсистентности).
> 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Разделение репозитория

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 2733 bytes --]

Здравствуйте Андрей Черепанов
  В сообщении от 21 июня 2011 Андрей Черепанов написал(a):
> То есть проблема чисто организационная? Можно составить списки
> включаемых пакетов по именам и группам RPM/cекциям APT, а
> также исключениям из общих правил. Тогда распределение по
> компонентам можно автоматизировать.
Нужно чётко сформулировать цель, которую мы хотим добиться. 
Исходя из неё можно уже формулировать критерии и ограничения, 
которые будут правильно отражать эту цель, а потом уже можно и 
автоматизировать.
Т.е 
1. Фраза, чётко формулирующая цель. Если целей несколько, то 
второстепенные цели надо формулировать, как ограничения.
2. Критерии и ограничения, накладываемые на репозиторий.
3. Методы автоматизации.

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

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

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

-- 
  А ещё говорят так  (fortune):
 
The static electricity routing is acting up... 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Разделение репозитория

[Sergei Epiphanov]

В сообщении от 21 июня 2011 23:49:36 автор Hihin Ruslan написал:
> С теорией покончили. Переходим к практике.
> Основная цель  - уменьшить трафик пользователей при обновлении.
> Второстепенные цели 
> - уменьшить индексы репозитория.
> - выделить пакеты, типа игр или дизайна, которые не влияют на 
> работу дистрибутивов, и обновление которых не обязательно

Первым делом отделите debuginfo-пакеты от основных. Подавляющему числу 
_пользователей_ debuginfo только мешают. (Или я ошибаюсь? Интересно, как часто 
они требуются и сколько debuginfo-пакетов в среднем требуется для решения 
задачи?)

Текущий Sisyphus (основные пакеты - debuginfo-пакеты):
arm: 19,5ГБ (18283 файла) - 2,6ГБ(3212 файлов)
i586: 7,4ГБ (13956 файлов) - 6,7ГБ (5493 файла)
x86_64: 7,5ГБ (13860 файлов) - 6,9ГБ (5487 файлов)

Нетрудно заметить, что debuginfo-пакеты в среднем в 2-3 раза больше основных 
(из наиболее впечатляющих xulrunner и vegastrike). При изменении структуры 
программы (в смысле деления на пакеты) или при появлении каких-либо плагинов 
так и подмывает использовать регулярные выражения для поиска и 
автоматизированной установки, а с debuginfo на закорках приходится с apt-get 
уходить на apt-shell и делать несколько лишних телодвижений.

-- 
С уважением, Епифанов Сергей

Re: [devel] Разделение репозитория

[Motsyo Gennadi aka Drool]

Sergei Epiphanov пишет:
> Первым делом отделите debuginfo-пакеты от основных. Подавляющему числу 
> _пользователей_ debuginfo только мешают. (Или я ошибаюсь? Интересно, как часто 
> они требуются и сколько debuginfo-пакетов в среднем требуется для решения 
> задачи?)
> 
> Текущий Sisyphus (основные пакеты - debuginfo-пакеты):
> arm: 19,5ГБ (18283 файла) - 2,6ГБ(3212 файлов)
> i586: 7,4ГБ (13956 файлов) - 6,7ГБ (5493 файла)
> x86_64: 7,5ГБ (13860 файлов) - 6,9ГБ (5487 файлов)

	Много раз +1 !

Re: [devel] Разделение репозитория

[Michael Shigorin]

On Tue, Jun 21, 2011 at 10:33:26PM +0400, Yury A. Romanov wrote:
> Нет, Андрей, помимо скриптов сборочницы есть вопрос
> о целесообразности существования таких репозитариев.

Юрий, если Вы лично не застали предыдущие обсуждения (а это,
очевидно, именно так) -- то потрудитесь вместо дешёвого яда
потратить время на чтение архивов по словам RPMS.media,
RPMS.games, RPMS.contrib.

И да, к старым хотелкам стоит добавить RPMS.debug.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[devel] VisIt

[Valery Pipin]

Отличный пакет визуализации и научной графики
https://wci.llnl.gov/codes/visit/

Re: [devel] VisIt

[REAL]

23.06.2011 00:26, Valery Pipin пишет:
> Отличный пакет визуализации и научной графики
> https://wci.llnl.gov/codes/visit/

Отличный, но у меня до него руки так и не дошли. На него нужно много 
времени (на опакечивание), а я же сейчас несколько другими задачами 
занимаюсь.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] VisIt

[Valery Pipin]

Ну я попробую черновик собрать на досуге
> 23.06.2011 00:26, Valery Pipin пишет:
>> Отличный пакет визуализации и научной графики
>> https://wci.llnl.gov/codes/visit/
>
> Отличный, но у меня до него руки так и не дошли. На него нужно много 
> времени (на опакечивание), а я же сейчас несколько другими задачами 
> занимаюсь.
>