[devel] I: repocop test for %{get_version ...} is disabled.

[devel] I: repocop test for %{get_version ...} is disabled.

[Igor Vlasenko]

Уважаемые коллеги,
по поводу макроса get_version в spec-файлах.
В свое время Алексей реализовал set:versions, 
и тогда в devel@ были заявения, что теперь с set:versions %get_version
не нужен и его пора удалять,
в результате чего я даже написал тест репокоп, который удаляет в spec-файлах
макрос get_version, как, например, в
http://repocop.altlinux.org/pub/repocop/reports/diff/by-acl/zerg/poppler26-0.20.2-alt1.diff

Пыль осела, и начал сомневаться, а нужно ли удалять %get_version?
В большинстве случаев он избыточен, но ведь вреда вроде бы от него нет?

Я обсудил ситуацию с Сергеем (zerg@, на него робот приготовил большое NMU
с удалением %get_version в kde пакетах), и пришли к выводу,
что раз формально set:versions не дает полных гарантий, 
то и убирать %get_version не надо, хуже от него не будет.

В общем, отключил тест. Если есть возражения, прошу высказать.

-- 

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] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Wed, Aug 22, 2012 at 10:56:49PM +0300, Igor Vlasenko wrote:
> Уважаемые коллеги,
> по поводу макроса get_version в spec-файлах.
> В свое время Алексей реализовал set:versions, 
> и тогда в devel@ были заявения, что теперь с set:versions %get_version
> не нужен и его пора удалять,
> в результате чего я даже написал тест репокоп, который удаляет в spec-файлах
> макрос get_version, как, например, в
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-acl/zerg/poppler26-0.20.2-alt1.diff

-Requires: libqt4-core >= %{get_version libqt4-core}
+Requires: libqt4-core

Надо было удалять всю зависимость на libqt4-core, а не только %get_version.

> Пыль осела, и начал сомневаться, а нужно ли удалять %get_version?
> В большинстве случаев он избыточен, но ведь вреда вроде бы от него нет?
> 
> Я обсудил ситуацию с Сергеем (zerg@, на него робот приготовил большое NMU
> с удалением %get_version в kde пакетах), и пришли к выводу,
> что раз формально set:versions не дает полных гарантий, 
> то и убирать %get_version не надо, хуже от него не будет.

Set-версии формально не дают полной гарантии, а какую тогда гарантию
формально дает %get_version?  Можно подумать, что указание версии, не
меньшей текущей, дает полную гарантию, и разводить демагогию, а на самом
деле гарантии нет вообще никакой.  Нет никакой гарантии, что в следующих
версиях сохранится полная обратная совместимость.  А set-версии как раз
пытаются выразить, и притом довольно успешно и совершенно автоматически,
определенный критерий совместимости между версиями библиотек.  То, что
"хуже не будет", aka "от балды" - я тогда сейчас сделаю в rpmbuild, чтобы
он и все зависимости дополнял текущими версиями, хуже не будет.
А будет круто!

В чем вообще смысл зависимости
Requires: libqt4-core >= %{get_version libqt4-core}
в системе с хорошо развитыми автоматическими зависимостями?
Это какое-то ретроградство и оксюморон из 1998 года.

Вообще, мега-идея была, чтобы не указывать зависимости вручную вообще:
все Requires зависимости из спекфайлов снести, а BuildRequires зависимости
добавлять только с помощью /usr/bin/buildreq.  Понятно, что не
предлагалось следовать этой идее с особым фанатизмом, но в то же время
было многое сделано для того, чтобы в большинстве случаев получался
приемлемый результат.  Так что роботу следовало бы попросту косить все
зависимости из спекфайлов под корень. :-)

> В общем, отключил тест. Если есть возражения, прошу высказать.
> 
> -- 
> 
> Dr. Igor Vlasenko
> --------------------
> Topology Department
> Institute of Math
> Kiev, Ukraine

Re: [devel] I: repocop test for %{get_version ...} is disabled.

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

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

On Wed, Aug 22, 2012 at 10:56:49PM +0300, Igor Vlasenko wrote:

