[devel] rpm 4.0.4-alt87

[devel] rpm 4.0.4-alt87

[@ 2008-02-24 18:01 UTC (permalink / raw)]

[devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[@ 2008-02-24 19:29 UTC (permalink / raw)]

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[@ 2008-02-24 22:53 UTC (permalink / raw)]

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[Alexey Tourbin]

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

On Mon, Feb 25, 2008 at 01:53:36AM +0300, Alexey Rusakov wrote:
> > Кстати, встал вопрос, как более грамотно выражаться на человеческом
> > языке.  А именно, имеется в виду вариант
> > 
> > -functions (ValidateBuildRoot): require RPM_BUILD_ROOT path be canonical
> > +functions (ValidateBuildRoot): require RPM_BUILD_ROOT path to be
> > canonical
> to require не бывает модальным глаголом, поэтому to обязательно.

Вы таки хорошо знать человеческий язык (и что такое subjunctive mode)?
Если гуглом поискать "require * be *" (с кавычками), то станет понять,
что люди использовать "to" как минимум не всегда.

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

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[Alexey Rusakov]

On Mon, 25 Feb 2008 06:33:07 +0300
Alexey Tourbin wrote:

> On Mon, Feb 25, 2008 at 01:53:36AM +0300, Alexey Rusakov wrote:
> > > Кстати, встал вопрос, как более грамотно выражаться на человеческом
> > > языке.  А именно, имеется в виду вариант
> > > 
> > > -functions (ValidateBuildRoot): require RPM_BUILD_ROOT path be canonical
> > > +functions (ValidateBuildRoot): require RPM_BUILD_ROOT path to be canonical
> > to require не бывает модальным глаголом, поэтому to обязательно.
> 
> Вы таки хорошо знать человеческий язык (и что такое subjunctive mode)?
> Если гуглом поискать "require * be *" (с кавычками), то станет понять,
> что люди использовать "to" как минимум не всегда.
Извините, а при чём здесь сослагательное наклонение вообще? Указывается
требование, которое должно быть выполнено, никакой условности или
вероятности. Что касается to - я настаиваю, что to в этой конструкции
обязательно. Да, вместо require ... to be ... нередко используется
конструкция require that ... is/am/be ..., из которой затем вываливается
that, потому что that вообще часто выбрасывают. Лично я придерживаюсь
консервативной точки зрения, что либо that, либо to присутствовать должны.

-- 
  Alexey "Ktirf" Rusakov
  Head of System development dept.
  ALT Linux Ltd.

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[Alexey Tourbin]

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

On Mon, Feb 25, 2008 at 10:49:10AM +0300, Alexey Rusakov wrote:
> > > > -functions (ValidateBuildRoot): require RPM_BUILD_ROOT path be canonical
> > > > +functions (ValidateBuildRoot): require RPM_BUILD_ROOT path to be canonical
> > > to require не бывает модальным глаголом, поэтому to обязательно.
> > 
> > Вы таки хорошо знать человеческий язык (и что такое subjunctive mode)?
> > Если гуглом поискать "require * be *" (с кавычками), то станет понять,
> > что люди использовать "to" как минимум не всегда.
> Извините, а при чём здесь сослагательное наклонение вообще?

А при том что тут сослагательное наклонение.  Может быть.
"Let my people go" -> "Require RPM_BUILD_ROOT path be".

> Указывается требование, которое должно быть выполнено, никакой
> условности или вероятности.

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

> Что касается to - я настаиваю, что to в этой конструкции
> обязательно.

Huh...
Если у Вас есть TOEFL то может быть соглашусь.

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

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[Alexey Rusakov]

On Sun, 9 Mar 2008 19:12:59 +0300
Alexey Tourbin wrote:

> > Что касается to - я настаиваю, что to в этой конструкции
> > обязательно.
> 
> Huh...
> Если у Вас есть TOEFL то может быть соглашусь.
Облом, мне не нужен TOEFL, я как-то без него справляюсь. Так что лучше не
соглашайтесь :)

-- 
  Alexey "Ktirf" Rusakov
  Head of Systems development dept.
  ALT Linux Technology

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[Alexey Tourbin]

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

On Sun, Mar 09, 2008 at 08:03:18PM +0300, Alexey Rusakov wrote:
> > > Что касается to - я настаиваю, что to в этой конструкции
> > > обязательно.
> > 
> > Huh...
> > Если у Вас есть TOEFL то может быть соглашусь.
> Облом, мне не нужен TOEFL, я как-то без него справляюсь. Так что лучше не
> соглашайтесь :)

Вам истина дороже или что?  В принципе я уже однажды обещал Вас
пристрелить, к тому же причина это сделать никуда не исчезла. 

$ hsh-run -- rpm -e --test python-modules-xml
error: removing these packages would break dependencies:
        python2.5(xml)   is needed by glib2-devel-2.15.6-alt1
        python2.5(xml)   is needed by libgtk+2-common-2.12.8-alt1
$

https://bugzilla.altlinux.org/show_bug.cgi?id=13377
Готовьтесь.

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

Re: [devel] libgtk+2-common-2.12.8-alt1

[Dmitry V. Levin]

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

On Sun, Mar 09, 2008 at 09:08:21PM +0300, Alexey Tourbin wrote:
[...]
> $ hsh-run -- rpm -e --test python-modules-xml
> error: removing these packages would break dependencies:
>         python2.5(xml)   is needed by glib2-devel-2.15.6-alt1
>         python2.5(xml)   is needed by libgtk+2-common-2.12.8-alt1
> $
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=13377
> Готовьтесь.

Тебе было бы быстрее решить вопрос с зависимостями пакета
libgtk+2-common самому.


-- 
ldv

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

Re: [devel] [JT] subjunctive mode (rpm 4.0.4-alt87)

[Alexey Rusakov]

On Sun, 9 Mar 2008 21:08:21 +0300
Alexey Tourbin wrote:

> https://bugzilla.altlinux.org/show_bug.cgi?id=13377
О, спасибо что напомнили, хоть и не в топик. Пойду исправлю.

-- 
  Alexey "Ktirf" Rusakov
  Head of Systems development dept.
  ALT Linux Technology

Re: [devel] rpm 4.0.4-alt87

[Stanislav Ievlev]

Может стоит отделить ALT-specific наработки в rpm в отдельный пакет? А то
теоретическая  миграция на 5.0 становится всё сложнее и сложнее.

