[devel] kill Sisyphus noarch?

[devel] kill Sisyphus noarch?

[Igor Vlasenko]

Уважаемые коллеги,
Что если оставить разбивку 
на x86_64 noarch и i586 в files,
но симлинки из noarch бросать и в x86_64 и в i586?

на уровне репозитариев оставить только
i586/RPMS.classic
и x86_64/RPMS.classic.

noarch/RPMS.classic тоже останется, пустой, для совместимости.

Иначе нас захлестнет вал проблем наподобие
https://bugzilla.altlinux.org/show_bug.cgi?id=17674

Ведь сейчас с помощью BuildArch: noarch
можно добиться, что даже из одного srpm пакета
часть собранных уйдет в arch, а часть - в noarch.

А наш apt клинит на межрепозитарных Req/Prov/Obsoletes/Conflicts.
(Как я понимаю ситуацию).

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 12:16:54 26.10.2008 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

 IV> Иначе нас захлестнет вал проблем наподобие
 IV> https://bugzilla.altlinux.org/show_bug.cgi?id=17674

Кроме того, это сильно уменьшит количетсво недоуменных юзерских
вопросов. Отдельный noarch в sources.list - это постоянный источник
проблем.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Igor Vlasenko]

On Sun, Oct 26, 2008 at 12:16:54PM +0200, Igor Vlasenko wrote:
> на уровне репозитариев оставить только
> i586/RPMS.classic
> и x86_64/RPMS.classic.

Заодно решится проблема рассинхронизации архитектур.
Например, 
под i586 собралась boo-2.0, под x86_64 осталась boo-1.0
имеем:
files/i586
boo-2.0
files/x86_64
boo-1.0
files/noarch
boo-data-1.0
boo-data-2.0

Но в репозитарий кладем ссылки 
в соответствии с архитектурой основного пакета:
i586/RPMS.classic
boo-2.0.i586
boo-data-2.0.noarch
x86_64/RPMS.classic
boo-1.0.x86_64
boo-data-1.0.noarch




-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 04:20:44PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 12:16:54 26.10.2008 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
> 
>  IV> Иначе нас захлестнет вал проблем наподобие
>  IV> https://bugzilla.altlinux.org/show_bug.cgi?id=17674
> 
> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
> вопросов. Отдельный noarch в sources.list - это постоянный источник
> проблем.

customers suck

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 15:02:50 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 >> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
 >> вопросов. Отдельный noarch в sources.list - это постоянный источник
 >> проблем.

 AT> customers suck

Напомни себе, кто является источником твоей "стипендии".

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 12:26:43PM +0200, Igor Vlasenko wrote:
> On Sun, Oct 26, 2008 at 12:16:54PM +0200, Igor Vlasenko wrote:
> > на уровне репозитариев оставить только
> > i586/RPMS.classic
> > и x86_64/RPMS.classic.
> 
> Заодно решится проблема рассинхронизации архитектур.

Проблема рассинхронизации архитектур решается недопущением
рассинхронизации архитектур.

> Например, 
> под i586 собралась boo-2.0, под x86_64 осталась boo-1.0
> имеем:
> files/i586
> boo-2.0
> files/x86_64
> boo-1.0
> files/noarch
> boo-data-1.0
> boo-data-2.0

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 06:04:51PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 15:02:50 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  >> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
>  >> вопросов. Отдельный noarch в sources.list - это постоянный источник
>  >> проблем.
> 
>  AT> customers suck
> Напомни себе, кто является источником твоей "стипендии".

Про меня ещё говорили, что "Турбин ничего не делает и получает за это
деньги".  По-моему, неплохо.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 04:20:44PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 12:16:54 26.10.2008 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
> 
>  IV> Иначе нас захлестнет вал проблем наподобие
>  IV> https://bugzilla.altlinux.org/show_bug.cgi?id=17674
> 
> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
> вопросов. Отдельный noarch в sources.list - это постоянный источник
> проблем.

А как удостоверться, что это постоянный источник проблем?  По-моему,
разделение репозитария на $arch и noarch комоненты вполне естественно.
Первая копонента содержит *.$arch.rpm пакеты, вторая -- *.noarch.rpm.
Не понимаю, какая тут почва для недоумения.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 15:27:19 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 >> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
 >> вопросов. Отдельный noarch в sources.list - это постоянный источник
 >> проблем.

 AT> А как удостоверться, что это постоянный источник проблем?

Подсчётом вопросов в рассылках типа community.

 AT> По-моему, разделение репозитария на $arch и noarch комоненты вполне
 AT> естественно.  Первая копонента содержит *.$arch.rpm пакеты, вторая
 AT> -- *.noarch.rpm.  Не понимаю, какая тут почва для недоумения.

По-моему, отсутствие разделения репозитория на $arch и noarch компоненты
вполне естественно. Один репозиторий для каждой поддерживаемой
архитектуры.

Не понимаю, какая тут почва для переусложнения.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 06:29:34PM +0600, Mikhail Gusarov wrote:
>  >> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
>  >> вопросов. Отдельный noarch в sources.list - это постоянный источник
>  >> проблем.
> 
>  AT> А как удостоверться, что это постоянный источник проблем?
> Подсчётом вопросов в рассылках типа community.

Я помню только один тред, что недавно кто-то подключил noarch,
но не подключил $arch.  Тогда как более логичной ошибкой было бы
подключить $arch, а забыть подключить noarch.

>  AT> По-моему, разделение репозитария на $arch и noarch комоненты вполне
>  AT> естественно.  Первая копонента содержит *.$arch.rpm пакеты, вторая
>  AT> -- *.noarch.rpm.  Не понимаю, какая тут почва для недоумения.
> 
> По-моему, отсутствие разделения репозитория на $arch и noarch компоненты
> вполне естественно. Один репозиторий для каждой поддерживаемой
> архитектуры.
> 
> Не понимаю, какая тут почва для переусложнения.