IV> Пыль осела, и начал сомневаться, а нужно ли удалять %get_version?
IV> В большинстве случаев он избыточен, но ведь вреда вроде бы от него нет?

Подобные конструкции запрещают устанавливать пакет, если зависимость имеет
меньшую версию.

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

set-versions помогает в обоих случаях (но без абсолютной гарантии).

Наличие зависимостей с %get_version не является ошибкой, но, скорее всего,
является излишеством. Поэтому их удаление вполне себе minor enchancement.

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Michael Shigorin]

On Thu, Aug 23, 2012 at 12:53:34AM +0400, Alexey Tourbin wrote:
> Вообще, мега-идея была, чтобы не указывать зависимости вручную вообще:

Она во многом удалась, хотя есть несколько проблем -- %ifdef,
%package и паразитные зависимости вроде cvs или что там ещё
когда-то вытягивалось каждым третьим configure-скриптом.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----        Sep 29, Kiev, Ukraine:
--       http://conference.osdn.org.ua

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Dmitry V. Levin]

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

On Thu, Aug 23, 2012 at 12:16:00AM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2012 at 12:53:34AM +0400, Alexey Tourbin wrote:
> > Вообще, мега-идея была, чтобы не указывать зависимости вручную вообще:
> 
> Она во многом удалась, хотя есть несколько проблем -- %ifdef,
> %package и паразитные зависимости вроде cvs или что там ещё
> когда-то вытягивалось каждым третьим configure-скриптом.

Зависимости на cvs когда-то вытягивались autopoint'ом.
Но это было давно, уже много лет как не вытягиваются.


-- 
ldv

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 01:11:57AM +0400, Денис Смирнов wrote:
> On Wed, Aug 22, 2012 at 10:56:49PM +0300, Igor Vlasenko wrote:
> 
> IV> Пыль осела, и начал сомневаться, а нужно ли удалять %get_version?
> IV> В большинстве случаев он избыточен, но ведь вреда вроде бы от него нет?
> 
> Подобные конструкции запрещают устанавливать пакет, если зависимость имеет
> меньшую версию.
> 
> Это помогает с библиотеками, в которые добавляют новые символы, но не
> удаляют их.
> 
> set-versions помогает в обоих случаях (но без абсолютной гарантии).

Гарантия разрешимости символов, которую дают set-версии, довольно высокая:
в предельном случае, когда по сравнению с предыдущей версией требуется
всего один новый символ, она зафиксирована на уровне не хуже 2^{-10}
т.е. около 0.1%.  Когда требуется два новых символа, гарантия уже
подскакивает до милионной.

Гарантию следует интуитивно соотносить с количеством пакетов в
репозитории: мы допускаем, что либо несколько пакетов, либо в среднем
один-два пакета, либо скорее всего ни одного пакета не лишаются гарантии.
Гарантию можно поднять: удвоение гарантии стоит 1 бит, в "base62"
кодировке каждый символ несет 5.9+ битов.

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 01:29:44AM +0400, Alexey Tourbin wrote:
> Гарантию можно поднять: удвоение гарантии стоит 1 бит, в "base62"
> кодировке каждый символ несет 5.9+ битов.

Несколько точнее, при текущей гарантии 2^{-10} каждый символ из Provides
версии требует примерно 12 битов, т.е. примерно 2 буквы.  Следовательно,
чтобы поднять гарантию, например, в 64 раза, потребуется, еще примерно
log2(64)=6 битов на символ, то есть примерно еще 1 буква, то есть размер
Provides set-версий вырастет примерно в полтора раза.

Откуда берётся 12 битов?  Это этнорпия "n choose k" - выбор, грубо говоря,
2^{10} элементов из 2^{20} элементов.  Более точное значение равно 11.44
(но мы округляем количество символов в большую сторону, следовательно еще
полбита), и оно хорошо сохраняется при смене параметров:

$ R
> lchoose(2**20, 2**10)/log(2)/2**10
[1] 11.43581
> lchoose(2**30, 2**20)/log(2)/2**20
[1] 11.44198

(Довольно интересно, для представления набора 1024 20-битных чисел
требуется всего 11.44 бита на число - неплохое сжатие.)