On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> После некоторых колебаний я подготовил новую сборку rpm.
> 
>     4.0.4-alt87
>     
>     - implemented automatic dependencies for %%pre, %%preun, %%post,
>       and %%postun scriptlets (#7409)
>     - find-package: when possible, keep file-level dependencies as is,
>       without mapping them to package names
>     - find-package: relax file-level dependencies on unpackaged directories
>     - find-package: optimize out bulk dependencies on sh, cat, rm, mv etc.
>     - build/parseScript.c: optimize out RPMSENSE_INTERP dependencies on /bin/sh
>     - lib.req: enabled ELF_INTERP dependencies except for standard /lib/ld-linux.so.2
>     - functions (ValidateBuildRoot): require RPM_BUILD_ROOT path be canonical
> 
> Прокомментирую основные изменения:
> 
> 1) Поиск зависимостей в %post-скритпах.  Теперь зависимости 
> %post-скриптов вида Requires(post): ... можно не писать вручную (и лучше
> вообще не писать без особой нужды).  Реализация мне не очень нравится,
> но на практике это не должно повлиять на конечный результат (реализацию
> можно будет переделать, если станет понятно, как это можно сделать
> лучше).
> 
> Ранее я уже писал, что нужно понимать некоторые особенности работы
> shell.req, чтобы зависимости в шелл-коде %post-скриптов генерировались
> наиболее приемлемым образом.  В частности, если зависимости быть не
> должно (если она не строгая), то команды в шелл-коде нужно заворачивать
> в переменные:
> 
> 	x=/usr/bin/x
> 	if [ -x "$x" ]; then
> 		"$x"
> 	fi
> 
> В отличие от реализации jbj@ (в апстриме rpm), поиск зависимостей
> работает не только для shell-кода (например, если %post-скрипт написан
> на перле -- "%post -p /usr/bin/perl" -- то будет работать поиск перловых
> зависимостей).
> 
> 2) Когда путь к файлу указан явно, rpm теперь будет стараться сохранить
> зависимость на этот файл as is, без поиска соответствующего пакета,
> который содержит этот файл.  Это пока возможно не для всех путей (для
> некоторых путей это может дать "полу-анметы"), но для многих -- возможно.
> 
> Идея в том, что когда где-то требуется путь к файлу, то наиболее точный
> способ указать зависимость -- это просто вставить этот путь в
> зависимости.  Вот пример, когда это желательно.  Пусть в пакете
> используется /usr/bin/tclsh8.4.  Тогда старый rpm разрешал эту
> зависимость в пакет tcl (версии 8.4).  Новый пакет tcl (версии 8.5)
> уже не содержит файла /usr/bin/tclsh8.4, но зависимость на пакет tcl
> остаётся, естественно, удовлетворенной (то есть получаем нерабочий
> пакет).  После же пересборки старый rpm изменил бы зависимость
> s/tcl/tcl8.4/.  Всего этого можно избежать, если не делать "производных"
> зависимостей, а стараться указывать зависимости в их наиболее
> "первоначальном" виде.  Здесь имеется полная аналогия с виртуальными
> зависимостями -- они как раз предназначены для того, чтобы указывать
> зависимости в наиболее точном "первичном" виде.
> 
> Чтобы не появилось слишком много bulk зависимостей, я реализовал
> оптимизацию, которая удаляет следующие зависимости (как "команды"
> в шелл-скриптах, так и соответствующие им /bin/ пути):
> 	sh cat rm mv cp mkdir ln
> 
> (список можно будет немного увеличить, если кто-нибудь захочет
> составить более точную статистику, чем у меня получилось с ходу).
> 
> Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> не окончательно поломанной среде эти зависимости должны быть
> заведомо удовлетворены.
> 
> Это изменение не затрагивает случая, когда известна только "команда"
> (из шелл-срипта) и поиск зависимости на эту команду идёт через перебор
> каталогов по default PATH.  Здесь осталось всё по-старому (как правило,
> генерируется зависимость на имя пакета, содержащего "команду").
> 
> 
> 2ldv: лучше собрать его два раза, второй раз --with-stuff.



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] rpm 4.0.4-alt87

[Mikhail Gusarov]

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

Twas brillig at 13:36:42 25.02.2008 UTC+03 when Stanislav Ievlev did gyre and gimble:

 SI> Может стоит отделить ALT-specific наработки в rpm в отдельный
 SI> пакет? А то теоретическая миграция на 5.0 становится всё сложнее и
 SI> сложнее.

Имхо, не сложнее и не легче: какая разница, где патчсет?

-- 

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

Re: [devel] rpm 4.0.4-alt87

[Dmitry V. Levin]

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

On Mon, Feb 25, 2008 at 01:36:42PM +0300, Stanislav Ievlev wrote:
> Может стоит отделить ALT-specific наработки в rpm в отдельный пакет?

Стас, они там повсюду.

> А то теоретическая миграция на 5.0 становится всё сложнее и сложнее.

Нет, сложнее уже некуда. :)


-- 
ldv

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

Re: [devel] rpm 4.0.4-alt87

[Dmitry V. Levin]

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

On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
[...]
> Чтобы не появилось слишком много bulk зависимостей, я реализовал
> оптимизацию, которая удаляет следующие зависимости (как "команды"
> в шелл-скриптах, так и соответствующие им /bin/ пути):
> 	sh cat rm mv cp mkdir ln
> 
> (список можно будет немного увеличить, если кто-нибудь захочет
> составить более точную статистику, чем у меня получилось с ходу).
> 
> Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> не окончательно поломанной среде эти зависимости должны быть
> заведомо удовлетворены.

В результате у пакета rpm появилась зависимость на /bin/chgrp; в чём смысл?


-- 
ldv

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Mon, Feb 25, 2008 at 11:48:33PM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> [...]
> > Чтобы не появилось слишком много bulk зависимостей, я реализовал
> > оптимизацию, которая удаляет следующие зависимости (как "команды"
> > в шелл-скриптах, так и соответствующие им /bin/ пути):
> > 	sh cat rm mv cp mkdir ln
> > 
> > (список можно будет немного увеличить, если кто-нибудь захочет
> > составить более точную статистику, чем у меня получилось с ходу).
> > 
> > Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> > не окончательно поломанной среде эти зависимости должны быть
> > заведомо удовлетворены.
> 
> В результате у пакета rpm появилась зависимость на /bin/chgrp; в чём смысл?

Если в системе нет /bin/chgrp, то %post-скрипт не отработает.