Разделение на $arch и noarch компоненты придумал не я, и оно существует
очень давно (примерно с 2005-03-23).  Есть свои за и против.  Мне больше
всего не нравится то, что каждая компонента в отдельности является
заведомо незамкнутым репозитарием (из каждой компоненты торчит большое
количество анметов, которые разрешаются в другую компоненту).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 15:41:59 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Я помню только один тред, что недавно кто-то подключил noarch, но
 AT> не подключил $arch. Тогда как более логичной ошибкой было бы
 AT> подключить $arch, а забыть подключить noarch.

Несколько веток на форуме, в IRC неоднократно всплывало, и, если не
ошибаюсь, даже в багзилле - вешали баг на отсутствующую зависимость при
отключенном noarch.

 AT> Разделение на $arch и noarch компоненты придумал не я, и оно
 AT> существует очень давно (примерно с 2005-03-23).

Это можно не принимать во внимание.

 AT> Есть свои за и против. 

А можно озвучить "за", кроме (совершенно неинтересных) вопросов
удобства/неудобства реализации?

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 06:46:44PM +0600, Mikhail Gusarov wrote:
>  AT> Есть свои за и против. 
> 
> А можно озвучить "за", кроме (совершенно неинтересных) вопросов
> удобства/неудобства реализации?

То, что первым делом приходит в голову -- если влить в каждый
архитектурный репозитарий noarch компоненту, то она будет дублироваться.
Это экономия минимум 2M при синхронизации сизифа для двух архитектур,
а максимум -- 82M (du -hs /ALT/Sisyphus/noarch/base).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 15:52:53 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> То, что первым делом приходит в голову -- если влить в каждый
 AT> архитектурный репозитарий noarch компоненту, то она будет
 AT> дублироваться.  Это экономия минимум 2M при синхронизации сизифа
 AT> для двух архитектур,

 AT> а максимум -- 82M (du -hs /ALT/Sisyphus/noarch/base).

contents_index изжить надо (как мы уже обсуждали), и тогда это
неудобство по большей части рассосётся - 2M уже не важно.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Sergey Bolshakov]

>>>>> "Mikhail" == Mikhail Gusarov <dottedmag-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > Twas brillig at 12:16:54 26.10.2008 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
 IV> Иначе нас захлестнет вал проблем наподобие
 IV> https://bugzilla.altlinux.org/show_bug.cgi?id=17674

 > Кроме того, это сильно уменьшит количетсво недоуменных юзерских
 > вопросов. Отдельный noarch в sources.list - это постоянный источник
 > проблем.

Юзеры имеют дело с сущностями вроде base, disk и updates.
Если некто правит sources.list на бранч или сизиф --
делает это на свой собственный страх и риск.
Обсуждать тут нечего.

-- 

Re: [devel] kill Sisyphus noarch?

[Sergey Bolshakov]

>>>>> "Mikhail" == Mikhail Gusarov <dottedmag-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > Twas brillig at 15:02:50 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
 >>> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
 >>> вопросов. Отдельный noarch в sources.list - это постоянный источник
 >>> проблем.

 AT> customers suck

 > Напомни себе, кто является источником твоей "стипендии".
Сделай милость, не демонстрируй прилюдно интерес к источнику
наполнения чужих карманов.

-- 

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 16:22:40 26.10.2008 UTC+03 when sbolshakov@altlinux.ru did gyre and gimble:

 >> Напомни себе, кто является источником твоей "стипендии".

 SB> Сделай милость, не демонстрируй прилюдно интерес к источнику
 SB> наполнения чужих карманов.

Будь добр, не выплёскивай свои неверные интерпретации в рассылку.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 16:20:49 26.10.2008 UTC+03 when sbolshakov@altlinux.ru did gyre and gimble:

 SB> Юзеры имеют дело с сущностями вроде base, disk и updates.

http://www.altlinux.org/Репозитории_ALT_Linux

Какова логика присутствия noarch везде, кроме updates?

 SB> Если некто правит sources.list на бранч или сизиф -- делает это на
 SB> свой собственный страх и риск.

На сизиф - да. На бранч - нет. Отправляю к rider'у.

 SB> Обсуждать тут нечего.

Конечно, чем больше граблей разложено, тем меньше юзеров, тем меньше
беспокойства.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Anton Farygin]

Alexey Tourbin пишет:
> On Sun, Oct 26, 2008 at 06:29:34PM +0600, Mikhail Gusarov wrote:
<skip>
>> Не понимаю, какая тут почва для переусложнения.
> 
> Разделение на $arch и noarch компоненты придумал не я, и оно существует
> очень давно (примерно с 2005-03-23).  Есть свои за и против.  Мне больше
> всего не нравится то, что каждая компонента в отдельности является
> заведомо незамкнутым репозитарием (из каждой компоненты торчит большое
> количество анметов, которые разрешаются в другую компоненту).

+1. Мне именно это жутко досаждает. Всё остальное - обучаемо. Но 
репозитарии, IMHO, должны быть замкнуты.

Re: [devel] kill Sisyphus noarch?

[Anton Farygin]

Sergey Bolshakov пишет:
>>>>>> "Mikhail" == Mikhail Gusarov <dottedmag-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:
> 
>  > Twas brillig at 12:16:54 26.10.2008 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:
>  IV> Иначе нас захлестнет вал проблем наподобие
>  IV> https://bugzilla.altlinux.org/show_bug.cgi?id=17674
> 
>  > Кроме того, это сильно уменьшит количетсво недоуменных юзерских
>  > вопросов. Отдельный noarch в sources.list - это постоянный источник
>  > проблем.
> 
> Юзеры имеют дело с сущностями вроде base, disk и updates.
> Если некто правит sources.list на бранч или сизиф --
> делает это на свой собственный страх и риск.
> Обсуждать тут нечего.