Текущий размер всех set-версий (в буквенном виде) - примерно 13M, в сжатом
виде - примерно 9M:

$ strings /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic |grep ^set: |wc -c
13820628
$ strings /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic |grep ^set: |lzma |wc -c
9453115

Соответственно, чтобы поднять гарантию в 64 раза (весьма впечатлительно),
придется при каждом обновлении всё же скачивать лишние 5M и после разжатия
обрабатывать на клиенте лишние 7M (что тоже не совсем мало).

Следует отметить, что новые биты не сжимаются (по принципу энтропии "n
choose k"), то есть удвоение гарантии неизбежно требует полный новый бит,
а сжатие было возможно только на более "ранних" стадиях.

> lchoose(2**21, 2**10)/log(2)/2**10
[1] 12.43617
> lchoose(2**31, 2**20)/log(2)/2**20
[1] 12.44233

Следует также отметить, что Provides set-версии откусывают большую
половину, хотя и не подавляющую часть, в сравнении с Requires set-версиями.

$ pkglist-query '[%{ProvideVersion}\n]' /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic |grep ^set: |wc -c
8261756
$ pkglist-query '[%{RequireVersion}\n]' /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic |grep ^set: |wc -c
5558872

Re: [devel] I: repocop test for %{get_version ...} is disabled.

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

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

On Thu, Aug 23, 2012 at 01:29:44AM +0400, Алексей Турбин wrote:

AT> Гарантия разрешимости символов, которую дают set-версии, довольно высокая:
AT> в предельном случае, когда по сравнению с предыдущей версией требуется
AT> всего один новый символ, она зафиксирована на уровне не хуже 2^{-10}
AT> т.е. около 0.1%.  Когда требуется два новых символа, гарантия уже
AT> подскакивает до милионной.

Это не такой уж маленький процент при нашей пакетной базе. Однако
увеличение объема индексов apt до создания более эффективной системы, мне
кажется, неприемлимо.

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

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 09:03:44AM +0400, Денис Смирнов wrote:
> On Thu, Aug 23, 2012 at 01:29:44AM +0400, Алексей Турбин wrote:
> AT> Гарантия разрешимости символов, которую дают set-версии, довольно высокая:
> AT> в предельном случае, когда по сравнению с предыдущей версией требуется
> AT> всего один новый символ, она зафиксирована на уровне не хуже 2^{-10}
> AT> т.е. около 0.1%.  Когда требуется два новых символа, гарантия уже
> AT> подскакивает до милионной.
> 
> Это не такой уж маленький процент при нашей пакетной базе. Однако
> увеличение объема индексов apt до создания более эффективной системы, мне
> кажется, неприемлимо.

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

Насчет индексов апта - set-версии составляют в них не более половины.
Их удалось ужать до практичного размера.  Так что полагаю, что разговоры
насчет объема индексов apt и создания "более эффективной системы" политически
мотивированы.

$ l /var/cache/apt/pkgcache.bin
-rw-r--r-- 1 at rpm 58513368 Aug 22 03:31 /var/cache/apt/pkgcache.bin
$ strings /var/cache/apt/pkgcache.bin |grep ^set: |wc -c
25803870
$ 

У меня еще подключен репозиторий x86_64-i586, что делает размер
правдоподобным:

$ strings /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic |grep ^set: |wc -c
13820628
$ strings /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64-i586_base_pkglist.classic |grep ^set: |wc -c
11934095

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

Зависимости %get_version не заведомо излишни, а просто они безосновательны
и глупы: зависимости должны выражать необходимые и достаточные условия, а
с помощью оператора >= можно выразить лишь достаточные условия, да и то с
очень большой натяжкой, поскольку сохранение обратной совместимости в
новых версиях ничем не гарантируется.

Короче, подписчикам следут меньше думать о том, что set-версии не дают
"абсолютной гарантии".  Гарантия очень большая, а абсолютную гарантию,
как известно, дает только страховой полис.

That said, интересно подумать, что можно еще извлечь из set-версий.
Над чем я думал: можно внести поддержку прототипов по схеме, похожей на
C++ mangling - это довольно сложно, но не архисложно.  Информацию о
прототипах можно извлекать из .debug файлов, которые автоматически
создаются на стадии brp-debuginfo.  Над чем еще не думал: можно ли таким
образом контролировать структуру VMT в C++ (по некоторым данным, к этому
классу можно отнести около 1% изученных случаев бинарной несовместимости).

> -- 
> С уважением, Денис
> 
> http://mithraen.ru/

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Igor Vlasenko]

