Re: [devel] Requires optimization/pruning

Re: [devel] Requires optimization/pruning

[Michael Shigorin]

On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
> пришло в голову, что зависимости можно оптимизировать ещё сильнее:
> а именно, оптимизировать можно не только зависимости, удовлетворённые
> через Provides, но и зависимости, удовлетворенные через Requires! Ж-)
> 
> Пусть например пакет rpm требует две зависимости
> librpm = 4.0.4-alt16
> libc.so.6()(64bit)
> а пакет librpm в свою очередь требует среди прочих зависимость
> libc.so.6()(64bit)
> 
> Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
> То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
> лидер нации, через базовый подпакет.  Что в принципе имеет смысл.
> 
> Но там сложнее сделать, поскольку две Requires зависимости нельзя
> сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
> потому что обычно будут разные/несравнимые подможества.  А оптимизация
> зависимостей делается прежде всего, чтобы снизить нагрузку на
> pkglist/pkgcache и apt, которая подскочила из-за set-версий.

Может, всё-таки обрезать в pkglist, а не в самих пакетах?

Тогда пакеты будут нести достаточную индивидуальную информацию,
а pkglist-ы -- отражать достаточную совокупную на момент генерации.
(мысль высказана led@ и мне кажется разумной)

Если вырезать из самих пакетов -- очень большой шанс напороться
на ещё более неприятные грабли с разрывом цепочки, чем уже
предсказанные и происшедшие с BuildRequires (см. тж. buildreq -u):
http://lists.altlinux.org/pipermail/devel/2007-March/137289.html

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

Re: [devel] Requires optimization/pruning

[Alexey Tourbin]

On Wed, Mar 09, 2011 at 01:20:41PM +0200, Michael Shigorin wrote:
> On Sat, Feb 05, 2011 at 08:41:03AM +0300, Alexey Tourbin wrote:
> > Насчет оптимизации зависимостей между подпакетами.  Мне совсем недавно
> > пришло в голову, что зависимости можно оптимизировать ещё сильнее:
> > а именно, оптимизировать можно не только зависимости, удовлетворённые
> > через Provides, но и зависимости, удовлетворенные через Requires! Ж-)
> > 
> > Пусть например пакет rpm требует две зависимости
> > librpm = 4.0.4-alt16
> > libc.so.6()(64bit)
> > а пакет librpm в свою очередь требует среди прочих зависимость
> > libc.so.6()(64bit)
> > 
> > Тогда из пакета rpm можно удалить зависимость на libc.so.6()(64bit).
> > То есть некоторые зависимости подпакетов иногда "отоваривать", как говорит
> > лидер нации, через базовый подпакет.  Что в принципе имеет смысл.
> > 
> > Но там сложнее сделать, поскольку две Requires зависимости нельзя
> > сравнивать напрямую.  И это не будет хорошо работать с set-версиями,
> > потому что обычно будут разные/несравнимые подможества.  А оптимизация
> > зависимостей делается прежде всего, чтобы снизить нагрузку на
> > pkglist/pkgcache и apt, которая подскочила из-за set-версий.
> 
> Может, всё-таки обрезать в pkglist, а не в самих пакетах?
> 
> Тогда пакеты будут нести достаточную индивидуальную информацию,
> а pkglist-ы -- отражать достаточную совокупную на момент генерации.
> (мысль высказана led@ и мне кажется разумной)

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

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

А то можно договориться до того, что, например, в gcc нельзя инлайнировать
функции.  Потому что функции несут индвивидуальную информацию.

А выгоды от оптимизации довольно-таки ощутимы.

$ rpm -qR gcc4.5-c++
gcc4.5 = 4.5.1-alt8
libstdc++4.5-devel = 4.5.1-alt8
rpmlib(PayloadIsLzma)
$

> Если вырезать из самих пакетов -- очень большой шанс напороться
> на ещё более неприятные грабли с разрывом цепочки, чем уже
> предсказанные и происшедшие с BuildRequires (см. тж. buildreq -u):
> http://lists.altlinux.org/pipermail/devel/2007-March/137289.html

Если пакет A строго требует пакеты B и C, а пакет B строго требует пакет C,
то удаление из пакета A зависимости на пакет С логически ничего не меняет:
а именно, сохраняется гарантия, что при установке или обновлении пакета A
будет установлен пакет C, как если бы он был напрямую указан в
зависимостях пакета A.

Другими словами, rpm работает правильно, а грабли в других местах -
это грабли в других местах.

Re: [devel] Requires optimization/pruning

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

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

On Wed, Mar 09, 2011 at 02:24:13PM +0300, Алексей Турбин wrote:

AT> Если пакет A строго требует пакеты B и C, а пакет B строго требует пакет C,
AT> то удаление из пакета A зависимости на пакет С логически ничего не меняет:
AT> а именно, сохраняется гарантия, что при установке или обновлении пакета A
AT> будет установлен пакет C, как если бы он был напрямую указан в
AT> зависимостях пакета A.
AT> Другими словами, rpm работает правильно, а грабли в других местах -
AT> это грабли в других местах.