Неправда. Стандартный источник _дополнительных_ программ к дистрибутиву 
- branch. Пользователям рекомендуют после установки основной системы 
именно оттуда брать всё, что нужно дополнительного.

Re: [devel] kill Sisyphus noarch?

[Kirill A. Shutemov]

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

On Sun, Oct 26, 2008 at 06:29:34PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 15:27:19 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  >> Кроме того, это сильно уменьшит количетсво недоуменных юзерских
>  >> вопросов. Отдельный noarch в sources.list - это постоянный источник
>  >> проблем.
> 
>  AT> А как удостоверться, что это постоянный источник проблем?
> 
> Подсчётом вопросов в рассылках типа community.
> 
>  AT> По-моему, разделение репозитария на $arch и noarch комоненты вполне
>  AT> естественно.  Первая копонента содержит *.$arch.rpm пакеты, вторая
>  AT> -- *.noarch.rpm.  Не понимаю, какая тут почва для недоумения.
> 
> По-моему, отсутствие разделения репозитория на $arch и noarch компоненты
> вполне естественно. Один репозиторий для каждой поддерживаемой
> архитектуры.
> 
> Не понимаю, какая тут почва для переусложнения.

Ну, к примеру, намного проще портировать на новые архитектуры.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 16:42:48 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:

 KAS> Ну, к примеру, намного проще портировать на новые архитектуры.

Это общие слова. Что конкретно проще? Напомню, что наиболее
"портированный" дистрибутив никакого разделения на $arch и noarch не
ведёт.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Kirill A. Shutemov]

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

On Sun, Oct 26, 2008 at 08:56:47PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 16:42:48 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:
> 
>  KAS> Ну, к примеру, намного проще портировать на новые архитектуры.
> 
> Это общие слова. Что конкретно проще?

Мне не приходится возиться с кучей симлинков или, что ещё хуже,
пересобирать noarch пакеты. Я просто добавляю одну строчку в sources.list
и всё.

> Напомню, что наиболее
> "портированный" дистрибутив никакого разделения на $arch и noarch не
> ведёт.

А, ну так сразу бы и сказал. Аргумент из серии "некононично". Подобная
аргументация несостоятельна.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 19:27:31 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:

 >>  KAS> Ну, к примеру, намного проще портировать на новые архитектуры.
 >> Это общие слова. Что конкретно проще?

 KAS> Мне не приходится возиться с кучей симлинков

Когда noarch будет упразднён, то машинерия по сборке репозитория из
$arch и noarch-пакетов будет доступна и тебе.

 >> Напомню, что наиболее "портированный" дистрибутив никакого
 >> разделения на $arch и noarch не ведёт.

 KAS> А, ну так сразу бы и сказал. Аргумент из серии
 KAS> "некононично". Подобная аргументация несостоятельна.

Ты не понял. Это лишь опровержение того, что портирование становится
"намного" проще. Проще, но не более того.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Led]

On Sunday, 26 October 2008 19:34:34 Kirill A. Shutemov wrote:
> On Sun, Oct 26, 2008 at 11:28:41PM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 19:27:31 26.10.2008 UTC+02 when kirill@shutemov.name did 
gyre and gimble:
> >  >>  KAS> Ну, к примеру, намного проще портировать на новые архитектуры.
> >  >> Это общие слова. Что конкретно проще?
> >
> >  KAS> Мне не приходится возиться с кучей симлинков
> >
> > Когда noarch будет упразднён, то машинерия по сборке репозитория из
> > $arch и noarch-пакетов будет доступна и тебе.
>
> Я до сих пор не вижу веских причин менять status quo.

Это потому, что у вас иммунитет на маркетинговые "аргументы":)

-- 
Led

Re: [devel] kill Sisyphus noarch?

[Kirill A. Shutemov]

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

On Sun, Oct 26, 2008 at 11:28:41PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 19:27:31 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:
> 
>  >>  KAS> Ну, к примеру, намного проще портировать на новые архитектуры.
>  >> Это общие слова. Что конкретно проще?
> 
>  KAS> Мне не приходится возиться с кучей симлинков
> 
> Когда noarch будет упразднён, то машинерия по сборке репозитория из
> $arch и noarch-пакетов будет доступна и тебе.

Я до сих пор не вижу веских причин менять status quo. 

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 19:34:18 26.10.2008 UTC+02 when ledest@gmail.com did gyre and gimble:

 >> Я до сих пор не вижу веских причин менять status quo.
 L> Это потому, что у вас иммунитет на маркетинговые "аргументы":)

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Kirill A. Shutemov]

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

On Sun, Oct 26, 2008 at 11:35:25PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 19:34:18 26.10.2008 UTC+02 when ledest@gmail.com did gyre and gimble:
> 
>  >> Я до сих пор не вижу веских причин менять status quo.
>  L> Это потому, что у вас иммунитет на маркетинговые "аргументы":)
> 
> Это потому-то кто-то уже сидит здесь N лет, и запомнил всю ту кучу
> совершенно необязательных приседаний, которые нужно проделывать.

Если вы не знаете, что нужно писать в sources.list, вероятно, вам не нужно
его редактировать.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 19:38:51 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:

 KAS> Если вы не знаете, что нужно писать в sources.list, вероятно, вам
 KAS> не нужно его редактировать.

Предлагаю ещё после noarch добавить обязательную запись "Поклоняйтесь
великому ldv", и при её отсутствии - падать. И задокументировать.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Led]