On Thu, Aug 23, 2012 at 12:53:34AM +0400, Alexey Tourbin wrote:
> приемлемый результат.  Так что роботу следовало бы попросту косить все
> зависимости из спекфайлов под корень. :-)
 
Ок, тогда включу этот патчгенератор опять, 
когда проведу NMU.
не все сейчас морально готовы к применению NMU c удалением
%{get_version ...} в своих спек-файлах.

-- 

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] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 09:09:38AM +0300, Igor Vlasenko wrote:
> On Thu, Aug 23, 2012 at 12:53:34AM +0400, Alexey Tourbin wrote:
> > приемлемый результат.  Так что роботу следовало бы попросту косить все
> > зависимости из спекфайлов под корень. :-)
>  
> Ок, тогда включу этот патчгенератор опять, 
> когда проведу NMU.
> не все сейчас морально готовы к применению NMU c удалением
> %{get_version ...} в своих спек-файлах.

Надо было не просто формально искоренять %get_version, а разбираться в
каждом случае по смыслу, зачем эта зависимость была нужна.  Если такая
зависимость уточняет требования к библиотеке, которые выражаются на уровне
soname/set-version, то всю зависимость нужно выкосить под корень, а не
только %get_version.  Удаление одной только версии %get_version - это не
работа над пакетами, а сумбур и формализм, как у Д.Д.Шостаковича. :-)

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Michael Shigorin]

On Thu, Aug 23, 2012 at 10:06:23AM +0400, Alexey Tourbin wrote:
> Насчет индексов апта - set-версии составляют в них не более половины.
> Их удалось ужать до практичного размера.  Так что полагаю, что
> разговоры насчет объема индексов apt и создания "более
> эффективной системы" политически мотивированы.

Там бы скорее вынести факультативную информацию вроде %changelog
в сторонку так, чтоб можно было локально решить -- тащить или нет.
Поскольку от апта такого требовать было бы слишком много,
было предложено msp@ для обдумывания формирования метаданных
с применением deepsolver.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----        Sep 29, Kiev, Ukraine:
--       http://conference.osdn.org.ua

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Igor Vlasenko]

On Thu, Aug 23, 2012 at 11:42:05AM +0400, Alexey Tourbin wrote:
> Надо было не просто формально искоренять %get_version, а разбираться в
> каждом случае по смыслу, зачем эта зависимость была нужна.  Если такая
> зависимость уточняет требования к библиотеке, которые выражаются на уровне
> soname/set-version, то всю зависимость нужно выкосить под корень, а не
> только %get_version.  Удаление одной только версии %get_version - это не
> работа над пакетами, а сумбур и формализм, как у Д.Д.Шостаковича. :-)

Тогда, наверное, стОит включить тест, а отключить патчгенератор.

-- 

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] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 11:04:41AM +0300, Michael Shigorin wrote:
> On Thu, Aug 23, 2012 at 10:06:23AM +0400, Alexey Tourbin wrote:
> > Насчет индексов апта - set-версии составляют в них не более половины.
> > Их удалось ужать до практичного размера.  Так что полагаю, что
> > разговоры насчет объема индексов apt и создания "более
> > эффективной системы" политически мотивированы.
> 
> Там бы скорее вынести факультативную информацию вроде %changelog
> в сторонку так, чтоб можно было локально решить -- тащить или нет.
> Поскольку от апта такого требовать было бы слишком много,
> было предложено msp@ для обдумывания формирования метаданных
> с применением deepsolver.

%changelog хорошо сжимается, что снижает нагрузку при скачивании,
а также не участвует в разрешении зависимостей, что снижает нагрузку
на клиенте.  Короче, проблема скачивания всяких текстовых описаний -
немного дутая.