$ rpm -q --scripts rpm |grep chgrp
        /bin/chgrp rpm /var/lib/rpm/*.rpm
        /bin/chgrp rpm /var/lib/rpm/[A-Z]*
$

Значит, смысл в том, что указана точная зависимость -- /bin/chgrp.

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

Re: [devel] rpm 4.0.4-alt87

[Dmitry V. Levin]

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

On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
[...]
> Чтобы не появилось слишком много bulk зависимостей, я реализовал
> оптимизацию, которая удаляет следующие зависимости (как "команды"
> в шелл-скриптах, так и соответствующие им /bin/ пути):
> 	sh cat rm mv cp mkdir ln
> 
> (список можно будет немного увеличить, если кто-нибудь захочет
> составить более точную статистику, чем у меня получилось с ходу).
> 
> Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> не окончательно поломанной среде эти зависимости должны быть
> заведомо удовлетворены.

Боюсь что эту оптимизацию придётся убрать,
иначе порядок установки пакетов в пустую систему может испортиться.


-- 
ldv

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Wed, Feb 27, 2008 at 07:46:04PM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> [...]
> > Чтобы не появилось слишком много bulk зависимостей, я реализовал
> > оптимизацию, которая удаляет следующие зависимости (как "команды"
> > в шелл-скриптах, так и соответствующие им /bin/ пути):
> > 	sh cat rm mv cp mkdir ln
> > 
> > (список можно будет немного увеличить, если кто-нибудь захочет
> > составить более точную статистику, чем у меня получилось с ходу).
> > 
> > Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> > не окончательно поломанной среде эти зависимости должны быть
> > заведомо удовлетворены.
> 
> Боюсь что эту оптимизацию придётся убрать,
> иначе порядок установки пакетов в пустую систему может испортиться.

Я об этом думал.  Другая похожая возможность нарушения порядка --
это использование 'rpmi --root chroot/' при отсутствии rpm в чруте.

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

Насколько я вижу, сейчас есть всего один пакет, который "меньше" rpm
и в котором есть shell-скриптлет -- coreutils, в котором дёргается
install-info.  Значит, в coreutils желательно вручную прописать
зависимость на /bin/sh.  Ещё в принципе желательно добавить зависимость
на /bin/sh в info-install.

Таким образом, если заморачиваться этой гипотетической проблемой,
то зависимость на /bin/sh нужна в трёх местах -- rpm, coreutils
и info-install.  Я считаю это достаточно надёжной конструкцией --
больше нигде зависимость на /bin/sh можно не ставить.

С другой стороны, в hasher используется специальная процедура
инициализации чрута, которая НЕ ПОЛАГАЕТСЯ на порядок установки
базовых пакетов.

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

Re: [devel] rpm 4.0.4-alt87

[Dmitry V. Levin]

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

On Thu, Feb 28, 2008 at 09:00:53PM +0300, Alexey Tourbin wrote:
> On Wed, Feb 27, 2008 at 07:46:04PM +0300, Dmitry V. Levin wrote:
> > On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> > [...]
> > > Чтобы не появилось слишком много bulk зависимостей, я реализовал
> > > оптимизацию, которая удаляет следующие зависимости (как "команды"
> > > в шелл-скриптах, так и соответствующие им /bin/ пути):
> > > 	sh cat rm mv cp mkdir ln
> > > 
> > > (список можно будет немного увеличить, если кто-нибудь захочет
> > > составить более точную статистику, чем у меня получилось с ходу).
> > > 
> > > Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> > > не окончательно поломанной среде эти зависимости должны быть
> > > заведомо удовлетворены.
> > 
> > Боюсь что эту оптимизацию придётся убрать,
> > иначе порядок установки пакетов в пустую систему может испортиться.
> 
> Я об этом думал.  Другая похожая возможность нарушения порядка --
> это использование 'rpmi --root chroot/' при отсутствии rpm в чруте.

Ну это и есть вариант установки пакетов в пустую систему.

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

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

> Насколько я вижу, сейчас есть всего один пакет, который "меньше" rpm
> и в котором есть shell-скриптлет -- coreutils, в котором дёргается
> install-info.  Значит, в coreutils желательно вручную прописать
> зависимость на /bin/sh.  Ещё в принципе желательно добавить зависимость
> на /bin/sh в info-install.

А как быть с зависимостями на coreutils?  Их тоже предлагается optimize out
в сочетании с гарантией того, что coreutils должен быть установлен раньше
других пакетов?

В любом случае убирать автозависимости вида /bin/cp не вижу смысла: обычно
такие зависимости это признак ошибки неиспользования $PATH.

> Таким образом, если заморачиваться этой гипотетической проблемой,
> то зависимость на /bin/sh нужна в трёх местах -- rpm, coreutils
> и info-install.  Я считаю это достаточно надёжной конструкцией --
> больше нигде зависимость на /bin/sh можно не ставить.

А как гарантировать, что эти три кита будут установлены раньше других
зависимых пакетов, если действует оптимизация зависимостей на coreutils?

> С другой стороны, в hasher используется специальная процедура
> инициализации чрута, которая НЕ ПОЛАГАЕТСЯ на порядок установки
> базовых пакетов.

Да, не о hasher речь.


-- 
ldv

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Thu, Feb 28, 2008 at 09:34:19PM +0300, Dmitry V. Levin wrote:
> > Насколько я вижу, сейчас есть всего один пакет, который "меньше" rpm
> > и в котором есть shell-скриптлет -- coreutils, в котором дёргается
> > install-info.  Значит, в coreutils желательно вручную прописать
> > зависимость на /bin/sh.  Ещё в принципе желательно добавить зависимость
> > на /bin/sh в info-install.
> 
> А как быть с зависимостями на coreutils?  Их тоже предлагается optimize out
> в сочетании с гарантией того, что coreutils должен быть установлен раньше
> других пакетов?

Так я думал.  Точнее, я думал, что такая система является non-conforming
(не удовлетворяющая положениям стандартов, которые утверждают, что в
любой системе должны присутствовать /bin/sh, /bin/rm и т.д.), поэтому
такие системы я наскоро исключил из своего обдумывания. :)

> В любом случае убирать автозависимости вида /bin/cp не вижу смысла: обычно
> такие зависимости это признак ошибки неиспользования $PATH.

Ну уж не такая это и ошибка, хотя и для явного указания путей на базовые
системные команды обычно нет хорошей причины.  Просто ещё есть дефолтный
alias cp='cp -i', он вообще-то не активизируется для неинтерактивных
шеллов (в скриптах), но иногда всё равно хочется его избегать. :)

> > Таким образом, если заморачиваться этой гипотетической проблемой,
> > то зависимость на /bin/sh нужна в трёх местах -- rpm, coreutils
> > и info-install.  Я считаю это достаточно надёжной конструкцией --
> > больше нигде зависимость на /bin/sh можно не ставить.
> 
> А как гарантировать, что эти три кита будут установлены раньше других
> зависимых пакетов, если действует оптимизация зависимостей на coreutils?

Получается, что никак.  Но, с другой стороны, наличие /bin/sh и как
минимум некоторых команд из coreutils -- это свойство conforming среды.

Кстати, библиотечная функция system(3) неявно требует /bin/sh.  Не
значит ли это, что в пакет glibc-core нужно добавить зависимость на
/bin/sh?  Ведь гипотетически возможно, что, допустим, в "%post -p
/usr/bin/post" в программе на Си (/usr/bin/post) используется system(3),
и всё обломится.

В общем, возможны два разных подхода:
1) полагаемся на то, что есть корректно инициализированная conforming
минимальная рабочая среда; можно кое-что оптимизировать;
2) ни на что не полагаемся, ничего не оптимизируем.

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

Re: [devel] Q: rpmi --chroot

[Dmitry V. Levin]

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

On Thu, Feb 28, 2008 at 10:05:17PM +0300, Alexey Tourbin wrote:
[...]
> В общем, возможны два разных подхода:
> 1) полагаемся на то, что есть корректно инициализированная conforming
> минимальная рабочая среда; можно кое-что оптимизировать;
> 2) ни на что не полагаемся, ничего не оптимизируем.

Короче говоря, в практической плоскости вопрос получается такой:

Нас интересует поддержка установки системы с нуля одной транзакцией с помощью
"rpmi --chroot" или нет?  Если интересует, то оптимизировать нельзя.
Если не интересует, то других причин не оптимизировать я не вижу.


-- 
ldv

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

Re: [devel] Q: rpmi --chroot

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Нас интересует поддержка установки системы с нуля одной транзакцией с помощью
> "rpmi --chroot" или нет?  Если интересует, то оптимизировать нельзя.
> Если не интересует, то других причин не оптимизировать я не вижу.

Всё-таки вмешаюсь в дискуссию. Хочу напомнить что ваш инсталлятор
сейчас делает именно "rpmi --chroot". Если вы хотите от этого
отказаться, нужно придумать альтернативу такой установки.

-- 
Rgrds, legion

Re: [devel] Q: rpmi --chroot

[Dmitry V. Levin]

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

On Fri, Feb 29, 2008 at 12:09:44AM +0300, Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> > Нас интересует поддержка установки системы с нуля одной транзакцией с помощью
> > "rpmi --chroot" или нет?  Если интересует, то оптимизировать нельзя.
> > Если не интересует, то других причин не оптимизировать я не вижу.
> 
> Всё-таки вмешаюсь в дискуссию.

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

> Хочу напомнить что ваш инсталлятор

Наш инсталлятор ;)

> сейчас делает именно "rpmi --chroot".

Одной транзакцией?

> Если вы хотите от этого отказаться,
> нужно придумать альтернативу такой установки.


-- 
ldv

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

Re: [devel] Q: rpmi --chroot

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Я же специально сформулировал вопрос в такой форме,
> чтобы заинтересованные люди откликнулись.

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

> Одной транзакцией?

Сейчас в инсталлере базовая система ставится через манифест-файл т.е.
одной транзакцией. После пакеты доставляются штатным образом через 	apt.

-- 
Rgrds, legion

Re: [devel] Q: rpmi --chroot

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Gladkov <legion-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > Dmitry V. Levin wrote:
 >> Я же специально сформулировал вопрос в такой форме,
 >> чтобы заинтересованные люди откликнулись.

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

 >> Одной транзакцией?

 > Сейчас в инсталлере базовая система ставится через манифест-файл т.е.
 > одной транзакцией. После пакеты доставляются штатным образом через 	apt.

Инсталлятор junior/dvd ставит все пакеты (несколько сотен) одной
транзакцией (удивительно, но это возможно).

-- 

Re: [devel] Q: rpmi --chroot

[Sergey Bolshakov]

>>>>> "Sergey" == Sergey Bolshakov <sbolshakov-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
 > Инсталлятор junior/dvd ставит все пакеты (несколько сотен) одной
 > транзакцией (удивительно, но это возможно).

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

-- 

Re: [devel] Q: rpmi --chroot

[Alexey Tourbin]

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

On Fri, Feb 29, 2008 at 02:08:27AM +0300, Sergey Bolshakov wrote:
> >>>>> "Sergey" == Sergey Bolshakov <sbolshakov-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
>  > Инсталлятор junior/dvd ставит все пакеты (несколько сотен) одной
>  > транзакцией (удивительно, но это возможно).

Воистину удивительно!

> Вдогонку: мне представляется, что введение в оборот ещё
> одной сущности вроде minimalsystem или conforming-chroot
> (ха, это даже не сферический конь, это сферический орловский рысак)
> должно вызывать возражения как со стороны пуристов (бритва оккама),
> так и со стороны затюканных практиков (работает -- не трожь).

Такие сущности уже и так кое-где имеются, например в
/usr/bin/hsh-sh-functions:
   162  # initial stage package file list
   163  pkg_init_list='setup filesystem rpm fakeroot>=0:0.7.3'

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

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

Re: [devel] Q: rpmi --chroot

[Alexey Tourbin]

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

On Fri, Feb 29, 2008 at 12:09:44AM +0300, Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> > Нас интересует поддержка установки системы с нуля одной транзакцией с помощью
> > "rpmi --chroot" или нет?  Если интересует, то оптимизировать нельзя.
> > Если не интересует, то других причин не оптимизировать я не вижу.
> 
> Всё-таки вмешаюсь в дискуссию. Хочу напомнить что ваш инсталлятор
> сейчас делает именно "rpmi --chroot". Если вы хотите от этого
> отказаться, нужно придумать альтернативу такой установки.

От инсталлятора (в случае оптимизации зависимостей) требуется лишь,
чтобы он инсталлировал в два этапа: сначала установка rpm (или хотя
бы coreutils + /bin/sh); а потом установка всего остального.  То есть
инициализация минимального conforming чрута должна быть отделена
"барьером" от установки дополнительных пакетов; тогда проблем с
неправильным порядком устновки пакетов не будет, даже при достаточно
сильной оптимизации (или же эти проблемы решаются точечным выправлением
зависимостей в двух местах).

Если же принципиально хочется ставить с помощью 'rpmi --chroot'
в пустой чрут произвольно сложный набор пакетов, то без "барьера"
возможны глюки, и оптимизировать зависимости нельзя.  Впрочем,
желание иметь "conforming chroot" чем можно раньше -- законно
в любом случае.

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

Re: [devel] Q: rpmi --chroot

[Alexey Gladkov]

Alexey Tourbin wrote:
> От инсталлятора (в случае оптимизации зависимостей) требуется лишь,
> чтобы он инсталлировал в два этапа: сначала установка rpm (или хотя
> бы coreutils + /bin/sh); а потом установка всего остального.  То есть
> инициализация минимального conforming чрута должна быть отделена

Есть репозиторий N как по нему вычислить состав conforming чрута ?
Или это жёстко запитый список пакетов ? ... если второе, то это как-то
некузяво.
Предлагается ставить пакеты для conforming чрута через rpm2cpio ?

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


-- 
Rgrds, legion

Re: [devel] Q: rpmi --chroot

[Alexey Tourbin]

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

On Fri, Feb 29, 2008 at 12:38:24AM +0300, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> > От инсталлятора (в случае оптимизации зависимостей) требуется лишь,
> > чтобы он инсталлировал в два этапа: сначала установка rpm (или хотя
> > бы coreutils + /bin/sh); а потом установка всего остального.  То есть
> > инициализация минимального conforming чрута должна быть отделена
> 
> Есть репозиторий N как по нему вычислить состав conforming чрута ?
> Или это жёстко запитый список пакетов ? ... если второе, то это как-то
> некузяво.
> Предлагается ставить пакеты для conforming чрута через rpm2cpio ?

Conforming chroot -- это в котором заведомо есть /bin/sh и некоторые
команды из coreutils (в частности, /bin/rm, далее cat mv cp mkdir ln).
Такой чрут является "conforming", потому что он соответствует
спецификации SUSv3 -- в нём заведомо работают некоторые самые
базовые UNIX программы.  Если мы исходим из того, что установка
любого пакета происходит в conforming chroot, тогда некоторые
самые частые зависимости можно оптимизировать (удалить).  Если же
исходить из того, что установка любого сколь угодно сложно пакета
происходит в потеницально пустой чрут, то базовые зависимости удалять
нельзя, потому что это может дать неправильный порядок установки
пакетов (и соответственно падение в скриптлетах).

Допустим, мы ставим в *пустой* чрут пакет openoffice.org.  Если в нём
оптимизирована (удалена) зависимость на /bin/sh, то rpm имеет право
ставить пакет openoffice.org ВПЕРЁД пакет sh (и даже вообще не ставить
пакет sh, если все зависимости на /bin/sh были удалены).  При этом
%post-скрипт в openoffice.org обломится, потому что пакет sh с /bin/sh
ещё не успел поставиться (или вовсе не собирался ставиться).

Поэтому в инсталляторе желательно разделить стадию инициализации
conforming чрута и последующую стадию установки дополнительных пакетов.
Состав conforming чрута вычисляется как замыкание зависимостей пакета
rpm.  Впрочем, ldv не уверен, что пакет rpm должен в *любой* системе
присутствовать (иными словами, в принципе возможны мини-чруты, с которым
"внешний" rpm общается со своей базой rpmdb только посредством 'rpm --root').
В таком случае содержимое минимального conforming чрута можно вычислять
как замыкание coreutils и sh.  Всё что меньше этого заведомо не
conforming.

Более развязано (то есть менее строго), для инициализации conforming
чрута специально существует пакет basesystem.  То есть с натяжкой можно
считать, что в любой рабочей среде установлен пакет basesystem.
Конечно, так лучше не считать, когда мы находимся в "шаре" с диаметром
в пределах basesystem.

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

Re: [devel] Q: rpmi --chroot

[Alexey Gladkov]

Alexey Tourbin wrote:
> Допустим, мы ставим в *пустой* чрут пакет openoffice.org.  Если в нём
> оптимизирована (удалена) зависимость на /bin/sh, то rpm имеет право
> ставить пакет openoffice.org ВПЕРЁД пакет sh (и даже вообще не ставить
> пакет sh, если все зависимости на /bin/sh были удалены).  При этом
> %post-скрипт в openoffice.org обломится, потому что пакет sh с /bin/sh
> ещё не успел поставиться (или вовсе не собирался ставиться).

У меня возник вопрос: если мы оптимизируем зависимости на базовые
команды, как будет работать aptbox? Сейчас aptbox используется для
создания замыканий по зависимостям. aptbox это пустая rpm база (пустой
чрут) ... если базовых зависимостей не будет у openoffice.org, то
замыкание придётся делать как замыкание вокруг openoffice.org +
замыкание вокруг состава conforming чрута.

> Поэтому в инсталляторе желательно разделить стадию инициализации
> conforming чрута и последующую стадию установки дополнительных пакетов.

Это сложно сделать пока не определён способ генерации списка пакетов
conforming чрута и предлагаемый способ установки этих пакетов в пустой
чрут. Как я отмечал, rpm2cpio не годится для этой задачи т.к. в этом
списке тоже есть зависимости и %post скрипты.

-- 
Rgrds, legion

Re: [devel] Q: rpmi --chroot

[Alexey Tourbin]

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

On Fri, Feb 29, 2008 at 02:06:18AM +0300, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> > Допустим, мы ставим в *пустой* чрут пакет openoffice.org.  Если в нём
> > оптимизирована (удалена) зависимость на /bin/sh, то rpm имеет право
> > ставить пакет openoffice.org ВПЕРЁД пакет sh (и даже вообще не ставить
> > пакет sh, если все зависимости на /bin/sh были удалены).  При этом
> > %post-скрипт в openoffice.org обломится, потому что пакет sh с /bin/sh
> > ещё не успел поставиться (или вовсе не собирался ставиться).
> 
> У меня возник вопрос: если мы оптимизируем зависимости на базовые
> команды, как будет работать aptbox? Сейчас aptbox используется для
> создания замыканий по зависимостям. aptbox это пустая rpm база (пустой
> чрут) ... если базовых зависимостей не будет у openoffice.org, то
> замыкание придётся делать как замыкание вокруг openoffice.org +
> замыкание вокруг состава conforming чрута.

aptbox это не пустая база, содержимое aptbox/var/lib/rpm обновляется
синхронно с chroot/var/lib/rpm.

$ hsh --initroot --pkg-build-list=,
$ rpm -qa --root ~tmp/build/aptbox     
filesystem-2.3.3-alt1
glibc-preinstall-2.5.1-alt3
getopt-1.1.4-alt1
zlib-1.2.3-alt4
info-install-4.11-alt2
terminfo-5.6-alt4
coreutils-5.97-alt6
libbeecrypt-2.2.0-alt6
libelf-0.131-alt1
librpm-4.0.4-alt87
rpm-4.0.4-alt87
setup-2.2.11-alt1
alt-gpgkeys-0.4.8-alt1
glibc-core-2.5.1-alt3
bzlib-1.0.4-alt3
libzio-0.4-alt1
sh-3.1.17-alt4
libtinfo-5.6-alt4
fakeroot-1.9-alt1
libdb4.4-4.4.20-alt2
libpopt-1.7-alt17
librpmbuild-4.0.4-alt87
$ 

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

Re: [devel] Q: rpmi --chroot

[Alexey Gladkov]

Alexey Tourbin wrote:
> aptbox это не пустая база, содержимое aptbox/var/lib/rpm обновляется
> синхронно с chroot/var/lib/rpm.

Я имел ввиду:

mkaptbox /tmp/box

и уже получившийся aptbox используется, например, в mkimage или
скрипты, которые получают список unmets тоже создают пустой aptbox. Я
имел ввиду ситуацию, когда aptbox используется отдельно от hasher.

> $ hsh --initroot --pkg-build-list=,

Ну всё правильно в чруте будут пакеты из ещё одного предопределённого
списка: --pkg-init-list=LIST.

$ grep pkg_init_list= /usr/bin/hsh-*
/usr/bin/hsh-sh-functions:pkg_init_list='setup filesystem rpm
fakeroot>=0:0.7.3'

и кстати, замыкание этого изначального списка делается как раз на
таком пустом aptbox'е, где база rpm ещё пуста.

> $ rpm -qa --root ~tmp/build/aptbox

изначально, aptbox именно пуст:

$ mkaptbox /tmp/box
$ rpm -qa --root /tmp/box/aptbox |wc -l
0

-- 
Rgrds, legion

Re: [devel] rpm 4.0.4-alt87

[Kirill A. Shutemov]

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

On [Thu, 28.02.2008 21:34], Dmitry V. Levin wrote:
> On Thu, Feb 28, 2008 at 09:00:53PM +0300, Alexey Tourbin wrote:
> > В любом случае, корректная процедура инициализации пустой системы
> > или чрута должна начинаться с установки самого rpm.  Значит, порядок
> > пакетов в худжем случае придётся проконтролировать только для конечного
> > числа пакетов, от которых зависит rpm.
> 
> Я не уверен, что rpm как пакет всегда должен присутствовать в любой системе.

Из соображений экономии дискового пространства rpm'а может не быть на
embedded system.

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

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Fri, Feb 29, 2008 at 12:34:54PM +0200, Kirill A. Shutemov wrote:
> On [Thu, 28.02.2008 21:34], Dmitry V. Levin wrote:
> > Я не уверен, что rpm как пакет всегда должен присутствовать в любой системе.
> Из соображений экономии дискового пространства rpm'а может не быть на
> embedded system.

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

$ rpm -q --qf '%{SIZE}\n' librpm rpm coreutils
512273
582735
7764576
$

В принципе, когда речь идет об оптимизации или экономии, всегда надо
измерять выгоду (gain).  "Measure before optimizing", "programmers are
notoriously bad at predicting ..." etc.  Братие, дьявольские искушения
подстерегают нас на каждом шагу!!

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

Re: [devel] rpm 4.0.4-alt87

[Mikhail Gusarov]

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

Twas brillig at 12:45:37 01.03.2008 UTC+03 when Alexey Tourbin did gyre and gimble:

 AT> $ rpm -q --qf '%{SIZE}\n' librpm rpm coreutils
 AT> 512273
 AT> 582735
 AT> 7764576
 AT> $

В embedded coreutils обычно заменяют busybox'ом, а вот rpm заменять
нечем (тот rpm, что внутри busybox'а, сильно убог).

-- 

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

Re: [devel] rpm 4.0.4-alt87

[Alexander Bokovoy]

2008/3/1 Mikhail Gusarov <dottedmag@dottedmag.net>:
> Twas brillig at 12:45:37 01.03.2008 UTC+03 when Alexey Tourbin did gyre and gimble:
>
>   AT> $ rpm -q --qf '%{SIZE}\n' librpm rpm coreutils
>   AT> 512273
>   AT> 582735
>   AT> 7764576
>   AT> $
>
>  В embedded coreutils обычно заменяют busybox'ом, а вот rpm заменять
>  нечем (тот rpm, что внутри busybox'а, сильно убог).
В образе, который заливается в железку, обычно нет места на базы rpm.
Код не так важен, когда нет баз. В типичной системе с полутора-двумя
тысячами пакетов размер базы будет около 50Мб. В embedded количество
пакетов существенно меньше, но базы все равно займут где-то два-три
раза больше, чем содержимое пакета coreutils, приведенное выше.

Это не говоря уже о том, что в embedded системе будут отсутствовать
/usr/share/doc/* и прочие штуки, которые формально включены в пакеты.
-- 
/ Alexander Bokovoy

Re: [devel] rpm 4.0.4-alt87

[Mikhail Gusarov]

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

Twas brillig at 00:02:56 02.03.2008 UTC+03 when Alexander Bokovoy did gyre and gimble:

 AB> В embedded количество
 AB> пакетов существенно меньше, но базы все равно займут где-то два-три
 AB> раза больше, чем содержимое пакета coreutils, приведенное выше.

Да, тут без другого бэкенда не обойтись :-/

 AB> Это не говоря уже о том, что в embedded системе будут отсутствовать
 AB> /usr/share/doc/* и прочие штуки, которые формально включены в
 AB> пакеты.

С этим можно справляться приблизительно так, как справляются с prelink.

-- 

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Sun, Mar 02, 2008 at 12:02:56AM +0300, Alexander Bokovoy wrote:
> 2008/3/1 Mikhail Gusarov <dottedmag@dottedmag.net>:
> > Twas brillig at 12:45:37 01.03.2008 UTC+03 when Alexey Tourbin did gyre and gimble:
> >
> >   AT> $ rpm -q --qf '%{SIZE}\n' librpm rpm coreutils
> >   AT> 512273
> >   AT> 582735
> >   AT> 7764576
> >   AT> $
> >
> >  В embedded coreutils обычно заменяют busybox'ом, а вот rpm заменять
> >  нечем (тот rpm, что внутри busybox'а, сильно убог).
> В образе, который заливается в железку, обычно нет места на базы rpm.
> Код не так важен, когда нет баз. В типичной системе с полутора-двумя
> тысячами пакетов размер базы будет около 50Мб. В embedded количество
> пакетов существенно меньше, но базы все равно займут где-то два-три
> раза больше, чем содержимое пакета coreutils, приведенное выше.

Какие-то легенды ходят про размер rpm базы.

$ hsh --init
$ du -hs build/cache/chroot/rpmdb.tar build/cache/chroot/chroot.cpio
4.1M    build/cache/chroot/rpmdb.tar
152M    build/cache/chroot/chroot.cpio
$

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Gladkov]

Alexey Tourbin wrote:
> Какие-то легенды ходят про размер rpm базы.
> 
> $ hsh --init
> $ du -hs build/cache/chroot/rpmdb.tar build/cache/chroot/chroot.cpio
> 4.1M    build/cache/chroot/rpmdb.tar

Ты не поверишь, но в некоторых случаях эти 4М могут иметь значение.

-- 
Rgrds, legion

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Sun, Mar 02, 2008 at 12:45:10AM +0300, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> > Какие-то легенды ходят про размер rpm базы.
> > 
> > $ hsh --init
> > $ du -hs build/cache/chroot/rpmdb.tar build/cache/chroot/chroot.cpio
> > 4.1M    build/cache/chroot/rpmdb.tar
> 
> Ты не поверишь, но в некоторых случаях эти 4М могут иметь значение.

Это 4.1M от 152M-4.1M чрута, в котром стоит 135 пакетов.
Если уменьшить содержимое чрута (не устанавливать лишних пакетов),
то размер rpmdb уменьшится примерно пропорционально.

$ hsh --initroot --pkg-build-list=basesystem
$ du -hs build/cache/chroot/rpmdb.tar build/cache/chroot/chroot.cpio
1.9M    build/cache/chroot/rpmdb.tar
37M     build/cache/chroot/chroot.cpio
$ hsh-run -- rpm -qa |wc -l                 
90
$

В общем, система без rpmdb и система без coreutils -- два сапога пара.
Но тогда при чём тут зависимости...

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Gladkov]

Alexey Tourbin wrote:
> В общем, система без rpmdb и система без coreutils -- два сапога пара.
> Но тогда при чём тут зависимости...

При том что заготовку для такой системы нужно как-то создать. Можно
конечно сделать --initroot, а потом руками удалять из чрута всё лишнее.

-- 
Rgrds, legion

Re: [devel] rpm 4.0.4-alt87

[Led]

Sunday, 02 March 2008 00:09:25 Alexey Gladkov написав:
> Alexey Tourbin wrote:
> > В общем, система без rpmdb и система без coreutils -- два сапога пара.
> > Но тогда при чём тут зависимости...
>
> При том что заготовку для такой системы нужно как-то создать. Можно
> конечно сделать --initroot, а потом руками удалять из чрута всё лишнее.

Отказаться от обновлений ради экономии 2% занимаемого места на носителе?

-- 
Led

Re: [devel] rpm 4.0.4-alt87

[Pavlov Konstantin]

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

On Sun, Mar 02, 2008 at 12:25:42AM +0200, Led wrote:
> Sunday, 02 March 2008 00:09:25 Alexey Gladkov написав:
> > Alexey Tourbin wrote:
> > > В общем, система без rpmdb и система без coreutils -- два сапога пара.
> > > Но тогда при чём тут зависимости...
> >
> > При том что заготовку для такой системы нужно как-то создать. Можно
> > конечно сделать --initroot, а потом руками удалять из чрута всё лишнее.
> 
> Отказаться от обновлений ради экономии 2% занимаемого места на носителе?

В случае embedded-систем -- однозначное да.

-- 
> А как вы называете систему, которая делает не то, что вам хочется или то,
> но не так? :))
Системы, которые делают не то, что мне хочется, бэкапятся на
сервер патологоанатомического отделения.
На предмет выяснения -- не являются ли они летальными мутантами.
		-- jaa in community@

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

Re: [devel] rpm 4.0.4-alt87

[Alexander Bokovoy]

2008/3/2 Led <ledest@gmail.com>:
> Sunday, 02 March 2008 00:09:25 Alexey Gladkov написав:
>
> > Alexey Tourbin wrote:
>  > > В общем, система без rpmdb и система без coreutils -- два сапога пара.
>  > > Но тогда при чём тут зависимости...
>  >
>  > При том что заготовку для такой системы нужно как-то создать. Можно
>  > конечно сделать --initroot, а потом руками удалять из чрута всё лишнее.
>
>  Отказаться от обновлений ради экономии 2% занимаемого места на носителе?
Да. К тому же, обновления на embedded делаются немного не руками
встроенного менеджера пакетов. То есть, это тоже делается и качество
таких "обновлений" мы можем наблюдать на работе ipkg и прочих
"упрощенных" менеджеров.

Как правило, собирается firmware целиком, для этого генерируется чрут
с нужным содержимым и потом из него все ненужное уничтожается перед
сборкой образа.
-- 
/ Alexander Bokovoy

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Sun, Mar 02, 2008 at 10:30:50AM +0300, Alexander Bokovoy wrote:
> >  Отказаться от обновлений ради экономии 2% занимаемого места на носителе?
> Да. К тому же, обновления на embedded делаются немного не руками
> встроенного менеджера пакетов. То есть, это тоже делается и качество
> таких "обновлений" мы можем наблюдать на работе ipkg и прочих
> "упрощенных" менеджеров.
> 
> Как правило, собирается firmware целиком, для этого генерируется чрут
> с нужным содержимым и потом из него все ненужное уничтожается перед
> сборкой образа.

Это очень примитивно; это получается типа прошивки программируемого
микрокалькулятора (aka BIOS) с полным замещением конфигов, обязательной
перезгарузкой, никакого намёка на возможность транзакции и т.п.

То есть это алгоритм обновления типа
cat BIOS |(cd /; sleep 1; rm -rf /; tar xf -; reboot)

Я бы такой дрянью не занялся даже за большие деньги.
Если только за очень большие. :)

К тому же научно-технический прогресс несколько шагнул вперёд,
и стоимость фшелки в гигабайт-два на уровне поставщика -- это
несколько долларов.  Это если только такая допотопная емедовщина
которой семь лет в обед.

Я на самом деле не знаю, сколько люди рассчитвают на этом сэкономить
и сколько взамен заработать.  Счёт изменяется не в пользу.

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Sun, Mar 02, 2008 at 10:54:39AM +0300, Alexey Tourbin wrote:
> К тому же научно-технический прогресс несколько шагнул вперёд,
> и стоимость фшелки в гигабайт-два

флешки

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Sun, Mar 02, 2008 at 10:54:39AM +0300, Alexey Tourbin wrote:
> То есть это алгоритм обновления типа
> cat BIOS |(cd /; sleep 1; rm -rf /; tar xf -; reboot)

Здесь как раз потребуется какой-нибудь busybox, чтобы
после rm сработал builtin tar и builtin reboot.

Всё это нехорошо. :)

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

Re: [devel] rpm 4.0.4-alt87

[Alexander Bokovoy]

2008/3/2 Alexey Tourbin <at@altlinux.ru>:
>  > Как правило, собирается firmware целиком, для этого генерируется чрут
>  > с нужным содержимым и потом из него все ненужное уничтожается перед
>  > сборкой образа.
>
>  Это очень примитивно; это получается типа прошивки программируемого
>  микрокалькулятора (aka BIOS) с полным замещением конфигов, обязательной
>  перезгарузкой, никакого намёка на возможность транзакции и т.п.
Там одна транзакция: залилось-не залилось. Загрузчик обычно живет
совсем независимо и позволяет перепрошивать систему совсем без
работающей firmware. Сохранение и восстановление конфигурации обычно
делается отдельным механизмом -- вначале собирается состояние и
записывается в какую-нибудь независимую память (внешний флеш или еще
что, или внутренний раздел, который не перезаписывается), а потом
после обновления прошивки при первом старте обнаруживается и
восстанавливается.

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

>  То есть это алгоритм обновления типа
>  cat BIOS |(cd /; sleep 1; rm -rf /; tar xf -; reboot)
>
>  Я бы такой дрянью не занялся даже за большие деньги.
>  Если только за очень большие. :)
Как правило, так и есть -- деньги, которые берут с потребителей своих
услуг производители встраиваемых платформ, очень большие. Мне называли
десяток-два тысяч долларов в год за лицензию на одно рабочее место
разработчика за продукт MontaVista.

>  К тому же научно-технический прогресс несколько шагнул вперёд,
>  и стоимость фшелки в гигабайт-два на уровне поставщика -- это
>  несколько долларов.  Это если только такая допотопная емедовщина
>  которой семь лет в обед.
Что касается пары долларов на гигабайт флеша, то это не совсем верно.
Особенно в случаях массового производства. Дело в том, что флеш флешу
рознь и стоимость NAND, используемого внутри устройств, обычно выше
такого же, но используемого во внешних системах, во многом из-за того,
что он используется в серийном режиме вместо параллельного для
экономии занимаемого пространства (многие такие чипсеты ограничены
количеством ножек, а серийные устройства требуют меньше ножек, чем
параллельные). Поскольку практически все дешевые "встраиваемые"
устройства представляют собой системы-на-чипе, там это становится
критическим моментом.

>  Я на самом деле не знаю, сколько люди рассчитвают на этом сэкономить
>  и сколько взамен заработать.  Счёт изменяется не в пользу.
Экономят центы, получают миллионы. Закон больших чисел. Вообще, в этой
области правят "быстрее-выше-сильнее": быстрее вывести продукт на
рынок, сделать его дешевле из имеющихся уже компонентов, быть сильнее
конкурента в подписании контрактов на сбыт. Типичный срок реакции
китайских компаний -- 4-7 месяцев.

-- 
/ Alexander Bokovoy

Re: [devel] rpm 4.0.4-alt87

[Led]

Sunday, 02 March 2008 09:54:39 Alexey Tourbin написав:
> On Sun, Mar 02, 2008 at 10:30:50AM +0300, Alexander Bokovoy wrote:
> > >  Отказаться от обновлений ради экономии 2% занимаемого места на
> > > носителе?
> >
> > Да. К тому же, обновления на embedded делаются немного не руками
> > встроенного менеджера пакетов. То есть, это тоже делается и качество
> > таких "обновлений" мы можем наблюдать на работе ipkg и прочих
> > "упрощенных" менеджеров.
> >
> > Как правило, собирается firmware целиком, для этого генерируется чрут
> > с нужным содержимым и потом из него все ненужное уничтожается перед
> > сборкой образа.
>
> Это очень примитивно; это получается типа прошивки программируемого
> микрокалькулятора (aka BIOS) с полным замещением конфигов, обязательной
> перезгарузкой, никакого намёка на возможность транзакции и т.п.
>
> То есть это алгоритм обновления типа
> cat BIOS |(cd /; sleep 1; rm -rf /; tar xf -; reboot)
>
> Я бы такой дрянью не занялся даже за большие деньги.
> Если только за очень большие. :)
>
> К тому же научно-технический прогресс несколько шагнул вперёд,
> и стоимость фшелки в гигабайт-два на уровне поставщика -- это
> несколько долларов.  Это если только такая допотопная емедовщина
> которой семь лет в обед.
>
> Я на самом деле не знаю, сколько люди рассчитвают на этом сэкономить
> и сколько взамен заработать.  Счёт изменяется не в пользу.

ИМХО более другими способами можно "сэкономить" значительно больше, чем 2%, 
даже не удаляя базы rpm.

-- 
Led

[devel] embedded package (non-)management

[Michael Shigorin]

On Sun, Mar 02, 2008 at 10:54:39AM +0300, Alexey Tourbin wrote:
> > Как правило, собирается firmware целиком, для этого
> > генерируется чрут с нужным содержимым и потом из него все
> > ненужное уничтожается перед сборкой образа.
> Это очень примитивно; это получается типа прошивки
> программируемого микрокалькулятора (aka BIOS) с полным
> замещением конфигов, обязательной перезгарузкой, никакого
> намёка на возможность транзакции и т.п.

Зато у такой прошивки существует очень ценное свойство:
детерминированность.

> Я бы такой дрянью не занялся даже за большие деньги.
> Если только за очень большие. :)

Ну, я чуточку занимался. :)

> Я на самом деле не знаю, сколько люди рассчитвают на этом
> сэкономить и сколько взамен заработать.  Счёт изменяется не в
> пользу.

Собственно, речь была о том, что такие случаи есть и обычны.
Дело даже если и не в том, что места мало, то в том, что rpm
там просто не нужен.

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

Re: [devel] embedded package (non-)management

[Alexey Shabalin]

03.03.08, Michael Shigorin<mike@osdn.org.ua> написал(а):
> On Sun, Mar 02, 2008 at 10:54:39AM +0300, Alexey Tourbin wrote:
>  > > Как правило, собирается firmware целиком, для этого
>  > > генерируется чрут с нужным содержимым и потом из него все
>  > > ненужное уничтожается перед сборкой образа.
>  > Это очень примитивно; это получается типа прошивки
>  > программируемого микрокалькулятора (aka BIOS) с полным
>  > замещением конфигов, обязательной перезгарузкой, никакого
>  > намёка на возможность транзакции и т.п.
>
>  Зато у такой прошивки существует очень ценное свойство:
>  детерминированность.
>
>  > Я бы такой дрянью не занялся даже за большие деньги.
>  > Если только за очень большие. :)
>
>  Ну, я чуточку занимался. :)
Я занимался только "эксплуатированием" систем со встроенным линуксом.

>  > Я на самом деле не знаю, сколько люди рассчитвают на этом
>  > сэкономить и сколько взамен заработать.  Счёт изменяется не в
>  > пользу.
>
>  Собственно, речь была о том, что такие случаи есть и обычны.
>  Дело даже если и не в том, что места мало, то в том, что rpm
>  там просто не нужен.
Вот здесь можно соглашатся или нет. И производители каждый для себя
решает сам. Приводить пример где не используется rpm не буду, а вот
где он есть - например в FC -коммутаторах brocade (оемятся так же
ibm'ом). "Прошивки" обновляются yum'ом(там есть команда типа
firmwareupdate которая реально дёргает yum). Даже для железки иногда
не плохо запустить rpm -V. Тем более возможность %post %pre тоже
хороша даже для железок.

-- 
Alexey Shabalin

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Wed, Feb 27, 2008 at 07:46:04PM +0300, Dmitry V. Levin wrote:
> On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> [...]
> > Чтобы не появилось слишком много bulk зависимостей, я реализовал
> > оптимизацию, которая удаляет следующие зависимости (как "команды"
> > в шелл-скриптах, так и соответствующие им /bin/ пути):
> > 	sh cat rm mv cp mkdir ln
> > 
> > (список можно будет немного увеличить, если кто-нибудь захочет
> > составить более точную статистику, чем у меня получилось с ходу).
> > 
> > Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> > не окончательно поломанной среде эти зависимости должны быть
> > заведомо удовлетворены.
> 
> Боюсь что эту оптимизацию придётся убрать,
> иначе порядок установки пакетов в пустую систему может испортиться.

Тогда уж надо было откатывать и
5224b77cbdd2200ab040124101a132e92531f134
build/parseScript.c: opitimize out RPMSENSE_INTERP dependencies on /bin/sh

Но вообще я считаю, что зависимости, которые есть, грубо говоря,
у каждого второго пакета, можно считать не столько собственными
зависимостями пакета, сколько атрубитами системы, для установки
в которую эти пакеты предназначены.  Например, зависимость на /bin/sh
из-за %post-скриптов означает, что сам rpm умеет запускать дефолтный
интерпретатор для исполнения %post-скриптов.  Значит, зависимость на
/bin/sh проще обеспечить на "системном" уровне, чем вставлять
её в каждый второй пакет.

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

Re: [devel] rpm 4.0.4-alt87

[Dmitry V. Levin]

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

On Thu, Feb 28, 2008 at 09:40:50PM +0300, Alexey Tourbin wrote:
> On Wed, Feb 27, 2008 at 07:46:04PM +0300, Dmitry V. Levin wrote:
> > On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> > [...]
> > > Чтобы не появилось слишком много bulk зависимостей, я реализовал
> > > оптимизацию, которая удаляет следующие зависимости (как "команды"
> > > в шелл-скриптах, так и соответствующие им /bin/ пути):
> > > 	sh cat rm mv cp mkdir ln
> > > 
> > > (список можно будет немного увеличить, если кто-нибудь захочет
> > > составить более точную статистику, чем у меня получилось с ходу).
> > > 
> > > Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> > > не окончательно поломанной среде эти зависимости должны быть
> > > заведомо удовлетворены.
> > 
> > Боюсь что эту оптимизацию придётся убрать,
> > иначе порядок установки пакетов в пустую систему может испортиться.
> 
> Тогда уж надо было откатывать и
> 5224b77cbdd2200ab040124101a132e92531f134
> build/parseScript.c: opitimize out RPMSENSE_INTERP dependencies on /bin/sh

Пакет, у которого есть %post-скрипт на /bin/sh, твоими изменениями теперь
получает зависимость на /bin/sh из-за #!/bin/sh, поэтому RPMSENSE_INTERP
на /bin/sh тут уже не требуется.
На самом деле RPMSENSE_INTERP тут не требуется не только для /bin/sh, но и
для всего остального.  Эта зависимость теперь вообще не нужна.

> Но вообще я считаю, что зависимости, которые есть, грубо говоря,
> у каждого второго пакета, можно считать не столько собственными
> зависимостями пакета, сколько атрубитами системы, для установки
> в которую эти пакеты предназначены.  Например, зависимость на /bin/sh
> из-за %post-скриптов означает, что сам rpm умеет запускать дефолтный
> интерпретатор для исполнения %post-скриптов.  Значит, зависимость на
> /bin/sh проще обеспечить на "системном" уровне, чем вставлять
> её в каждый второй пакет.

Осталось только обеспечить, чтобы /bin/sh всегда был.
Как это сделать без зависимостей?  Написать крупными буквами?


-- 
ldv

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

Re: [devel] rpm 4.0.4-alt87

[Alexey Tourbin]

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

On Thu, Feb 28, 2008 at 09:44:17PM +0300, Dmitry V. Levin wrote:
> > 5224b77cbdd2200ab040124101a132e92531f134
> > build/parseScript.c: opitimize out RPMSENSE_INTERP dependencies on /bin/sh
> 
> Пакет, у которого есть %post-скрипт на /bin/sh, твоими изменениями теперь
> получает зависимость на /bin/sh из-за #!/bin/sh, поэтому RPMSENSE_INTERP
> на /bin/sh тут уже не требуется.
> На самом деле RPMSENSE_INTERP тут не требуется не только для /bin/sh, но и
> для всего остального.  Эта зависимость теперь вообще не нужна.

Точно.  Я об этом совсем не подумал.  Если только не отключать
%__find_scriptlet_requires, то будет две одинаковые зависимости
на интерпретатор с разными флагами (флаг из-за #!/interp будет
отличаться на RPMSENSE_FIND_REQUIRES).  Наверное, одна из этих
зависимостей будет оптимизирована в build/reqprov.c

> > Но вообще я считаю, что зависимости, которые есть, грубо говоря,
> > у каждого второго пакета, можно считать не столько собственными
> > зависимостями пакета, сколько атрубитами системы, для установки
> > в которую эти пакеты предназначены.  Например, зависимость на /bin/sh
> > из-за %post-скриптов означает, что сам rpm умеет запускать дефолтный
> > интерпретатор для исполнения %post-скриптов.  Значит, зависимость на
> > /bin/sh проще обеспечить на "системном" уровне, чем вставлять
> > её в каждый второй пакет.
> 
> Осталось только обеспечить, чтобы /bin/sh всегда был.
> Как это сделать без зависимостей?  Написать крупными буквами?

Можно в rpmi добавить хак типа [ -x /bin/sh ].
Но это уже как-то совсем...

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