On Sunday, 26 October 2008 19:35:25 Mikhail Gusarov wrote:
> Twas brillig at 19:34:18 26.10.2008 UTC+02 when ledest@gmail.com did gyre 
and gimble:
>  >> Я до сих пор не вижу веских причин менять status quo.
>
>  L> Это потому, что у вас иммунитет на маркетинговые "аргументы":)
>
> Это потому-то кто-то уже сидит здесь N лет, и запомнил всю ту кучу
> совершенно необязательных приседаний, которые нужно проделывать.

Кто мешает вам в дистрибутивах убрать эти "приседания"? Почему вы пытаетесь 
навязать маркетинговые "фишки" в репозитарии для разрабочиков?

-- 
Led

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 19:42:07 26.10.2008 UTC+02 when ledest@gmail.com did gyre and gimble:

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

 L> Кто мешает вам в дистрибутивах убрать эти "приседания"?

См. выше мнение одного из релиз-менеджеров. Релиз-менеджер "не сечёт
фишку".

 L> Почему вы
 L> пытаетесь навязать маркетинговые "фишки"

Не вижу в этом треде обсуждения маркетинговых фишек.

 L> в репозитарии для разрабочиков?

В частности потому, что искусственное деление на $arch и noarch
необходимо ровно для одной цели: шпынять тех, кто про него не знает. Это
увеличивает эго шпыняющего, но не более того.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] noarch/base

[Dmitry V. Levin]

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

On Sun, Oct 26, 2008 at 06:46:44PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 15:41:59 26.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> Я помню только один тред, что недавно кто-то подключил noarch, но
>  AT> не подключил $arch. Тогда как более логичной ошибкой было бы
>  AT> подключить $arch, а забыть подключить noarch.
> 
> Несколько веток на форуме, в IRC неоднократно всплывало, и, если не
> ошибаюсь, даже в багзилле - вешали баг на отсутствующую зависимость при
> отключенном noarch.
> 
>  AT> Разделение на $arch и noarch компоненты придумал не я, и оно
>  AT> существует очень давно (примерно с 2005-03-23).
> 
> Это можно не принимать во внимание.
> 
>  AT> Есть свои за и против. 
> 
> А можно озвучить "за", кроме (совершенно неинтересных) вопросов
> удобства/неудобства реализации?

Самый сильный аргумент -- это инерция.  Грубо говоря, это звучит так:
"у нас есть система, которая как-то работает, а вы тут предлагаете её
сломать".  Для того, чтобы получить что-то лучшее, нужно сделать это
что-то лучшее.

С одной стороны, я не буду настаивать на сохранении noarch/base в его
нынешнем виде, поскольку мне кажется, что оно создаёт больше проблем чем
решает.  С другой стороны, я не планировал ликвидировать noarch/base
сейчас, поэтому тому из вас, кто торопится, придётся попробовать себя
паровозм.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Igor Vlasenko]

On Sun, Oct 26, 2008 at 03:52:53PM +0300, Alexey Tourbin wrote:
> On Sun, Oct 26, 2008 at 06:46:44PM +0600, Mikhail Gusarov wrote:
> >  AT> Есть свои за и против. 
> > 
> > А можно озвучить "за", кроме (совершенно неинтересных) вопросов
> > удобства/неудобства реализации?
> 
> То, что первым делом приходит в голову -- если влить в каждый
> архитектурный репозитарий noarch компоненту, то она будет дублироваться.
> Это экономия минимум 2M при синхронизации сизифа для двух архитектур,
> а максимум -- 82M (du -hs /ALT/Sisyphus/noarch/base).

Экономя на мегабайт, теряем на гигабайт :(
Напомню, что я предложил упразднить noarch чтобы
преодолеть
https://bugzilla.altlinux.org/show_bug.cgi?id=17674

Т.е. я решил попробовать поиграть с 
BuildArch: noarch в подпакетах.
начал с fonts-ttf-java-1.6.0-sun-1.6.0.10-alt2.noarch.rpm
(1,3M экономии).
Последствия красочно расписаны в #17674:
apt клинит, java-1.6.0-sun без бубна не ставится...

Если слить репозитарии, чтобы BuildArch: noarch
пользоваться было не страшно, то только из этого
пакета будет еще 24M экономии:
6,1M java-1.6.0-sun-demo-1.6.0.10-alt2.x86_64.rpm
 18M java-1.6.0-sun-source-1.6.0.10-alt2.x86_64.rpm

Что такое 82M?
Если распилить один только большой пакет,
например wesnoth, то его 150M wesnoth-data
покроют 82M как бык овцу.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 20:15:07 26.10.2008 UTC+02 when vlasenko@imath.kiev.ua did gyre and gimble:

 IV> Если распилить один только большой пакет, например wesnoth, то его
 IV> 150M wesnoth-data покроют 82M как бык овцу.

Тут нужно считать, как часто обновлется репозиторий, и как часто -
wesnoth-data и другие noarch-субпакеты.

Впрочем, из тех 82M очень много - не по существу. Информация из
contents_index легко ужимается до нескольких мегабайт (trie вместо
списка файлов).

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Pavlov Konstantin]

On Sun, Oct 26, 2008 at 07:38:51PM +0200, Kirill A. Shutemov wrote:
> On Sun, Oct 26, 2008 at 11:35:25PM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 19:34:18 26.10.2008 UTC+02 when ledest@gmail.com did gyre and gimble:
> > 
> >  >> Я до сих пор не вижу веских причин менять status quo.
> >  L> Это потому, что у вас иммунитет на маркетинговые "аргументы":)
> > 
> > Это потому-то кто-то уже сидит здесь N лет, и запомнил всю ту кучу
> > совершенно необязательных приседаний, которые нужно проделывать.
> 
> Если вы не знаете, что нужно писать в sources.list, вероятно, вам не нужно
> его редактировать.

Чушь, я гарантирую это.

-- 
>>Именно.  И тратить силы на дублирование -- самоубийство.
>Нет. Самоубийство предоставлять неполноценную, не связанную и 
>разрозненную документацию.
Давайте не будем о суициде, тем более -- о его способах.
		-- aen in docs@