Проблема set-версий более тяжелая - они плохо сжимаются 6/8=75%,
при любом раскладе их нужно все скачать и обработать на клиенте,
прежде чем хоть что-то решить.  Имеются повышенные требования к
эффективности упаковки и эффективности распаковки.

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Sergey V Turchin]

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

On 23 августа 2012 00:53:34 Alexey Tourbin wrote:

[...]
> Set-версии формально не дают полной гарантии,
Они реально не дают полной гарантии, а не вормально.

> а какую тогда гарантию формально дает %get_version?
Немного другую, которой в set-версиях нет, т.к. они применимы не только к ABI, 
но и к API и к noarch.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Michael Shigorin]

On Thu, Aug 23, 2012 at 12:58:55PM +0400, Alexey Tourbin wrote:
> Короче, проблема скачивания всяких текстовых описаний -
> немного дутая.

При платном трафике она есть, люди грустят порой в отзывах.
Не смертельно, но ведь и пользу-то из этого добавления так
и не сделали (ЕМНИП собирались сделать возможность отсмотра
изменений по предложенному обновлению).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
 ----        Sep 29, Kiev, Ukraine:
--       http://conference.osdn.org.ua

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 02:33:27PM +0400, Sergey V Turchin wrote:
> > Set-версии формально не дают полной гарантии,
> Они реально не дают полной гарантии, а не вормально.

Полную гарантию дает только страховой полис.
Для libqt4-core set-версии хорошо очерчивают круг совместимых версий.
С интересом рассмотрю контрпримеры.

> > а какую тогда гарантию формально дает %get_version?
> Немного другую, которой в set-версиях нет, т.к. они применимы не только к ABI, 
> но и к API и к noarch.

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Sergey V Turchin]

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

On 23 августа 2012 17:03:54 Alexey Tourbin wrote:
> On Thu, Aug 23, 2012 at 02:33:27PM +0400, Sergey V Turchin wrote:
> > > Set-версии формально не дают полной гарантии,
> > 
> > Они реально не дают полной гарантии, а не вормально.
> 
> Полную гарантию дает только страховой полис.
Я тебя цитировал.

> Для libqt4-core set-версии хорошо очерчивают круг совместимых версий.
> С интересом рассмотрю контрпримеры.
Я не имел ввиду libqt4-core, но я лично наблюдал пример, где программа падала, 
хотя, с set-зависимостью было все в порядке. Если надо, укажу конкретно.
 
> > > а какую тогда гарантию формально дает %get_version?
> > 
> > Немного другую, которой в set-версиях нет, т.к. они применимы не только к
> > ABI, но и к API и к noarch.
> 
> Иногда стоит указать зависимость вручную - с минимальной версией,
> но привязка к текущей версии - это просто-таки дедовский метод конторля,
> да, не только ABI, но и API.  Достойный старых обезьян.
Ну да. К тому же еще и ленивых ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

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

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

On Thu, Aug 23, 2012 at 10:06:23AM +0400, Алексей Турбин wrote:

AT> Насчет индексов апта - set-версии составляют в них не более половины.
AT> Их удалось ужать до практичного размера.  Так что полагаю, что разговоры
AT> насчет объема индексов apt и создания "более эффективной системы" политически
AT> мотивированы.

Однако факт есть факт -- apt является жутким тормозом на нашем размере
пакетной базы.

На моем ноутбуке /usr/bin/time apt-cache search asterisk занимает:
2.06user 1.14system 0:16.71elapsed 19%CPU (0avgtext+0avgdata
125936maxresident)k
382000inputs+0outputs (390major+10698minor)pagefaults 0swaps

16 секунд для такой операции абсолютно неприемлимое время. 1с -- хорошо,
2с -- периемлимо, 10с -- недопустимо.

Судя по разнице между elapsed-(user+system) основное время было потрачено
на I/O.

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

http://mithraen.ru/
----------------------------------------------------------------------------

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 07:26:50PM +0400, Sergey V Turchin wrote:
> > Для libqt4-core set-версии хорошо очерчивают круг совместимых версий.
> > С интересом рассмотрю контрпримеры.
> Я не имел ввиду libqt4-core, но я лично наблюдал пример, где программа падала, 
> хотя, с set-зависимостью было все в порядке. Если надо, укажу конкретно.