пакет B версии 1 требует C, а версии 2 вдруг не требует. Опаньки, все
сломалось.

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

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

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

Re: [devel] Requires optimization/pruning

[Dmitry V. Levin]

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

On Wed, Mar 09, 2011 at 05:01:35PM +0300, Денис Смирнов wrote:
> On Wed, Mar 09, 2011 at 02:24:13PM +0300, Алексей Турбин wrote:
> 
> AT> Если пакет A строго требует пакеты B и C, а пакет B строго требует пакет C,
> AT> то удаление из пакета A зависимости на пакет С логически ничего не меняет:
> AT> а именно, сохраняется гарантия, что при установке или обновлении пакета A
> AT> будет установлен пакет C, как если бы он был напрямую указан в
> AT> зависимостях пакета A.
> AT> Другими словами, rpm работает правильно, а грабли в других местах -
> AT> это грабли в других местах.
> 
> пакет B версии 1 требует C, а версии 2 вдруг не требует. Опаньки, все
> сломалось.

Есть одна важная деталь:
поскольку A, B и C это подпакеты одного пакета, собираемые одновременно,
можно считать, что гарантия сохраняется.

До тех пор, пока M не соберет какой-нибудь левый пакет, содержащий
Provides: B = %version-%release


-- 
ldv

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

[devel] Requires optimization/pruning seems broken

[Michael Shigorin]

On Wed, Mar 09, 2011 at 02:24:13PM +0300, Alexey Tourbin wrote:
> В общем с моей точки зрения тут лучше не философствовать насчёт
> сущностей, а рассуждать с точки зрения сохранения гарантий.

А кто их давал, кстати? :)

> Получим ли мы всегда то же самое, если мы применим оптимизацию?
> Да, эмпирически при установке и обновлении пакетов мы всегда
> получаем то же самое.  Значит, оптимизация корректна.

Было:

$ hsh-rmchroot ~/hasher/tmpfs                          
$ hsh --initroot-only --apt-config=/home/mike/apt/apt.conf.test ~/hasher/tmpfs >&/dev/null
$ hsh-install ~/hasher/tmpfs libwxGTK-devel 2>&1 | grep wx                                          
<13>Mar 11 19:24:54 rpmi: libwxGTK-2:2.8.11.0-alt1.svn20100628.3 installed
<13>Mar 11 19:24:54 rpmi: wxGTK-2:2.8.11.0-alt1.svn20100628.3 installed
<13>Mar 11 19:24:54 rpmi: libwxGTK-devel-2:2.8.11.0-alt1.svn20100628.3 installed

Стало:

$ hsh-rmchroot ~/hasher/tmpfs                          
$ hsh --initroot-only ~/hasher/tmpfs >&/dev/null
$ hsh-install ~/hasher/tmpfs libwxGTK-devel 2>&1 | grep wx  
<13>Mar 11 19:16:20 rpmi: libwxGTK-devel-2:2.8.11.0-alt1.svn20100628.4 installed

--- /home/mike/apt/apt.conf.test
Dir::Etc::main "/dev/null";
Dir::Etc::parts "/var/empty";
Dir::Etc::SourceParts "/var/empty";
Dir::Etc::sourcelist "/home/mike/apt/sources.list.test";
---

--- /home/mike/apt/sources.list.test
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/Sisyphus/2010/12/05 x86_64 classic
rpm [alt] http://ftp.altlinux.org/pub/distributions/archive/Sisyphus/2010/12/05 noarch classic
---

> Если пакет A строго требует пакеты B и C, а пакет B строго
> требует пакет C, то удаление из пакета A зависимости на пакет С
> логически ничего не меняет: а именно, сохраняется гарантия, что
> при установке или обновлении пакета A будет установлен пакет C,
> как если бы он был напрямую указан в зависимостях пакета A.
> Другими словами, rpm работает правильно, а грабли в других
> местах - это грабли в других местах.

Тогда поясни, почему пересборки этим rpm (sans -g)
хватило для слома пакета:

http://git.altlinux.org/people/real/packages/?p=wxGTK.git;a=commitdiff;h=68d12cab85fb7b32ec2d7b0f52065aa2babd05c3

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

Re: [devel] Requires optimization/pruning is broken

[Dmitry V. Levin]

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

On Fri, Mar 11, 2011 at 09:29:59PM +0200, Michael Shigorin wrote:
> On Wed, Mar 09, 2011 at 02:24:13PM +0300, Alexey Tourbin wrote:
> > В общем с моей точки зрения тут лучше не философствовать насчёт
> > сущностей, а рассуждать с точки зрения сохранения гарантий.
> 
> А кто их давал, кстати? :)
> 
> > Получим ли мы всегда то же самое, если мы применим оптимизацию?
> > Да, эмпирически при установке и обновлении пакетов мы всегда
> > получаем то же самое.  Значит, оптимизация корректна.
> 
> Было:
> Стало:

Оптимизатор неправильно обрабатывает циклические зависимости:
http://git.altlinux.org/gears/w/wxGTK.git?p=wxGTK.git;a=blob;f=.gear/wxGTK.spec#l31
http://git.altlinux.org/gears/w/wxGTK.git?p=wxGTK.git;a=blob;f=.gear/wxGTK.spec#l43
http://git.altlinux.org/gears/w/wxGTK.git?p=wxGTK.git;a=blob;f=.gear/wxGTK.spec#l67

В данном случае этот цикл похож на ошибку упаковки, но по сути оптимизатор
глючит.


-- 
ldv

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

Re: [devel] Requires optimization/pruning is broken

[Michael Shigorin]

On Fri, Mar 11, 2011 at 11:20:47PM +0300, Dmitry V. Levin wrote:
> В данном случае этот цикл похож на ошибку упаковки,
> но по сути оптимизатор глючит.

Credits: led@

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

Re: [devel] Requires optimization/pruning is broken

[Yuri N. Sedunov]

В Птн, 11/03/2011 в 23:20 +0300, Dmitry V. Levin пишет:
> On Fri, Mar 11, 2011 at 09:29:59PM +0200, Michael Shigorin wrote:
> > On Wed, Mar 09, 2011 at 02:24:13PM +0300, Alexey Tourbin wrote:
> > > В общем с моей точки зрения тут лучше не философствовать насчёт
> > > сущностей, а рассуждать с точки зрения сохранения гарантий.
> > 
> > А кто их давал, кстати? :)
> > 
> > > Получим ли мы всегда то же самое, если мы применим оптимизацию?
> > > Да, эмпирически при установке и обновлении пакетов мы всегда
> > > получаем то же самое.  Значит, оптимизация корректна.
> > 
> > Было:
> > Стало:
> 
> Оптимизатор неправильно обрабатывает циклические зависимости:
> http://git.altlinux.org/gears/w/wxGTK.git?p=wxGTK.git;a=blob;f=.gear/wxGTK.spec#l31
> http://git.altlinux.org/gears/w/wxGTK.git?p=wxGTK.git;a=blob;f=.gear/wxGTK.spec#l43
> http://git.altlinux.org/gears/w/wxGTK.git?p=wxGTK.git;a=blob;f=.gear/wxGTK.spec#l67
> 
> В данном случае этот цикл похож на ошибку упаковки, но по сути оптимизатор
> глючит.

Как раз сегодня отловил ошибку в usbmuxd, где у подпакета libusbmuxd
была ошибочно проставлена зависимость на себя самого. В результате
"оптимизации" libusbmuxd-devel не получил зависимость на libusbmuxd.

-- 
Yuri N. Sedunov

Re: [devel] Requires optimization/pruning is severely broken

[Dmitry V. Levin]

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

On Fri, Mar 11, 2011 at 10:27:17PM +0200, Michael Shigorin wrote:
> On Fri, Mar 11, 2011 at 11:20:47PM +0300, Dmitry V. Levin wrote:
> > В данном случае этот цикл похож на ошибку упаковки,
> > но по сути оптимизатор глючит.
> 
> Credits: led@

Credits: freeciv.
Этот оптимизатор выкинул *все* зависимости из виртуального пакета freeciv,
кроме rpmlib(PayloadIsLzma)!
Кто не верит, можете посмотреть в #40357, когда тестовое задание соберется.

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


-- 
ldv

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

Re: [devel] Requires optimization/pruning is severely broken

[REAL]

12.03.2011 02:39, Dmitry V. Levin пишет:
> Пожалуй, пора останавливать сборочный конвейер, пока хоть какие-то
> зависимости сохранились.

надеюсь, очередь останется? т.е. не придётся заново таски заводить?

-- 

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

Re: [devel] Requires optimization/pruning is severely broken

[Dmitry V. Levin]

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

On Sat, Mar 12, 2011 at 02:53:50AM +0600, REAL wrote:
> 12.03.2011 02:39, Dmitry V. Levin пишет:
> >Пожалуй, пора останавливать сборочный 
> >конвейер, пока хоть какие-то
> >зависимости сохранились.
> 
> надеюсь, очередь останется? т.е. не 
> придётся заново таски заводить?

Если остановить конвейер, то очередь не просто останется, а даже вырастет.


-- 
ldv

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

Re: [devel] Requires optimization/pruning is severely broken

[REAL]

12.03.2011 02:55, Dmitry V. Levin пишет:
>> надеюсь, очередь останется? т.е. не
>> придётся заново таски заводить?
>
> Если остановить конвейер, то очередь не просто останется, а даже вырастет.

я всё же удалил свои (кроме free-cad, который сейчас собирается... 
кстати, может быть, вы сможете убить это задание как 
суперпользователь? не хотелось бы потом по-новой собирать).

-- 

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