Re: [devel] kill Sisyphus noarch?

[Pavlov Konstantin]

On Sun, Oct 26, 2008 at 03:52:53PM +0300, Alexey Tourbin wrote:
> On Sun, Oct 26, 2008 at 06:46:44PM +0600, Mikhail Gusarov wrote:
> >  AT> Есть свои за и против. 
> > 
> > А можно озвучить "за", кроме (совершенно неинтересных) вопросов
> > удобства/неудобства реализации?
> 
> То, что первым делом приходит в голову -- если влить в каждый
> архитектурный репозитарий noarch компоненту, то она будет дублироваться.
> Это экономия минимум 2M при синхронизации сизифа для двух архитектур,
> а максимум -- 82M (du -hs /ALT/Sisyphus/noarch/base).

Вы это сейчас серьезно о < 100M при 

37G /var/ftp/pub/distributions/ALTLinux/Sisyphus

?

-- 
<lioka> ppl, как mountpoint по украински ?
<Vitls> mountpoint
<lioka> ещё варианты будут ?
<combr> lioka: точка монтiрования? ;)
<Lost_work> lioka: розетка
<combr> lioka: (не знаю ни слова по)

Re: [devel] kill Sisyphus noarch?

[Alexey Tourbin]

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

On Sun, Oct 26, 2008 at 08:15:07PM +0200, Igor Vlasenko wrote:
> On Sun, Oct 26, 2008 at 03:52:53PM +0300, Alexey Tourbin wrote:
> > On Sun, Oct 26, 2008 at 06:46:44PM +0600, Mikhail Gusarov wrote:
> > >  AT> Есть свои за и против. 
> > > 
> > > А можно озвучить "за", кроме (совершенно неинтересных) вопросов
> > > удобства/неудобства реализации?
> > 
> > То, что первым делом приходит в голову -- если влить в каждый
> > архитектурный репозитарий noarch компоненту, то она будет дублироваться.
> > Это экономия минимум 2M при синхронизации сизифа для двух архитектур,
> > а максимум -- 82M (du -hs /ALT/Sisyphus/noarch/base).
> 
> Экономя на мегабайт, теряем на гигабайт :(
> Напомню, что я предложил упразднить noarch чтобы
> преодолеть
> https://bugzilla.altlinux.org/show_bug.cgi?id=17674
> 
> Т.е. я решил попробовать поиграть с 
> BuildArch: noarch в подпакетах.
> начал с fonts-ttf-java-1.6.0-sun-1.6.0.10-alt2.noarch.rpm
> (1,3M экономии).
> Последствия красочно расписаны в #17674:
> apt клинит, java-1.6.0-sun без бубна не ставится...

Если клинит apt, надо чтобы не клинило apt.
Может там в нём какой-нибудь алгоритм есть или что-нибудь такое!
(Я ещё не изучал #17674.)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Igor Vlasenko]

On Mon, Oct 27, 2008 at 12:18:22AM +0600, Mikhail Gusarov wrote:
> Тут нужно считать, как часто обновлется репозиторий, и как часто -
> wesnoth-data и другие noarch-субпакеты.

Пакетов, которые выиграют от BuildArch: noarch 
find . -name arch-dep-package-has-big-usr-share+++experimental | wc -l
751
оценка экономии для Сизифа - мин. 2 Gb.
думаю, что и средняя экономия на транзакцию тоже не будет маленькой.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 21:30:02 26.10.2008 UTC+03 when thresh@altlinux.ru did gyre and gimble:

 PK> Вы это сейчас серьезно о < 100M при 

 PK> 37G /var/ftp/pub/distributions/ALTLinux/Sisyphus

Всё-таки это base - то, что синхронизируется каждый раз при
обновлении. Правда из тех base apt-get'ом сколько тянулось - столько и
будет тянуться, а тех, кто миррорит, лишние 80M не смутят.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Mikhail Gusarov]

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

Twas brillig at 21:14:25 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:

 >> Предлагаю ещё после noarch добавить обязательную запись
 >> "Поклоняйтесь великому ldv", и при её отсутствии - падать. И
 >> задокументировать.

 KAS> Переходить на личности отличительная черта дебиановцев?

Где здесь переход на личности? Я предложил сделать ЕЩЁ одно совершенно
не нужное приплясывание. Ровно такое же, как noarch.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] kill Sisyphus noarch?

[Kirill A. Shutemov]

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

On Sun, Oct 26, 2008 at 11:38:53PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 19:38:51 26.10.2008 UTC+02 when kirill@shutemov.name did gyre and gimble:
> 
>  KAS> Если вы не знаете, что нужно писать в sources.list, вероятно, вам
>  KAS> не нужно его редактировать.
> 
> Предлагаю ещё после noarch добавить обязательную запись "Поклоняйтесь
> великому ldv", и при её отсутствии - падать. И задокументировать.

Переходить на личности отличительная черта дебиановцев?

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] kill Sisyphus noarch?

[Andrey Rahmatullin]

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

On Mon, Oct 27, 2008 at 12:44:37AM +0600, Mikhail Gusarov wrote:
> Всё-таки это base - то, что синхронизируется каждый раз при
> обновлении. Правда из тех base apt-get'ом сколько тянулось - столько и
> будет тянуться, а тех, кто миррорит, лишние 80M не смутят.
+1, а 80 там нету из-за rsync.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<thresh> интересно, будут ли randomsegfaults в пакетах ldv типа if nick=="из
         тех, что засветились в шутках в fortunes?"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[devel] contents_index trie

[Alexey Tourbin]

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