Программа может падать из-за разыменовывания нулевого указателя.
Set-версии дают гарантию, что перед запуском программы имеются в наличии
все вызываемые функции.  (Следующий бастион - set-версии должны
гарантировать, что прототипы вызываемых функций соответствуют вызовам,
но для C++ это уже сейчас гарантируется автоматически из-за mangling.)
То есть set-версии дают гарантию, что то, что мы собираемся запустить,
в каком-то смысле вообще запускаемо.  То, что программа не будет падать,
set-версии гарантировать не могут.

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

> > > > а какую тогда гарантию формально дает %get_version?
> > > 
> > > Немного другую, которой в set-версиях нет, т.к. они применимы не только к
> > > ABI, но и к API и к noarch.
> > 
> > Иногда стоит указать зависимость вручную - с минимальной версией,
> > но привязка к текущей версии - это просто-таки дедовский метод конторля,
> > да, не только ABI, но и API.  Достойный старых обезьян.
> Ну да. К тому же еще и ленивых ;-)

Laziness is a virtue. :-)
Вся разница в том, что %get_version - это довольно толстый метод привязки
к текущей версии, а set-versions - это гораздо более тонкий метод привязки
к текущей версии. :-)

> -- 
> Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Thu, Aug 23, 2012 at 08:38:11PM +0400, Денис Смирнов wrote:
> On Thu, Aug 23, 2012 at 10:06:23AM +0400, Алексей Турбин wrote:
> 
> AT> Насчет индексов апта - set-версии составляют в них не более половины.
> AT> Их удалось ужать до практичного размера.  Так что полагаю, что разговоры
> AT> насчет объема индексов apt и создания "более эффективной системы" политически
> AT> мотивированы.
> 
> Однако факт есть факт -- apt является жутким тормозом на нашем размере
> пакетной базы.
> 
> На моем ноутбуке /usr/bin/time apt-cache search asterisk занимает:
> 2.06user 1.14system 0:16.71elapsed 19%CPU (0avgtext+0avgdata
> 125936maxresident)k
> 382000inputs+0outputs (390major+10698minor)pagefaults 0swaps
> 
> 16 секунд для такой операции абсолютно неприемлимое время. 1с -- хорошо,
> 2с -- периемлимо, 10с -- недопустимо.

Какой смысл критиковать апт за поиск по тексту?  Ты знаешь как он
работает?  Никакого вспомогательного индекса для этого нету, он просто
откупоривает скоченные pkglist.classic файлы и шестерит их.  Логика -
поиск всё равно выполняется пользователем, несколько секунд он подождет.

> Судя по разнице между elapsed-(user+system) основное время было потрачено
> на I/O.

Либо ядро глючит, либо слишком мало RAM на машине (меньше 2G).

$ l /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic
-rw-r--r-- 1 root root 60206098 Aug 21 23:08 /var/lib/apt/lists/_ALT_Sisyphus_x86%5f64_base_pkglist.classic

Ядру ведь надо где-то взять 60 метров, чтобы этот файл в память загрузить,
и еще несколько таких файлов есть.  А если у тебя фаерфокс запущен, или,
прости Господи, флеш плеер?  Ядро оно что, должно тебе взять кредит в
Банке реконструкции и развития?

> -- 
> С уважением, Денис
> 
> http://mithraen.ru/

Re: [devel] I: repocop test for %{get_version ...} is disabled.

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

On Fri, Aug 24, 2012 at 04:52:34AM +0400, Алексей Турбин wrote:

> Какой смысл критиковать апт за поиск по тексту?  Ты знаешь как он
> работает?  Никакого вспомогательного индекса для этого нету,

Только мне кажется что здесь первая и последняя фраза противоречат
друг-другу? :)

> он просто
> откупоривает скоченные pkglist.classic файлы и шестерит их.  Логика -
> поиск всё равно выполняется пользователем, несколько секунд он подождет.

16 это не несколько, это дофига. И как раз такую простую операцию как
поиск я лично ожидаю в такой ситуации видеть за 1с максимум.

AT> Либо ядро глючит, либо слишком мало RAM на машине (меньше 2G).

$ free -m
             total       used       free     shared    buffers     cached
Mem:          3032       2829        203          0        122       1275
-/+ buffers/cache:       1430       1601
Swap:         3906       1165       2740

AT> Ядру ведь надо где-то взять 60 метров, чтобы этот файл в память загрузить,
AT> и еще несколько таких файлов есть.

О ужас, оно еще и пытается целиком эти 60 метров втянуть? Там реально
нужен random доступ?

AT> А если у тебя фаерфокс запущен, или,
AT> прости Господи, флеш плеер?  Ядро оно что, должно тебе взять кредит в
AT> Банке реконструкции и развития?

Запущены chromium и emacs. Два самых страшных монстра. Они неплохо
соревнуются кто из них монструознее :-/

Но, кажется, мне придется часть наездов на apt забрать назад.
apt-get install bash (в системе где он установлен) выполняется более 10-и
секунд (это повторный запуск, когда большинство уже в кэше). 

Виновник обнаружен: rpm-dir. Я ожидал, что при его использовании кэш
строится только при apt-get update, видимо это не так.

Комментирование строчки с репозиторием (локальные сборки пакетов) сразу же
ускоряет в 5 раз.

apt-cache search стал работать за 3 секунды, что хоть по моему мнению и
тормоза, но в приличных рамках.


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

http://mithraen.ru/
----------------------------------------------------------------------------

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Sergey V Turchin]

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

On 24 августа 2012 04:40:15 Alexey Tourbin wrote:

[...]
> Конкретный пример меня всё еще интересует, если станет ясно, что там
> случилось.  Почему программа падала, а не сам факт падения.
При обновлении choqok c 1.0 до 1.1 но падал со старыми его библиотеками (из 
того же пакета). Скорее всего этот случай не заслуживает внимания, чтобы что-
то менять в алгоритмах set-версий, но это было.

[...]
> Вся разница в том, что %get_version - это довольно толстый метод привязки
> к текущей версии, а set-versions - это гораздо более тонкий метод привязки
> к текущей версии. :-)
Я ж уже объяснял, что set-versions покрывает только ABI библиотек, а в других 
случаях неудобно отслеживать и ставить зависимость на конкретную версию 
вручную. Понятно, что толстый, зато автомат.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Fri, Aug 24, 2012 at 08:12:41AM +0400, Денис Смирнов wrote:
> On Fri, Aug 24, 2012 at 04:52:34AM +0400, Алексей Турбин wrote:
> 
> > Какой смысл критиковать апт за поиск по тексту?  Ты знаешь как он
> > работает?  Никакого вспомогательного индекса для этого нету,
> 
> Только мне кажется что здесь первая и последняя фраза противоречат
> друг-другу? :)

Апт - это не поисковая система.  Но он умеет искать по скоченным файлам
методом их откупоривания и шестерения.  Потихоньку так.

> > он просто
> > откупоривает скоченные pkglist.classic файлы и шестерит их.  Логика -
> > поиск всё равно выполняется пользователем, несколько секунд он подождет.
> 
> 16 это не несколько, это дофига. И как раз такую простую операцию как
> поиск я лично ожидаю в такой ситуации видеть за 1с максимум.

Нет предмета для спора. :-)

> AT> Либо ядро глючит, либо слишком мало RAM на машине (меньше 2G).
> 
> $ free -m
>              total       used       free     shared    buffers     cached
> Mem:          3032       2829        203          0        122       1275
> -/+ buffers/cache:       1430       1601
> Swap:         3906       1165       2740
> 
> AT> Ядру ведь надо где-то взять 60 метров, чтобы этот файл в память загрузить,
> AT> и еще несколько таких файлов есть.
> 
> О ужас, оно еще и пытается целиком эти 60 метров втянуть? Там реально
> нужен random доступ?

Думаю, он читает этот файл по порядку, через rpmReadPackageHeader(),
и в каждом загловке ищет совпадения.