On Mon, Oct 27, 2008 at 12:18:22AM +0600, Mikhail Gusarov wrote:
>  IV> Если распилить один только большой пакет, например wesnoth, то его
>  IV> 150M wesnoth-data покроют 82M как бык овцу.
> 
> Тут нужно считать, как часто обновлется репозиторий, и как часто -
> wesnoth-data и другие noarch-субпакеты.
> 
> Впрочем, из тех 82M очень много - не по существу. Информация из
> contents_index легко ужимается до нескольких мегабайт (trie вместо
> списка файлов).

Trie лишь оптимизирует *доступ* к contents_index (переходы типа
многоуровнего хеша); а с точки зрения размера выгоднее contents_index
просто сжать.

А также trie оптимизирует доступ лишь *логически*.  А на самом деле
доступ к contents_index будет проходить через диск.  Дисковый доступ
имеет сильно выраженную постраничную специфику (4K блоки).  Значит,
нужна нетривиальная логика сериализации trie, которая бы оптимизировала
локальность ссылок при переходе вглубь trie на физических страницах.
Грамотная запись trie на диск -- по сложности это уже задача на уровне
libdb4.

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

Если кто не в теме и кому интересно,
http://en.wikipedia.org/wiki/Trie
http://git.altlinux.org/people/at/packages/path-trie.git

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Mikhail Gusarov]

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

Twas brillig at 09:27:28 28.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Trie лишь оптимизирует *доступ* к contents_index (переходы типа
 AT> многоуровнего хеша); а с точки зрения размера выгоднее
 AT> contents_index просто сжать.

Конечно, но trie заодно уберёт огромную избыточность текущего
contents_index. Впрочем, сжать проще.

 AT> Значит, нужна нетривиальная логика сериализации trie, которая бы
 AT> оптимизировала локальность ссылок при переходе вглубь trie на
 AT> физических страницах.

Любая сериализация trie будет лучше, чем grep по файлу :)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Tue, Oct 28, 2008 at 12:31:35PM +0600, Mikhail Gusarov wrote:
>  AT> Trie лишь оптимизирует *доступ* к contents_index (переходы типа
>  AT> многоуровнего хеша); а с точки зрения размера выгоднее
>  AT> contents_index просто сжать.
> 
> Конечно, но trie заодно уберёт огромную избыточность текущего
> contents_index. Впрочем, сжать проще.

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

>  AT> Значит, нужна нетривиальная логика сериализации trie, которая бы
>  AT> оптимизировала локальность ссылок при переходе вглубь trie на
>  AT> физических страницах.
> 
> Любая сериализация trie будет лучше, чем grep по файлу :)

С точки зрения доступа сериализации должна давать минимальное количество
page faults [*].  То есть, примерно, чтобы переход / -> /usr затрагивал
всего одну 4K страницу (которую необходимо загрузить в память с диска),
переход /usr -> /usr/share затрагивал всего одну 4K страницу и т.д.

Если на одной странице оказываются unrelated пути (напр. /usr и /etc),
то мы лишь избавляемся от лишних вызовов типа regexec(3) (как в grep),
но не можем ограничить активность ОС (ограничить фактическое потребление
памяти).  А в примитивной сериализации адреса никак не сгруппированы и
не упорядочены, то есть будет почти случайное перемешивание; так что в
памяти будет оседать большое количество лишних страниц.  То есть при
наивной сериализации попытка сколько-нибудь глубокого доступ будет
"всасывать" весь contents_index в память, а оптимизация доступа будет
идти уже на "всосанных" данных.  Тогда понятие оптимальности
раздваивается: с точки зрения userspace вместо линейного перебора
будет trie; а с точки зрения virtual memory и свопа получается
то же самое, то есть очень дорого.

[*] http://en.wikipedia.org/wiki/Page_fault

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Mikhail Gusarov]

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

Twas brillig at 10:04:13 28.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> С точки зрения доступа сериализации должна давать минимальное
 AT> количество page faults [*].  То есть, примерно, чтобы переход / ->
 AT> /usr затрагивал всего одну 4K страницу (которую необходимо
 AT> загрузить в память с диска), переход /usr -> /usr/share затрагивал
 AT> всего одну 4K страницу и т.д.

 AT> Если на одной странице оказываются unrelated пути (напр. /usr и
 AT> /etc), то мы лишь избавляемся от лишних вызовов типа regexec(3)
 AT> (как в grep), но не можем ограничить активность ОС (ограничить
 AT> фактическое потребление памяти).

Не понимаю, почему так. Возьмём путь длиной в 40 символов (для простоты
- 40 байтов). Для того, чтобы добраться до его конца, нам нужно
прочитать 40 узлов. Каждый узел - это, максимум, 256 x (байт, указатель
на заголовок следующего блока, бит статуса), т.е. укладывается в 4k с
запасом. Бит статуса можно изжить с помощью заголовка "имена начинаются
со смещения 0xabcde".

Таким образом, для lookup'а придётся поднять 41 блок (последний - для
вычитываяния имени пакета) даже при тривиальной сериализации, которая
просто не даёт узлу пересечь границу блока.

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Tue, Oct 28, 2008 at 01:19:20PM +0600, Mikhail Gusarov wrote:
> Twas brillig at 10:04:13 28.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:
> 
>  AT> С точки зрения доступа сериализации должна давать минимальное
>  AT> количество page faults [*].  То есть, примерно, чтобы переход / ->
>  AT> /usr затрагивал всего одну 4K страницу (которую необходимо
>  AT> загрузить в память с диска), переход /usr -> /usr/share затрагивал
>  AT> всего одну 4K страницу и т.д.
> 
>  AT> Если на одной странице оказываются unrelated пути (напр. /usr и
>  AT> /etc), то мы лишь избавляемся от лишних вызовов типа regexec(3)
>  AT> (как в grep), но не можем ограничить активность ОС (ограничить
>  AT> фактическое потребление памяти).
> 
> Не понимаю, почему так. Возьмём путь длиной в 40 символов (для простоты
> - 40 байтов). Для того, чтобы добраться до его конца, нам нужно
> прочитать 40 узлов.