> AT> А если у тебя фаерфокс запущен, или,
> AT> прости Господи, флеш плеер?  Ядро оно что, должно тебе взять кредит в
> AT> Банке реконструкции и развития?
> 
> Запущены chromium и emacs. Два самых страшных монстра. Они неплохо
> соревнуются кто из них монструознее :-/
> 
> Но, кажется, мне придется часть наездов на apt забрать назад.
> apt-get install bash (в системе где он установлен) выполняется более 10-и
> секунд (это повторный запуск, когда большинство уже в кэше). 
> 
> Виновник обнаружен: rpm-dir. Я ожидал, что при его использовании кэш
> строится только при apt-get update, видимо это не так.

rpm-dir работает таким образом, что каждый раз заново сканирует все пакеты
в каталоге, причем из-за readahead(2) это означает, что каждый раз
считывается 128K, т.е. 32 страницы, несмотря на то, что заголовок пакета
может быть намного меньше.  Я пробовал отрубить readahead в lib/package.c,
не знаю работает или нет.

Короче, не надо валить все проблемы на апт - и проповедовать новую чудесную
"отечественную" систему, которая якобы решает все проблемы только в силу
своей чудодейственной альтернативности.

> Комментирование строчки с репозиторием (локальные сборки пакетов) сразу же
> ускоряет в 5 раз.
> 
> apt-cache search стал работать за 3 секунды, что хоть по моему мнению и
> тормоза, но в приличных рамках.
> 
> 
> -- 
> С уважением, Денис
> 
> http://mithraen.ru/

Re: [devel] I: repocop test for %{get_version ...} is disabled.

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

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

On Fri, Aug 24, 2012 at 06:13:03PM +0400, Алексей Турбин wrote:

AT> Апт - это не поисковая система.  Но он умеет искать по скоченным файлам
AT> методом их откупоривания и шестерения.  Потихоньку так.

Хочу заметить что это недостаток apt.
Поиск -- частая операция. И она должна выполняться быстро.

AT> Думаю, он читает этот файл по порядку, через rpmReadPackageHeader(),
AT> и в каждом загловке ищет совпадения.

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

AT> rpm-dir работает таким образом, что каждый раз заново сканирует все пакеты
AT> в каталоге, причем из-за readahead(2) это означает, что каждый раз
AT> считывается 128K, т.е. 32 страницы, несмотря на то, что заголовок пакета
AT> может быть намного меньше.  Я пробовал отрубить readahead в lib/package.c,
AT> не знаю работает или нет.

А почему rpm-dir работает именно так, а не строит индекс аналогично
остальным при apt-get update? Это баг или фича?

AT> Короче, не надо валить все проблемы на апт - и проповедовать новую чудесную
AT> "отечественную" систему, которая якобы решает все проблемы только в силу
AT> своей чудодейственной альтернативности.

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

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

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

http://mithraen.ru/
----------------------------------------------------------------------------


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

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Ildar Mulyukov]

On 24.08.2012 23:52:44, Денис Смирнов wrote:
> А почему rpm-dir работает именно так, а не строит индекс аналогично
> остальным при apt-get update? Это баг или фича?

Фича. Кому нужно с индексом, пользуются не rpm-dir, а rpm.
-- 
Ildar

Re: [devel] I: repocop test for %{get_version ...} is disabled.

[Alexey Tourbin]

On Fri, Aug 24, 2012 at 09:52:44PM +0400, Денис Смирнов wrote:
> AT> rpm-dir работает таким образом, что каждый раз заново сканирует все пакеты
> AT> в каталоге, причем из-за readahead(2) это означает, что каждый раз
> AT> считывается 128K, т.е. 32 страницы, несмотря на то, что заголовок пакета
> AT> может быть намного меньше.  Я пробовал отрубить readahead в lib/package.c,
> AT> не знаю работает или нет.
> 
> А почему rpm-dir работает именно так, а не строит индекс аналогично
> остальным при apt-get update? Это баг или фича?

А как он должен работать, куда он должен сохранить тебе построенный
индекс, даже если он привязывается, допустим, к mtimte каталога rpm-dir?
В том-то и смысл, что каталог сканируется на лету, и часто это быстрее,
чем поддержка отдельного состояния каталога.