Нужно не прочитать 40 узлов, а выполнить 40 разыменоваываний (dereferencing "->").
То, что разыменовывание означает чтение узла, это и есть оптимистическое
предоложение о том, что у нас есть фс-подобная структура с локальными
переходами между узлами.  Но на самом деле её нет.  Мы прсто сдампили
память.  Так что чтение "узла /usr" может дать чтение порядка 700
страниц (ls -l /usr |wc -c).

Точнее, это сильно зависит от способа организации ссылок.
Но при использовании malloc(3) вариантов мало.

     +---+                    +--------+
/usr | * | --> адрес страницы | /share | -> ...
     +---+                    +--------+
     | * |`
     +---+ `-> адрес страницы +--------+
     | * |`                   | /bin   | -> ...
     +---+ `		      +--------+
            `-> ...

Дело в том, что тут strcmp можно сделать на на стадии /usr, а только
после подгрузки всех детей /usr.

Надо подумать.

> Каждый узел - это, максимум, 256 x (байт, указатель
> на заголовок следующего блока, бит статуса), т.е. укладывается в 4k с
> запасом. Бит статуса можно изжить с помощью заголовка "имена начинаются
> со смещения 0xabcde".
> 
> Таким образом, для lookup'а придётся поднять 41 блок (последний - для
> вычитываяния имени пакета) даже при тривиальной сериализации, которая
> просто не даёт узлу пересечь границу блока.
> 
> В случае несильного ветвления лексикографическая сортировка даст ещё
> большую экономию (последовательные узлы окажутся в одном или соседних
> дисковых блоках).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Tue, Oct 28, 2008 at 10:50:13AM +0300, Alexey Tourbin wrote:
> память.  Так что чтение "узла /usr" может дать чтение порядка 700
> страниц (ls -l /usr |wc -c).

"wc -c" неуместно, "wc -l" даёт 16.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Mikhail Gusarov]

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

Twas brillig at 10:50:13 28.10.2008 UTC+03 when at@altlinux.ru did gyre and gimble:

 AT> Так что чтение "узла /usr" может дать чтение порядка 700 страниц
 AT> (ls -l /usr |wc -c).

Не так организовывать надо.

Не usr -> share -> foo, а u -> s -> r -> / -> s -> h -> ...

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

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] contents_index trie

[Денис Смирнов]

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

On Tue, Oct 28, 2008 at 10:50:13AM +0300, Алексей Турбин wrote:

Правильно ли я понимаю что речь идет о задаче создания чего-то вроде cdb,
с некоторыми уточнениями:
- нет key/data, есть только key
- поддерживается единственная операция "проверить на существование данный
  key"
- нужно обеспечить минимальное количество pagefaults при выполнении этой
  операции

Я правильно понял?

Еще вопрос -- правильно ли я понимаю что речь идет о том, что формат для
передачи данных и для их использования предполагается одинаковым? А то
может для _передачи_ разумнее использовать сжатые lzma каким plain text, а
уже при получении конвертировать в удобный для работы формат?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Sat, Nov 01, 2008 at 06:42:07PM +0300, Денис Смирнов wrote:
> On Tue, Oct 28, 2008 at 10:50:13AM +0300, Алексей Турбин wrote:
> 
> Правильно ли я понимаю что речь идет о задаче создания чего-то вроде cdb,
> с некоторыми уточнениями:
> - нет key/data, есть только key
> - поддерживается единственная операция "проверить на существование данный
>   key"
> - нужно обеспечить минимальное количество pagefaults при выполнении этой
>   операции
> 
> Я правильно понял?

Нет, имееется в виду trie.  Это дерево.  С каждым ключом ассоциировано
значение _и_ последующие вложенные ключи.  Так что идёт доступ по
составному ключу, типа ["usr","bin","perl"]->"perl-base".  То есть
значение ключа "накапливается", а дополнительный переход на каждом этапе
выполняется рекурсивно (хвостовая рекурсия с "остатком" составного ключа).
http://en.wikipedia.org/wiki/Trie

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Sat, Nov 01, 2008 at 09:01:36PM +0300, Alexey Tourbin wrote:
> On Sat, Nov 01, 2008 at 06:42:07PM +0300, Денис Смирнов wrote:
> > On Tue, Oct 28, 2008 at 10:50:13AM +0300, Алексей Турбин wrote:
> > 
> > Правильно ли я понимаю что речь идет о задаче создания чего-то вроде cdb,
> > с некоторыми уточнениями:
> > - нет key/data, есть только key
> > - поддерживается единственная операция "проверить на существование данный
> >   key"
> > - нужно обеспечить минимальное количество pagefaults при выполнении этой
> >   операции
> > 
> > Я правильно понял?
> 
> Нет, имееется в виду trie.  Это дерево.  С каждым ключом ассоциировано
> значение _и_ последующие вложенные ключи.  Так что идёт доступ по
> составному ключу, типа ["usr","bin","perl"]->"perl-base".  То есть
> значение ключа "накапливается", а дополнительный переход на каждом этапе
> выполняется рекурсивно (хвостовая рекурсия с "остатком" составного ключа).
> http://en.wikipedia.org/wiki/Trie

Это похоже на фаловую систему, только в файловой системе ключ не может
быть одновременно и файлом, и каталогом.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Sat, Nov 01, 2008 at 09:07:50PM +0300, Alexey Tourbin wrote:
> On Sat, Nov 01, 2008 at 09:01:36PM +0300, Alexey Tourbin wrote:
> > On Sat, Nov 01, 2008 at 06:42:07PM +0300, Денис Смирнов wrote:
> > > On Tue, Oct 28, 2008 at 10:50:13AM +0300, Алексей Турбин wrote:
> > > 
> > > Правильно ли я понимаю что речь идет о задаче создания чего-то вроде cdb,
> > > с некоторыми уточнениями:
> > > - нет key/data, есть только key
> > > - поддерживается единственная операция "проверить на существование данный
> > >   key"
> > > - нужно обеспечить минимальное количество pagefaults при выполнении этой
> > >   операции
> > > 
> > > Я правильно понял?
> > 
> > Нет, имееется в виду trie.  Это дерево.  С каждым ключом ассоциировано
> > значение _и_ последующие вложенные ключи.  Так что идёт доступ по
> > составному ключу, типа ["usr","bin","perl"]->"perl-base".  То есть
> > значение ключа "накапливается", а дополнительный переход на каждом этапе
> > выполняется рекурсивно (хвостовая рекурсия с "остатком" составного ключа).
> > http://en.wikipedia.org/wiki/Trie
> 
> Это похоже на фаловую систему, только в файловой системе ключ не может
> быть одновременно и файлом, и каталогом.

То есть это префиксное дерево в общем виде.
Вот другой пример (словарь):

["ч","а","й"] -> <напиток>
["ч","а","й","к","а"] -> <птица>

Организация памяти в префиксном дереве должна быть такой, чтобы при
очередном переходе по составному ключу, т.е. "ч"->"а", "а"->"й" и т.д.
выполнялось условие локальности ссылок: ключи и значения в памяти
должны быть размещены (сгруппированы) "близко" друг к другу, то есть
чтобы при проходе по составному ключу вглубь дерева затрагивалось
минимальное число сегментов памяти.

В файловой системе так и происходит: каталог тоже имеет inode, и данные
каталога (dirent.h) локльно "сгруппированы" в "файле" каталога.  Так что
переход из каталога в подкаталог затрагивает минимальное количество
дисковых страниц.  А если бы информация о содержимом каталога была
произвольно разбросана по диску (как указатели на строки при
использовании malloc), тогда для напр. readdir(2) потребовалось бы
читать с диска в буферный кеш большое количество лишних страниц.

Короче, оптимальное размещение в памяти префиксного дерева --
по сложности это задача где-то на уровне реализации файловой системы.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] contents_index trie

[Alexey Tourbin]

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

On Sat, Nov 01, 2008 at 11:45:41PM +0300, Alexey Tourbin wrote:
> On Sat, Nov 01, 2008 at 09:07:50PM +0300, Alexey Tourbin wrote:
> > On Sat, Nov 01, 2008 at 09:01:36PM +0300, Alexey Tourbin wrote:
> > > On Sat, Nov 01, 2008 at 06:42:07PM +0300, Денис Смирнов wrote:
> > > > On Tue, Oct 28, 2008 at 10:50:13AM +0300, Алексей Турбин wrote:
> > > > 
> > > > Правильно ли я понимаю что речь идет о задаче создания чего-то вроде cdb,
> > > > с некоторыми уточнениями:
> > > > - нет key/data, есть только key
> > > > - поддерживается единственная операция "проверить на существование данный
> > > >   key"
> > > > - нужно обеспечить минимальное количество pagefaults при выполнении этой
> > > >   операции
> > > > 
> > > > Я правильно понял?
> > > 
> > > Нет, имееется в виду trie.  Это дерево.  С каждым ключом ассоциировано
> > > значение _и_ последующие вложенные ключи.  Так что идёт доступ по
> > > составному ключу, типа ["usr","bin","perl"]->"perl-base".  То есть
> > > значение ключа "накапливается", а дополнительный переход на каждом этапе
> > > выполняется рекурсивно (хвостовая рекурсия с "остатком" составного ключа).
> > > http://en.wikipedia.org/wiki/Trie
> > 
> > Это похоже на фаловую систему, только в файловой системе ключ не может
> > быть одновременно и файлом, и каталогом.
> 
> То есть это префиксное дерево в общем виде.
> Вот другой пример (словарь):
> 
> ["ч","а","й"] -> <напиток>
> ["ч","а","й","к","а"] -> <птица>

Условие локальности ссылок дополнительно состоит в том, что группировка
данных должна усиливаться при нарастании вложенности.  На пальцах это
означает, что вариативность окончаний следует соотносить с основным
"понятием".  Пример (словарь):

["ч","а","й"] -> <напиток>
["ч","а","й","н","ы","й"] -> прил. муж. относящийся к "чай"
["ч","а","й","н","а","я"] -> прил. жен. относящийся к "чай"

Пример с точки зрения фс:
/usr/lib/perl5 -> perl-base
/usr/lib/perl5/Test -> perl-devel
/usr/lib/perl5/Test.pm -> perl-devel
/usr/lib/perl5/Test/More.pm -> perl-devel

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

> Организация памяти в префиксном дереве должна быть такой, чтобы при
> очередном переходе по составному ключу, т.е. "ч"->"а", "а"->"й" и т.д.
> выполнялось условие локальности ссылок: ключи и значения в памяти
> должны быть размещены (сгруппированы) "близко" друг к другу, то есть
> чтобы при проходе по составному ключу вглубь дерева затрагивалось
> минимальное число сегментов памяти.
> 
> В файловой системе так и происходит: каталог тоже имеет inode, и данные
> каталога (dirent.h) локльно "сгруппированы" в "файле" каталога.  Так что
> переход из каталога в подкаталог затрагивает минимальное количество
> дисковых страниц.  А если бы информация о содержимом каталога была
> произвольно разбросана по диску (как указатели на строки при
> использовании malloc), тогда для напр. readdir(2) потребовалось бы
> читать с диска в буферный кеш большое количество лишних страниц.
> 
> Короче, оптимальное размещение в памяти префиксного дерева --
> по сложности это задача где-то на уровне реализации файловой системы.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]