[devel] rpm-build 4.0.4-alt78+ RC

[devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

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

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

Статус alt78 повышается с беты до RC.
"Релиз должен быть сегодня".

Остается принять решение, нужно ли отвязывать rpm-build-tcl от базовой
сборочной среды или нет.  Я очень подробно писал, в чем тут суть дела.
Думаю, что смогу принять это решение самостоятельно.

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
> Я закончил разгребать изменения зависимостей у пакетов.  В процессе
> этого было внесено достаточно много исправлений как в rpm-build, так
> и ещё в несколько пакетов.  Все выявленные проблемы в основном решены.

Выявленные в rpm-build проблемы в основном решены.
А вот проблемы, выявленные в пакетах, ещё решены далеко не все.
Не знаю, поможет ли тут авторазвешиватель багов.

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

И это особенно радует.

> Статус alt78 повышается с беты до RC.
> "Релиз должен быть сегодня".

Пора вычитывать новые скрипты?

> Если у кого-то остались вопросы, то думаю, что весь день 24 сентября
> их будет очень уместно задавать.

Кто будет мерджить heads/altlinux-4.0? ;)


-- 
ldv

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Mon, Sep 24, 2007 at 02:10:48AM +0400, Dmitry V. Levin wrote:
> On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
> > Я закончил разгребать изменения зависимостей у пакетов.  В процессе
> > этого было внесено достаточно много исправлений как в rpm-build, так
> > и ещё в несколько пакетов.  Все выявленные проблемы в основном решены.
> 
> Выявленные в rpm-build проблемы в основном решены.
> А вот проблемы, выявленные в пакетах, ещё решены далеко не все.
> Не знаю, поможет ли тут авторазвешиватель багов.

В большинстве случаев выявленные баги приводят к появлению анметов.
Здесь достаточно поднатужиться incominger'у и просто не пускать пакеты
с "характерными" анметами.

Кроме того, я делал CC maintainer'ам, и с некоторыми из них вступал в
переписку.  Я готов и дальше это делать, хотя думаю, что лучше писать
в devel@.

> > Статус alt78 повышается с беты до RC.
> > "Релиз должен быть сегодня".
> Пора вычитывать новые скрипты?

Ну, да.  Только не надо придираться, типа как лучше вычистить башизмы $'\t'
я не знаю.  Дюже они удобны.  Сейчас это не критично.  Тж. echo vs. printf.

> > Если у кого-то остались вопросы, то думаю, что весь день 24 сентября
> > их будет очень уместно задавать.
> Кто будет мерджить heads/altlinux-4.0? ;)

Наверное, я.

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

[devel] исполняемые/не исполняемые скрипты

[Alexey Tourbin]

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

On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
> Я закончил разгребать изменения зависимостей у пакетов.  В процессе
> этого было внесено достаточно много исправлений как в rpm-build, так
> и ещё в несколько пакетов.  Все выявленные проблемы в основном решены.

Включение поиска зависимостей во всех шелл-скриптах, а не только
исполняемых, на самом деле выявило вот какую проблему.  Многие
matinainer'ы, кажется, вполне невинно не понимали, что в неисполняемых
скриптах поиск зависимостей был отключен.  Из-за этого игнорировались
зависимости на /etc/init.d и т.п.

Я вот думаю, в какой мере стоит сохранить проверку на исполняемость
скриптов в остальных случаях (напр. для перл-скритпов, если они не
кончаются на *.p[lmh]).

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

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

Re: [devel] исполняемые/неисполняемые скрипты

[Michael Shigorin]

On Mon, Sep 24, 2007 at 03:08:19AM +0400, Alexey Tourbin wrote:
> С одной стороны, как бы некрасиво "пережимать" (то есть делать
> то, чего не просят).  С другой стороны, исходя из того, что
> пакет собирает "средный maintainer", жать надо чем можно
> сильнее.

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

Может, сделать регулерятор поиска по _неисполняемым_
и в случае если он оказался выключенным (on by default)
-- нудеть, что мол поправили бы уже свои скрипты или перенесли
контриб в документацию или отдельным пакетом?

(а по .*-docs? и -contrib было бы совсем хорошо off by default)

PS: "неисполняемые" в данном контексте пишутся в месте. :]

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

Re: [devel] исполняемые/неисполняемые скрипты

[Alexey Tourbin]

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

On Mon, Sep 24, 2007 at 11:14:18AM +0300, Michael Shigorin wrote:
> On Mon, Sep 24, 2007 at 03:08:19AM +0400, Alexey Tourbin wrote:
> > С одной стороны, как бы некрасиво "пережимать" (то есть делать
> > то, чего не просят).  С другой стороны, исходя из того, что
> > пакет собирает "средный maintainer", жать надо чем можно
> > сильнее.
> 
> Хороший случай для warning на длительный период времени
> (полгода-год), вот только не вижу для этого возможности
> в случае искалки зависимостей.

Как раз и сделал warning.  Есть скрипты shebang.req.files и shebang.req,
который обрабатывают скрипты с #! и ставят зависимость на интерпретатор.
Если скрипт не исполняемый, shebang.req.files будет выдавать warning
"executable not executable".

commit 8ee696768c491759e7815fc42c3347618115b342
Author: Alexey Tourbin <at@altlinux>
Date:   Mon Sep 24 02:57:42 2007 +0400

    shebang.req.files: added "executable not executable" warning

diff --git a/scripts/shebang.req.files b/scripts/shebang.req.files
index e3c475a..2f4838e 100755
--- a/scripts/shebang.req.files
+++ b/scripts/shebang.req.files
@@ -1,5 +1,8 @@
 #!/bin/sh -efu
 while IFS=$'\t' read -r f t; do
-	[ -z "${t##*script text executable*}" ] &&
-		[ -x "$f" ] && echo "$f" ||:
+	case "$t" in
+		*"script text executable"*)
+			[ -x "$f" ] && echo "$f" ||
+			echo "${0##*/}: executable script $f not executable" >&2 ;;
+	esac
 done


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

Re: [devel] исполняемые/неисполняемые скрипты

[Michael Shigorin]

On Mon, Sep 24, 2007 at 01:03:01PM +0400, Alexey Tourbin wrote:
> > > С одной стороны, как бы некрасиво "пережимать"
> > Хороший случай для warning на длительный период времени
> Как раз и сделал warning.

Ну так и замечательно!

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
> Если у кого-то остались вопросы, то думаю, что весь день 24 сентября
> их будет очень уместно задавать.

Вопросов в этот бизнес-день не поступило.  Предварительное тестирование
закончено.  В mash:~at/SRPMS/ выложена пачка подписанных RC-пакетов:

rpm-4.0.4-alt78.src.rpm
rpm-build-mono-1.1-alt1.src.rpm
rpm-build-python-0.31-alt1.src.rpm
rpm-build-tcl-0.2.1-alt1.src.rpm
tcl-8.4.15-alt2.src.rpm
alternatives-0.3.1-alt1.src.rpm

Надеюсь, что протестов от maintainer'ов пакетов, по которым у меня нет
прав по ACL, не последует.  Все изменения узкие и направлены только на
поддержку нового rpm-build (они опубликованы в моих git-репозитариях).

(Впрочем, неплохо бы добавить меня в ACL ко всем rpm-build-* пакетам.)

Я также дополнил changelog к rpm-build.

* Mon Sep 24 2007 Alexey Tourbin <at@altlinux> 4.0.4-alt78
- implemented modular subsystem for find-requires and find-provides;
  there's no separate doc yet, except for my protva2007-ru-short.pdf;
  see also git changelog, especially commit 9717c128
- improved /usr/lib/rpm/find-package algorithms
- shell.req: non-executable scripts are now processed as well as executable
  ones; also, more shebang variants are recognized, e.g. "#!/usr/bin/env bash"
- symlinks.req: new dependency generator for external symbolic links
- pkgconfig.req: pkg-config(1) errors no longer silently ignored
- pkgconfiglib.req: new dependency analyzer for "Libs" field in *.pc files;
  maps e.g. "-lfoo" -> /usr/lib/libfoo.so -> libfoo-devel

Здесь есть два изменения по сравнению с предыдущим alt78 beta:

1) pkgconfiglib.req: это упомянуто в changelog'е.  Зависимости *-devel
пакетов (c *.pc файлом) будут жестко цементироваться по (сборочной)
хост-среде (т.е. по хешеровскому чруту).  Пока это скорее хорошо,
чем плохо: зависимости между *-devel пакетами не должны быть слишком
"виртуальными".  А именно, например, -ldb-4 должно давать зависимость
на libdb4.4-devel, а не libdb4-devel.  В дальнейшем цементирование можно
будет немного ослабить.

2) Я оторвал rpm-build-tcl от rpm-build.  Для этого пришлось собрать
tcl-*-alt2, где у tcl-devel добавлена зависимость на rpm-build-tcl.
Это не отражено в changelog'е, и я рассчитваю, что это изменение не
будет иметь серьезных последствий.  В противном случае зависимость
на rpm-build-tcl можно будет вернуть.

Следующее адресовано, по-видимому, Дмитрию Левину.

Эту пачку пакетов лучше собрать в два прохода: сначала --without-stuff,
а потом ещё раз (повторно) --with-stuff.  Это некий bootstrap, который
гарантирует минимальную консистентность.

Далее есть несколько вариантов, как всё это провести в сизиф.

1) Просто переложить, что получилось.

2) Положить в current/Sisyphus и запустить одну тестовую пересборку.

3) Запустить две почти синхронные пересборки со старым и новым rpm-build,
как в прошлый раз.

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Tue, Sep 25, 2007 at 12:31:14AM +0400, Alexey Tourbin wrote:
> On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
> > Если у кого-то остались вопросы, то думаю, что весь день 24 сентября
> > их будет очень уместно задавать.
> 
> Вопросов в этот бизнес-день не поступило.  Предварительное тестирование
> закончено.  В mash:~at/SRPMS/ выложена пачка подписанных RC-пакетов:
> 
> rpm-4.0.4-alt78.src.rpm
> rpm-build-mono-1.1-alt1.src.rpm
> rpm-build-python-0.31-alt1.src.rpm
> rpm-build-tcl-0.2.1-alt1.src.rpm
> tcl-8.4.15-alt2.src.rpm
> alternatives-0.3.1-alt1.src.rpm
> 
> Надеюсь, что протестов от maintainer'ов пакетов, по которым у меня нет
> прав по ACL, не последует.  Все изменения узкие и направлены только на
> поддержку нового rpm-build (они опубликованы в моих git-репозитариях).

Эта пачка пакетов пойдёт в Сизиф нестандартным путём, так что прошу
успеть выступить с протестами до того как пакеты попадут в Сизиф.


-- 
ldv

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

[devel] rpm-build-mono

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 01:04:55AM +0400, Dmitry V. Levin wrote:
> > Вопросов в этот бизнес-день не поступило.  Предварительное тестирование
> > закончено.  В mash:~at/SRPMS/ выложена пачка подписанных RC-пакетов:
> > 
> > rpm-4.0.4-alt78.src.rpm
> > rpm-build-mono-1.1-alt1.src.rpm
> > rpm-build-python-0.31-alt1.src.rpm
> > rpm-build-tcl-0.2.1-alt1.src.rpm
> > tcl-8.4.15-alt2.src.rpm
> > alternatives-0.3.1-alt1.src.rpm
> > 
> > Надеюсь, что протестов от maintainer'ов пакетов, по которым у меня нет
> > прав по ACL, не последует.  Все изменения узкие и направлены только на
> > поддержку нового rpm-build (они опубликованы в моих git-репозитариях).
> 
> Эта пачка пакетов пойдёт в Сизиф нестандартным путём, так что прошу
> успеть выступить с протестами до того как пакеты попадут в Сизиф.

rpm-build-mono я очень сильно переделал.  Но этот пакет походу
бесхозный.  Так что моя совесть чиста -- дареному коню в зубы
не смотрят.  Как должны выглядеть mono-зависимости никто не знает.

По поводу ACL я имел в виду прежде всего
tcl-8.4.15-alt2.src.rpm
alternatives-0.3.1-alt1.src.rpm

Здесь авторский код совершенно не затронут.  Желательно это на всякий
случай проверить тому, кто собирается проводить пакеты нестандартным
путём.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Tue, Sep 25, 2007 at 12:31:14AM +0400, Alexey Tourbin wrote:
[...]
> 1) pkgconfiglib.req: это упомянуто в changelog'е.  Зависимости *-devel
> пакетов (c *.pc файлом) будут жестко цементироваться по (сборочной)
> хост-среде (т.е. по хешеровскому чруту).  Пока это скорее хорошо,
> чем плохо: зависимости между *-devel пакетами не должны быть слишком
> "виртуальными".  А именно, например, -ldb-4 должно давать зависимость
> на libdb4.4-devel, а не libdb4-devel.

Зачем?  В своё время я даже buildreq substitution rules реализовал для
того, чтобы добиться обратного эффекта.  Чем зависимость на libdb4.4-devel
лучше зависимости на libdb4-devel?

> 3) Запустить две почти синхронные пересборки со старым и новым rpm-build,
> как в прошлый раз.

Так и сделаем.  Спешка тут ни к чему.


-- 
ldv

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:

 > On Tue, Sep 25, 2007 at 12:31:14AM +0400, Alexey Tourbin wrote:
 >> On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
 >> > Если у кого-то остались вопросы, то думаю, что весь день 24 сентября
 >> > их будет очень уместно задавать.
 >> 
 >> Вопросов в этот бизнес-день не поступило.  Предварительное тестирование
 >> закончено.  В mash:~at/SRPMS/ выложена пачка подписанных RC-пакетов:
 >> 
 >> rpm-4.0.4-alt78.src.rpm
 >> rpm-build-mono-1.1-alt1.src.rpm
 >> rpm-build-python-0.31-alt1.src.rpm
 >> rpm-build-tcl-0.2.1-alt1.src.rpm
 >> tcl-8.4.15-alt2.src.rpm
 >> alternatives-0.3.1-alt1.src.rpm
 >> 
 >> Надеюсь, что протестов от maintainer'ов пакетов, по которым у меня нет
 >> прав по ACL, не последует.  Все изменения узкие и направлены только на
 >> поддержку нового rpm-build (они опубликованы в моих git-репозитариях).

 > Эта пачка пакетов пойдёт в Сизиф нестандартным путём, так что прошу
 > успеть выступить с протестами до того как пакеты попадут в Сизиф.

Насколько я понимаю, tcl теперь обзаведётся зависимостью на самого
себя при сборке: tcl -> rpm-build-tcl -> /usr/bin/tclsh
Я нахожу это неприемлемым.
Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,
после чего уложить в сизиф. Предлагаю также не выкладывать в сизиф
tcl-8.4.15-alt2 - у меня дргуие планы на него.
Предлагаю майнтейнерам tcl-related пакетов указывать
при желании/необходимости как rpm-build-tcl, так и tcl(-devel).

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 01:30:10AM +0400, Sergey Bolshakov wrote:
> Насколько я понимаю, tcl теперь обзаведётся зависимостью на самого
> себя при сборке: tcl -> rpm-build-tcl -> /usr/bin/tclsh

Нет.  Топология зависимостей другая:
tcl-devel -> rpm-build-tcl -> tcl

То есть, tcl, действительно, потенциально обзаведется сборочной
зависимостью на самого себя.  Но buildreq должен обнаруживать эту
зависимость, и только это делает её неправильной.  То есть при сборке
tcl-src.rpm пакет tcl стоит в чруте, но фактически не используется.

> Я нахожу это неприемлемым.
> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,

Эту зависимость удалять нельзя, поскольку работоспособность
rpm-build-tcl напрямую связана с наличием /usr/bin/tcl.
(Во всех случаях, кроме одного единственного -- сборка самого tcl,
где используется переопределение RPM_TCLSH).

> после чего уложить в сизиф. Предлагаю также не выкладывать в сизиф
> tcl-8.4.15-alt2 - у меня дргуие планы на него.

Здесь ничего сказать не могу.

> Предлагаю майнтейнерам tcl-related пакетов указывать
> при желании/необходимости как rpm-build-tcl, так и tcl(-devel).

Если удаление rpm-build-tcl из rpm-build (базовой сборочной среды)
не вызывает протеста, то предложенная схема перетасовки зависимостей
является наиболее консистентной.  Я готов это обсудить ещё раз.

В худшем случае я готов отказаться от своих новых сборок tcl и
rpm-build-tcl, и будь что будет.  Однако, сломается гораздо больше.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 01:30:02AM +0400, Dmitry V. Levin wrote:
> > 1) pkgconfiglib.req: это упомянуто в changelog'е.  Зависимости *-devel
> > пакетов (c *.pc файлом) будут жестко цементироваться по (сборочной)
> > хост-среде (т.е. по хешеровскому чруту).  Пока это скорее хорошо,
> > чем плохо: зависимости между *-devel пакетами не должны быть слишком
> > "виртуальными".  А именно, например, -ldb-4 должно давать зависимость
> > на libdb4.4-devel, а не libdb4-devel.
> 
> Зачем?  В своё время я даже buildreq substitution rules реализовал для
> того, чтобы добиться обратного эффекта.  Чем зависимость на libdb4.4-devel
> лучше зависимости на libdb4-devel?

Приведи контр-пример, когда зависимость на lib%name-devel нежелательна,
а желателен ее "более виртуальный" аналог.

Подвижность BuildRequires зависимостей нужна для того, чтобы осуществить
возможность as-is пересборки src.rpm пакета в "контрлируемо"-другой
среде.  В частности, BuildRequires зависимость на libdb4-devel выражает
надежду, что данный src.rpm пакет удастся собрать с любым другим
libdb4.?-devel пакетом (вероятно, наиболее свежим).

Когда пакет собрался, то надежды уступают место действительности.
Например, мы собирали пакет libfoo.src.rpm.  Одноименный пакет
libfoo.i586.rpm получит реальную зависимость на libdb-4.4.so.
Теперь встает вопрос, какую зависимость должен получить
libfoo-devel.i586.rpm пакет, если у него в *.pc файле указано
"-ldb-4".  Я считаю, что эта зависимость должна быть конкретной:
libdb4.4-devel.  То есть соответствовать содержимому чрута, в котором
что-то ещё слинковалось с libdb-4.4.so.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:

 > On Tue, Sep 25, 2007 at 01:30:10AM +0400, Sergey Bolshakov wrote:
 >> Насколько я понимаю, tcl теперь обзаведётся зависимостью на самого
 >> себя при сборке: tcl -> rpm-build-tcl -> /usr/bin/tclsh

 > Нет.  Топология зависимостей другая:
 > tcl-devel -> rpm-build-tcl -> tcl

 > То есть, tcl, действительно, потенциально обзаведется сборочной
 > зависимостью на самого себя.  Но buildreq должен обнаруживать эту
 > зависимость, и только это делает её неправильной.  То есть при сборке
 > tcl-src.rpm пакет tcl стоит в чруте, но фактически не используется.

 >> Я нахожу это неприемлемым.
 >> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,

 > Эту зависимость удалять нельзя, поскольку работоспособность
 > rpm-build-tcl напрямую связана с наличием /usr/bin/tcl.
 > (Во всех случаях, кроме одного единственного -- сборка самого tcl,
 > где используется переопределение RPM_TCLSH).

Такой подход делает невозможным перенос tcl на другие архитектуры,
поскольку (по условию) /usr/bin/tclsh там ещё не существует.

С другой стороны, пакеты, содержащие модули tcl и заселявшие
/usr/{lib,share}/tcl, содержали в сборочных чрутах /usr/bin/tclsh
через tcl-devel, остальные либо содержали явную зависимость на
tcl, либо не предоставляли по результатам сборки зависимостей вида
tcl(xxx) -- ну и пусть их, уважаемым майнтайнерам виднее.

Короче, я ещё раз предлагаю убрать эту зависимость.
 
 >> после чего уложить в сизиф. Предлагаю также не выкладывать в сизиф
 >> tcl-8.4.15-alt2 - у меня дргуие планы на него.

 > Здесь ничего сказать не могу.
8.4.16 released, так что нет смысла в alt2.
rpm-build-tcl в зависимости tcl-devel я добавил.

 >> Предлагаю майнтейнерам tcl-related пакетов указывать
 >> при желании/необходимости как rpm-build-tcl, так и tcl(-devel).

 > Если удаление rpm-build-tcl из rpm-build (базовой сборочной среды)
 > не вызывает протеста, то предложенная схема перетасовки зависимостей
 > является наиболее консистентной.  Я готов это обсудить ещё раз.

 > В худшем случае я готов отказаться от своих новых сборок tcl и
 > rpm-build-tcl, и будь что будет.  Однако, сломается гораздо больше.

Я, видимо, ответственнен за бОльшую часть tcl-related и не вижу
проблемы в добавлении buildreq(pre): rpm-build-tcl во все такие
пакеты. Вообще, уважаемые майнтейнеры, эта тема Вас хоть
сколько-нибудь интересует ?

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Tue, Sep 25, 2007 at 02:01:14AM +0400, Alexey Tourbin wrote:
> On Tue, Sep 25, 2007 at 01:30:02AM +0400, Dmitry V. Levin wrote:
> > > 1) pkgconfiglib.req: это упомянуто в changelog'е.  Зависимости *-devel
> > > пакетов (c *.pc файлом) будут жестко цементироваться по (сборочной)
> > > хост-среде (т.е. по хешеровскому чруту).  Пока это скорее хорошо,
> > > чем плохо: зависимости между *-devel пакетами не должны быть слишком
> > > "виртуальными".  А именно, например, -ldb-4 должно давать зависимость
> > > на libdb4.4-devel, а не libdb4-devel.
> > 
> > Зачем?  В своё время я даже buildreq substitution rules реализовал для
> > того, чтобы добиться обратного эффекта.  Чем зависимость на libdb4.4-devel
> > лучше зависимости на libdb4-devel?
> 
> Приведи контр-пример, когда зависимость на lib%name-devel нежелательна,
> а желателен ее "более виртуальный" аналог.
> 
> Подвижность BuildRequires зависимостей нужна для того, чтобы осуществить
> возможность as-is пересборки src.rpm пакета в "контрлируемо"-другой
> среде.  В частности, BuildRequires зависимость на libdb4-devel выражает
> надежду, что данный src.rpm пакет удастся собрать с любым другим
> libdb4.?-devel пакетом (вероятно, наиболее свежим).

Да.

> Когда пакет собрался, то надежды уступают место действительности.
> Например, мы собирали пакет libfoo.src.rpm.  Одноименный пакет
> libfoo.i586.rpm получит реальную зависимость на libdb-4.4.so.
> Теперь встает вопрос, какую зависимость должен получить
> libfoo-devel.i586.rpm пакет, если у него в *.pc файле указано
> "-ldb-4".  Я считаю, что эта зависимость должна быть конкретной:
> libdb4.4-devel.  То есть соответствовать содержимому чрута, в котором
> что-то ещё слинковалось с libdb-4.4.so.

Логично.  Те немногие варианты, который в этой ситуации приводят к излишне
жёсткой зависимости -- это когда -ldb-4 находится в Libs.private (тогда и
libdb4-devel будет избыточным) или просто является лишней библиотекой,
которую вычищает --as-needed.  Вероятно Libs.private лучше обрабатывать
только в случае если в пакет упаковывается соответствующая статическая
библиотека, а избыточный -ldb-4 можно считать заботой мантейнера.


-- 
ldv

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [070925 01:07]:
> Эта пачка пакетов пойдёт в Сизиф нестандартным путём, так что прошу
> успеть выступить с протестами до того как пакеты попадут в Сизиф.
Будет полная пересборка Сизифа роботом (и надо срочно заливать
исправления) или новые пакеты можно готовить "не торопясь"?  Тем
более что робот-пересборщик у нас как МСВС, т.е. не существует.

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 02:14:16AM +0400, Sergey Bolshakov wrote:
>  >> Я нахожу это неприемлемым.
>  >> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,
> 
>  > Эту зависимость удалять нельзя, поскольку работоспособность
>  > rpm-build-tcl напрямую связана с наличием /usr/bin/tcl.
>  > (Во всех случаях, кроме одного единственного -- сборка самого tcl,
>  > где используется переопределение RPM_TCLSH).
> 
> Такой подход делает невозможным перенос tcl на другие архитектуры,
> поскольку (по условию) /usr/bin/tclsh там ещё не существует.

Такой подход также делает невозможным перенос perl-base на другие
архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
существует.  А также python-base (который привязан к rpm-build).

В общем, это условие слишком абстрактно.  Для каждой конкретной
архитектуры всё равно приходится делать bootstrap, и там ситуация
на первых порах бывает покруче, чем недоступность какого-то
интерпретатора.  Даже неудобно тебе это объяснять.

> С другой стороны, пакеты, содержащие модули tcl и заселявшие
> /usr/{lib,share}/tcl, содержали в сборочных чрутах /usr/bin/tclsh
> через tcl-devel, остальные либо содержали явную зависимость на
> tcl, либо не предоставляли по результатам сборки зависимостей вида
> tcl(xxx) -- ну и пусть их, уважаемым майнтайнерам виднее.
> 
> Короче, я ещё раз предлагаю убрать эту зависимость.

Здесь я не совсем понял.
Однако предлагаю обдумать ещё раз следующее утверждение:

В rpm-build-tcl НУЖНА зависимость на /usr/bin/tclsh КРОМЕ ОДНОГО
ЕДИНСТВЕННОГО СЛУЧАЯ -- сборки самого tcl.  Иначе запуск скриптов
/usr/lib/rpm/tcl.{req,prov} ничем не гарантирован -- он просто
обломится.  Вариант c [ -x /usr/bin/tclsh ] is not an option.
Зависимости либо ищутся, либо явно отключены.  Проверки доступности
интерпретатора больше нету в принципе.

>  >> после чего уложить в сизиф. Предлагаю также не выкладывать в сизиф
>  >> tcl-8.4.15-alt2 - у меня дргуие планы на него.
> 
>  > Здесь ничего сказать не могу.
> 8.4.16 released, так что нет смысла в alt2.
> rpm-build-tcl в зависимости tcl-devel я добавил.

Это уже лучше.

> Я, видимо, ответственнен за бОльшую часть tcl-related и не вижу
> проблемы в добавлении buildreq(pre): rpm-build-tcl во все такие
> пакеты. Вообще, уважаемые майнтейнеры, эта тема Вас хоть
> сколько-нибудь интересует ?

Не надо целиком замыкать на себя какую-то группу пакетов.  Рано или
поздно может появиться человек, который будет что-то собирать, и это
будет зудеть, и с этом ничего нельзя будет сделать.  С другой стороны,
это дает возможность думать, что нужно дать другим людям, которые не
сильно-то в теме.  В случае с перлом таким человеком стал lav@.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey I. Froloff]

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

* Sergey Bolshakov <sbolshakov@> [070925 02:17]:
> Я, видимо, ответственнен за бОльшую часть tcl-related и не вижу
> проблемы в добавлении buildreq(pre): rpm-build-tcl во все такие
> пакеты. Вообще, уважаемые майнтейнеры, эта тема Вас хоть
> сколько-нибудь интересует ?
А если бы мы использовали %include (как в PLD?), такие вещи могли
бы попадать в buildreq(pre) автоматом...

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Sergey" == Sergey Bolshakov <sbolshakov@altlinux.ru> writes:
[skipped]
 > 8.4.16 released, так что нет смысла в alt2.
 > rpm-build-tcl в зависимости tcl-devel я добавил.

FYI: tcl-8.4.16-alt1 (и парный ему tk) с правками из alt2 в incoming

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Tue, Sep 25, 2007 at 02:28:39AM +0400, Alexey I. Froloff wrote:
> * Dmitry V. Levin <ldv@> [070925 01:07]:
> > Эта пачка пакетов пойдёт в Сизиф нестандартным путём, так что прошу
> > успеть выступить с протестами до того как пакеты попадут в Сизиф.
> Будет полная пересборка Сизифа роботом (и надо срочно заливать
> исправления) или новые пакеты можно готовить "не торопясь"?  Тем
> более что робот-пересборщик у нас как МСВС, т.е. не существует.

У нас есть только робот для тестовых пересборок, для настоящих пересборок
требуется вмешательство человека.
Так что новые пакеты можно готовить в плановом порядке, лишь бы не
потерять необходимые изменения и не залить requires раньше provides.


-- 
ldv

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:

 > On Tue, Sep 25, 2007 at 02:14:16AM +0400, Sergey Bolshakov wrote:
 >> >> Я нахожу это неприемлемым.
 >> >> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,
 >> 
 >> > Эту зависимость удалять нельзя, поскольку работоспособность
 >> > rpm-build-tcl напрямую связана с наличием /usr/bin/tcl.
 >> > (Во всех случаях, кроме одного единственного -- сборка самого tcl,
 >> > где используется переопределение RPM_TCLSH).
 >> 
 >> Такой подход делает невозможным перенос tcl на другие архитектуры,
 >> поскольку (по условию) /usr/bin/tclsh там ещё не существует.

 > Такой подход также делает невозможным перенос perl-base на другие
 > архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
 > существует.  А также python-base (который привязан к rpm-build).

 > В общем, это условие слишком абстрактно.  Для каждой конкретной
 > архитектуры всё равно приходится делать bootstrap, и там ситуация
 > на первых порах бывает покруче, чем недоступность какого-то
 > интерпретатора.  Даже неудобно тебе это объяснять.

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

 >> С другой стороны, пакеты, содержащие модули tcl и заселявшие
 >> /usr/{lib,share}/tcl, содержали в сборочных чрутах /usr/bin/tclsh
 >> через tcl-devel, остальные либо содержали явную зависимость на
 >> tcl, либо не предоставляли по результатам сборки зависимостей вида
 >> tcl(xxx) -- ну и пусть их, уважаемым майнтайнерам виднее.
 >> 
 >> Короче, я ещё раз предлагаю убрать эту зависимость.

 > Здесь я не совсем понял.
 > Однако предлагаю обдумать ещё раз следующее утверждение:

 > В rpm-build-tcl НУЖНА зависимость на /usr/bin/tclsh КРОМЕ ОДНОГО
 > ЕДИНСТВЕННОГО СЛУЧАЯ -- сборки самого tcl.  Иначе запуск скриптов
 > /usr/lib/rpm/tcl.{req,prov} ничем не гарантирован -- он просто
 > обломится.  Вариант c [ -x /usr/bin/tclsh ] is not an option.
 > Зависимости либо ищутся, либо явно отключены.  Проверки доступности
 > интерпретатора больше нету в принципе.

Ну так rpm-build-tcl из rpm-build нынче вынесен, и появиться там он
теперь может либо в паре с tcl-devel, либо по явному требованию -- ну
так что мешает майнтайнеру явно же обеспечить наличие tclsh в билдруте ?

 >> Я, видимо, ответственнен за бОльшую часть tcl-related и не вижу
 >> проблемы в добавлении buildreq(pre): rpm-build-tcl во все такие
 >> пакеты. Вообще, уважаемые майнтейнеры, эта тема Вас хоть
 >> сколько-нибудь интересует ?

 > Не надо целиком замыкать на себя какую-то группу пакетов.  Рано или
 > поздно может появиться человек, который будет что-то собирать, и это
 > будет зудеть, и с этом ничего нельзя будет сделать.  С другой стороны,
 > это дает возможность думать, что нужно дать другим людям, которые не
 > сильно-то в теме.  В случае с перлом таким человеком стал lav@.

Не буду.

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 03:02:20AM +0400, Sergey Bolshakov wrote:
>  >> Такой подход делает невозможным перенос tcl на другие архитектуры,
>  >> поскольку (по условию) /usr/bin/tclsh там ещё не существует.
> 
>  > Такой подход также делает невозможным перенос perl-base на другие
>  > архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
>  > существует.  А также python-base (который привязан к rpm-build).
> 
>  > В общем, это условие слишком абстрактно.  Для каждой конкретной
>  > архитектуры всё равно приходится делать bootstrap, и там ситуация
>  > на первых порах бывает покруче, чем недоступность какого-то
>  > интерпретатора.  Даже неудобно тебе это объяснять.
> 
> Мил человек, это мне неудобно тебе объяснять -- негоже создавать
> геморрой на пустом месте. Я как бы немножко помню, во что выливается
> бутстрап на другую архитектуру и не стану его создавать там, где могу
> не создавать. Разумеется, с перлом ты волен делать что тебе вздумается.

Просто проблема с tcl далеко не первична, если речь идет о бутстрапе,
тем более на уровне rpm-зависимостей, а не более суровых фактических
зависимостей.  (Но rpm-зависимости всё же в первом приближении
мимикрируют "суровые" настоящие зависимости, для чего они и нужны.)

Хорошо.  Делай что хочешь.  Отмечу лишь следующее.

В предолженном мной варианте я брал часть ответственности за Tcl
на себя.  То есть если что-либо идет на перекосяк, то я берусь
в какой-то степени это разруливать, вплоть до возвращения в
rpm-build-tcl в базовую сборочную среду (но уже вместе с /usr/bin/tclsh,
то есть в моём варианте!).

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC [JT]

[Vitaly Lipatov]

On 25 сентября 2007, Alexey Tourbin wrote:
...
> Не надо целиком замыкать на себя какую-то группу пакетов. 
> Рано или поздно может появиться человек, который будет что-то
> собирать, и это будет зудеть, и с этом ничего нельзя будет
> сделать.  С другой стороны, это дает возможность думать, что
> нужно дать другим людям, которые не сильно-то в теме.  В
> случае с перлом таким человеком стал lav@.
Алексей, уже можете расслабиться в отношении меня. Никаким я ещё 
не стал.

P.S.
Если человек не видит своих ошибок, это не означает, что у него 
их нет.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Kirill A. Shutemov]

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

On [Tue, 25.09.2007 02:30], Alexey Tourbin wrote:
> On Tue, Sep 25, 2007 at 02:14:16AM +0400, Sergey Bolshakov wrote:
> >  >> Я нахожу это неприемлемым.
> >  >> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,
> > 
> >  > Эту зависимость удалять нельзя, поскольку работоспособность
> >  > rpm-build-tcl напрямую связана с наличием /usr/bin/tcl.
> >  > (Во всех случаях, кроме одного единственного -- сборка самого tcl,
> >  > где используется переопределение RPM_TCLSH).
> > 
> > Такой подход делает невозможным перенос tcl на другие архитектуры,
> > поскольку (по условию) /usr/bin/tclsh там ещё не существует.
> 
> Такой подход также делает невозможным перенос perl-base на другие
> архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
> существует.  А также python-base (который привязан к rpm-build).
> 
> В общем, это условие слишком абстрактно.  Для каждой конкретной
> архитектуры всё равно приходится делать bootstrap, и там ситуация
> на первых порах бывает покруче, чем недоступность какого-то
> интерпретатора.  Даже неудобно тебе это объяснять.
> 

Угу. tetex -- это что-то.

> > С другой стороны, пакеты, содержащие модули tcl и заселявшие
> > /usr/{lib,share}/tcl, содержали в сборочных чрутах /usr/bin/tclsh
> > через tcl-devel, остальные либо содержали явную зависимость на
> > tcl, либо не предоставляли по результатам сборки зависимостей вида
> > tcl(xxx) -- ну и пусть их, уважаемым майнтайнерам виднее.
> > 
> > Короче, я ещё раз предлагаю убрать эту зависимость.
> 
> Здесь я не совсем понял.
> Однако предлагаю обдумать ещё раз следующее утверждение:
> 
> В rpm-build-tcl НУЖНА зависимость на /usr/bin/tclsh КРОМЕ ОДНОГО
> ЕДИНСТВЕННОГО СЛУЧАЯ -- сборки самого tcl.  Иначе запуск скриптов
> /usr/lib/rpm/tcl.{req,prov} ничем не гарантирован -- он просто
> обломится.  Вариант c [ -x /usr/bin/tclsh ] is not an option.
> Зависимости либо ищутся, либо явно отключены.  Проверки доступности
> интерпретатора больше нету в принципе.
> 
> >  >> после чего уложить в сизиф. Предлагаю также не выкладывать в сизиф
> >  >> tcl-8.4.15-alt2 - у меня дргуие планы на него.
> > 
> >  > Здесь ничего сказать не могу.
> > 8.4.16 released, так что нет смысла в alt2.
> > rpm-build-tcl в зависимости tcl-devel я добавил.
> 
> Это уже лучше.
> 
> > Я, видимо, ответственнен за бОльшую часть tcl-related и не вижу
> > проблемы в добавлении buildreq(pre): rpm-build-tcl во все такие
> > пакеты. Вообще, уважаемые майнтейнеры, эта тема Вас хоть
> > сколько-нибудь интересует ?
> 
> Не надо целиком замыкать на себя какую-то группу пакетов.  Рано или
> поздно может появиться человек, который будет что-то собирать, и это
> будет зудеть, и с этом ничего нельзя будет сделать.  С другой стороны,
> это дает возможность думать, что нужно дать другим людям, которые не
> сильно-то в теме.  В случае с перлом таким человеком стал lav@.



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


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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Kirill A. Shutemov]

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

On [Tue, 25.09.2007 03:02], Sergey Bolshakov wrote:
> >>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:
> 
>  > On Tue, Sep 25, 2007 at 02:14:16AM +0400, Sergey Bolshakov wrote:
>  >> >> Я нахожу это неприемлемым.
>  >> >> Предлагаю удалить зависимость на /usr/bin/tclsh из rpm-build-tcl,
>  >> 
>  >> > Эту зависимость удалять нельзя, поскольку работоспособность
>  >> > rpm-build-tcl напрямую связана с наличием /usr/bin/tcl.
>  >> > (Во всех случаях, кроме одного единственного -- сборка самого tcl,
>  >> > где используется переопределение RPM_TCLSH).
>  >> 
>  >> Такой подход делает невозможным перенос tcl на другие архитектуры,
>  >> поскольку (по условию) /usr/bin/tclsh там ещё не существует.
> 
>  > Такой подход также делает невозможным перенос perl-base на другие
>  > архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
>  > существует.  А также python-base (который привязан к rpm-build).
> 
>  > В общем, это условие слишком абстрактно.  Для каждой конкретной
>  > архитектуры всё равно приходится делать bootstrap, и там ситуация
>  > на первых порах бывает покруче, чем недоступность какого-то
>  > интерпретатора.  Даже неудобно тебе это объяснять.
> 
> Мил человек, это мне неудобно тебе объяснять -- негоже создавать
> геморрой на пустом месте. Я как бы немножко помню, во что выливается
> бутстрап на другую архитектуру и не стану его создавать там, где могу
> не создавать. Разумеется, с перлом ты волен делать что тебе вздумается.

Как по-мне, так хватило бы какого-нибудь --with/--enable для bootstrap'а,
котрый при сборке отключал эту зависимость. Всё равно для создания порта
нужно несколько проходов сборки.

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Tue, Sep 25, 2007 at 03:12:35AM +0400, Alexey Tourbin wrote:
> On Tue, Sep 25, 2007 at 03:02:20AM +0400, Sergey Bolshakov wrote:
> >  >> Такой подход делает невозможным перенос tcl на другие архитектуры,
> >  >> поскольку (по условию) /usr/bin/tclsh там ещё не существует.
> > 
> >  > Такой подход также делает невозможным перенос perl-base на другие
> >  > архитектуры (который входит в basesystem), где /usr/bin/perl ещё не
> >  > существует.  А также python-base (который привязан к rpm-build).
> > 
> >  > В общем, это условие слишком абстрактно.  Для каждой конкретной
> >  > архитектуры всё равно приходится делать bootstrap, и там ситуация
> >  > на первых порах бывает покруче, чем недоступность какого-то
> >  > интерпретатора.  Даже неудобно тебе это объяснять.
> > 
> > Мил человек, это мне неудобно тебе объяснять -- негоже создавать
> > геморрой на пустом месте. Я как бы немножко помню, во что выливается
> > бутстрап на другую архитектуру и не стану его создавать там, где могу
> > не создавать. Разумеется, с перлом ты волен делать что тебе вздумается.
> 
> Просто проблема с tcl далеко не первична, если речь идет о бутстрапе,
> тем более на уровне rpm-зависимостей, а не более суровых фактических
> зависимостей.  (Но rpm-зависимости всё же в первом приближении
> мимикрируют "суровые" настоящие зависимости, для чего они и нужны.)
> 
> Хорошо.  Делай что хочешь.  Отмечу лишь следующее.
> 
> В предолженном мной варианте я брал часть ответственности за Tcl
> на себя.  То есть если что-либо идет на перекосяк, то я берусь
> в какой-то степени это разруливать, вплоть до возвращения в
> rpm-build-tcl в базовую сборочную среду (но уже вместе с /usr/bin/tclsh,
> то есть в моём варианте!).
> 
> Если мой вариант не катит, то я ответственность с себя снимаю.
> Я уже писал, что сломаться может гораздо больше.

Короче, Алексей, Сергей, вы договорились?
Откуда мне брать новый rpm-build-tcl?


-- 
ldv

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Dmitry" == Dmitry V Levin <ldv@altlinux.org> writes:
 > On Tue, Sep 25, 2007 at 03:12:35AM +0400, Alexey Tourbin wrote:
[skipped]

 >> Хорошо.  Делай что хочешь.  Отмечу лишь следующее.
 >> 
 >> В предолженном мной варианте я брал часть ответственности за Tcl
 >> на себя.  То есть если что-либо идет на перекосяк, то я берусь
 >> в какой-то степени это разруливать, вплоть до возвращения в
 >> rpm-build-tcl в базовую сборочную среду (но уже вместе с /usr/bin/tclsh,
 >> то есть в моём варианте!).
 >> 
 >> Если мой вариант не катит, то я ответственность с себя снимаю.
 >> Я уже писал, что сломаться может гораздо больше.

 > Короче, Алексей, Сергей, вы договорились?
 > Откуда мне брать новый rpm-build-tcl?

Похоже, нам нужен третий.

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 05:17:10PM +0400, Dmitry V. Levin wrote:
> > Просто проблема с tcl далеко не первична, если речь идет о бутстрапе,
> > тем более на уровне rpm-зависимостей, а не более суровых фактических
> > зависимостей.  (Но rpm-зависимости всё же в первом приближении
> > мимикрируют "суровые" настоящие зависимости, для чего они и нужны.)
> > 
> > Хорошо.  Делай что хочешь.  Отмечу лишь следующее.
> > 
> > В предолженном мной варианте я брал часть ответственности за Tcl
> > на себя.  То есть если что-либо идет на перекосяк, то я берусь
> > в какой-то степени это разруливать, вплоть до возвращения в
> > rpm-build-tcl в базовую сборочную среду (но уже вместе с /usr/bin/tclsh,
> > то есть в моём варианте!).
> > 
> > Если мой вариант не катит, то я ответственность с себя снимаю.
> > Я уже писал, что сломаться может гораздо больше.
> 
> Короче, Алексей, Сергей, вы договорились?
> Откуда мне брать новый rpm-build-tcl?

Предлагаю Сергею сделать rpm-build-tcl с версий > 0.2 на основе моего
git-репозитаория (с откатом того, что не нравится и т.п.).

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

Re: [devel] rpm-build 4.0.4-alt78+ RC [JT]

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 07:09:34AM +0400, Vitaly Lipatov wrote:
> > Не надо целиком замыкать на себя какую-то группу пакетов. 
> > Рано или поздно может появиться человек, который будет что-то
> > собирать, и это будет зудеть, и с этом ничего нельзя будет
> > сделать.  С другой стороны, это дает возможность думать, что
> > нужно дать другим людям, которые не сильно-то в теме.  В
> > случае с перлом таким человеком стал lav@.
> Алексей, уже можете расслабиться в отношении меня. Никаким я ещё 
> не стал.

Хорошо.

> P.S.
> Если человек не видит своих ошибок, это не означает, что у него 
> их нет.

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:
[skipped]

 >> Короче, Алексей, Сергей, вы договорились?
 >> Откуда мне брать новый rpm-build-tcl?

 > Предлагаю Сергею сделать rpm-build-tcl с версий > 0.2 на основе моего
 > git-репозитаория (с откатом того, что не нравится и т.п.).

Ещё раз:
мне не нравится циклическая сборочная зависимость tcl на самого себя,
и я не стану предлагать к рассмотрению сценарии, когда это плохо или
плохо-плохо -- они понятны.
at@ -- она там не косвенная, а самая прямая, поскольку для сборки
tcl нужен rpm-build-tcl.
Далее, предлагаемые изменения _ничего_ не добавляют в качестве
порождаемых rpm-build-tcl зависимостей, и, таким образом,
_для_ _rpm-build-tcl_ являются, как бы это помягче, балластом.

Бишь, суета и некоторый регресс в tcl в качестве цены за прогресс в
прочих местах. Я не могу сделать выбора.

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 07:06:46PM +0400, Sergey Bolshakov wrote:
>  >> Короче, Алексей, Сергей, вы договорились?
>  >> Откуда мне брать новый rpm-build-tcl?
> 
>  > Предлагаю Сергею сделать rpm-build-tcl с версий > 0.2 на основе моего
>  > git-репозитаория (с откатом того, что не нравится и т.п.).
> 
> Ещё раз:
> мне не нравится циклическая сборочная зависимость tcl на самого себя,
> и я не стану предлагать к рассмотрению сценарии, когда это плохо или
> плохо-плохо -- они понятны.
> at@ -- она там не косвенная, а самая прямая, поскольку для сборки
> tcl нужен rpm-build-tcl.
> Далее, предлагаемые изменения _ничего_ не добавляют в качестве
> порождаемых rpm-build-tcl зависимостей, и, таким образом,
> _для_ _rpm-build-tcl_ являются, как бы это помягче, балластом.

Понятно.  Но я также рассматриваю пакет rpm-build-tcl сам по себе.
Должен ли он работать САМ ПО СЕБЕ, просто по факту установки?
Или же любое его использование НЕЯВНО ПОДРАЗУМЕВАЕТ некую дополнительную
среду, в которой работосопособность rpm-build-tcl обеспечивается за счёт
косвенных факторов (либо переопределение RPM_TCLSH, либо косвенная
зависимость на tcl у кого-то ещё)?

Я склоняюсь к первому ответу, ты -- ко второму.

Что может ещё говорить в пользу первого ответа?  Если бы rpm-build-tcl
остался в базовой сборочной среде, то выбор в пользу первого варианта
стал бы безальтернативным.  В базовой сборочной среде не должно быть
скриптов, возможность запуска которых ничем не обеспечивается.  Иначе
поиск зависимостей в любом пакете, в котором есть файл с расширением
*.tcl, тупо отваливает (даже если это не Tcl-скрипт, а какой-нибудь
syntax highlight, как в пакете geany).

То есть, при попадании в базовую сброчную среду любого rpm-build-*
пакета возможность запуска его скриптов должна быть железно
гарантирована через зависимости на соответствующий базовый рантайм.
Пакет должен работать сам по себе.

При отвязывании же пакета от rpm-build появляется искушение думать,
что работоспособность сама по себе имеет меньшее значение. :)

> Бишь, суета и некоторый регресс в tcl в качестве цены за прогресс в
> прочих местах. Я не могу сделать выбора.

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at@altlinux.ru> writes:

 > On Tue, Sep 25, 2007 at 07:06:46PM +0400, Sergey Bolshakov wrote:
 >> >> Короче, Алексей, Сергей, вы договорились?
 >> >> Откуда мне брать новый rpm-build-tcl?
 >> 
 >> > Предлагаю Сергею сделать rpm-build-tcl с версий > 0.2 на основе моего
 >> > git-репозитаория (с откатом того, что не нравится и т.п.).
 >> 
 >> Ещё раз:
 >> мне не нравится циклическая сборочная зависимость tcl на самого себя,
 >> и я не стану предлагать к рассмотрению сценарии, когда это плохо или
 >> плохо-плохо -- они понятны.
 >> at@ -- она там не косвенная, а самая прямая, поскольку для сборки
 >> tcl нужен rpm-build-tcl.
 >> Далее, предлагаемые изменения _ничего_ не добавляют в качестве
 >> порождаемых rpm-build-tcl зависимостей, и, таким образом,
 >> _для_ _rpm-build-tcl_ являются, как бы это помягче, балластом.

 > Понятно.  Но я также рассматриваю пакет rpm-build-tcl сам по себе.
 > Должен ли он работать САМ ПО СЕБЕ, просто по факту установки?
 > Или же любое его использование НЕЯВНО ПОДРАЗУМЕВАЕТ некую дополнительную
 > среду, в которой работосопособность rpm-build-tcl обеспечивается за счёт
 > косвенных факторов (либо переопределение RPM_TCLSH, либо косвенная
 > зависимость на tcl у кого-то ещё)?

 > Я склоняюсь к первому ответу, ты -- ко второму.


 > Что может ещё говорить в пользу первого ответа?  Если бы rpm-build-tcl
 > остался в базовой сборочной среде, то выбор в пользу первого варианта
 > стал бы безальтернативным.  В базовой сборочной среде не должно быть
 > скриптов, возможность запуска которых ничем не обеспечивается.  Иначе
 > поиск зависимостей в любом пакете, в котором есть файл с расширением
 > *.tcl, тупо отваливает (даже если это не Tcl-скрипт, а какой-нибудь
 > syntax highlight, как в пакете geany).

 > То есть, при попадании в базовую сброчную среду любого rpm-build-*
 > пакета возможность запуска его скриптов должна быть железно
 > гарантирована через зависимости на соответствующий базовый рантайм.
 > Пакет должен работать сам по себе.

 > При отвязывании же пакета от rpm-build появляется искушение думать,
 > что работоспособность сама по себе имеет меньшее значение. :)

Я так понял, что вынос rpm-build-tcl из rpm-build -- дело решённое.

 >> Бишь, суета и некоторый регресс в tcl в качестве цены за прогресс в
 >> прочих местах. Я не могу сделать выбора.

 > Хм.  Какой-то выбор всё равно сделать надо, в худшем случае
 > подбрасыванием монеты.
В общем, у меня выпало -- выносить rpm-build-tcl из rpm
и /usr/bin/tclsh из rpm-build-tcl. alt2 в гите.
У кого чего сломается -- обращайтесь.

-- 

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 07:44:56PM +0400, Sergey Bolshakov wrote:
>  > Что может ещё говорить в пользу первого ответа?  Если бы rpm-build-tcl
>  > остался в базовой сборочной среде, то выбор в пользу первого варианта
>  > стал бы безальтернативным.  В базовой сборочной среде не должно быть
>  > скриптов, возможность запуска которых ничем не обеспечивается.  Иначе
>  > поиск зависимостей в любом пакете, в котором есть файл с расширением
>  > *.tcl, тупо отваливает (даже если это не Tcl-скрипт, а какой-нибудь
>  > syntax highlight, как в пакете geany).
> 
>  > То есть, при попадании в базовую сброчную среду любого rpm-build-*
>  > пакета возможность запуска его скриптов должна быть железно
>  > гарантирована через зависимости на соответствующий базовый рантайм.
>  > Пакет должен работать сам по себе.
> 
>  > При отвязывании же пакета от rpm-build появляется искушение думать,
>  > что работоспособность сама по себе имеет меньшее значение. :)

> Я так понял, что вынос rpm-build-tcl из rpm-build -- дело решённое.

Было два варианта: либо выносить rpm-build-tcl из rpm-build, либо
вносить tcl в базовую сборочную среду, чтобы запуск скриптов
rpm-build-tcl был гарантирован (второрой вариант -- это по сути
опять же добавление зависимости на /usr/bin/tclsh в rpm-build-tcl!).

Я сначала склонялся к варианту добавления tcl, потому что думал, что
это сможет обеспечить поиск зависимостей и syntax check в более-менее
"случайных" tcl-скриптах (типа /usr/bin/gitk).

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

Может быть, со стороны это выглядит немного наивно, но пытаюсь "решить
дело" с rpm-build-tcl только на основании ОБЩИХ содержательных
рассуждений, которые к тому же пытаюсь формализовать.  Вынос
rpm-build-tcl из rpm-build можно считать "делом решённым" в том смысле,
что я не вижу серьезного противовеса к аргументам, подытоженным в
комментарии к rpm.git 385ae847.  

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

>  >> Бишь, суета и некоторый регресс в tcl в качестве цены за прогресс в
>  >> прочих местах. Я не могу сделать выбора.
> 
>  > Хм.  Какой-то выбор всё равно сделать надо, в худшем случае
>  > подбрасыванием монеты.
> В общем, у меня выпало -- выносить rpm-build-tcl из rpm
> и /usr/bin/tclsh из rpm-build-tcl. alt2 в гите.
> У кого чего сломается -- обращайтесь.

Пусть будет так.  По крайней мере, все пакеты, у которых в BuildRequires
есть tcl-devel, сломаться не должны.  Наверное, необходимость
использования tcl-devel для сборки tcl-специфичных пакетов нужно
признать чем-то вроде полиси.  Пакет rpm-build-tcl в этом случае станет
спутником-фантомом пакета tcl-devel.  В частности, если buildreq
обнаружет одновременное использование пакетов tcl-devel и rpm-build-tcl,
то при оптимизации последний будет удалён из списка.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey I. Froloff]

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

* Sergey Bolshakov <sbolshakov@> [070925 19:14]:
> at@ -- она там не косвенная, а самая прямая, поскольку для сборки
> tcl нужен rpm-build-tcl.
А чем плохо собирать rpm-build-tcl из самого tcl?

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 08:50:22PM +0400, Alexey I. Froloff wrote:
> * Sergey Bolshakov <sbolshakov@> [070925 19:14]:
> > at@ -- она там не косвенная, а самая прямая, поскольку для сборки
> > tcl нужен rpm-build-tcl.
> А чем плохо собирать rpm-build-tcl из самого tcl?

Тем, что существенно разная работа ведется в пределах одного git
репозитария.  Кроме того, текущий дизайн find-requires не позволяет
сколько-нибудь простым способом при поиске зависимостей заменить
"старые" скрипты из /usr/lib/rpm на "новые" где-то в %_builddir или
%buildroot.

К тому же, сейчас сборка tcl существенно полагается на макросы,
которые жестко зашиты в rpm-build-tcl:

Provides: %_tcllibdir
Provides: %_tcldatadir

Для этого даже приходится использовать
BuildRequires(pre): rpm-build-tcl

Короче, вырисовывается следующая топология (упорядоченность)
зависимостей для неосновных rpm-build-* пакетов:

%name-devel -> rpm-build-%name -> %name

Вторая стрелочка в случае с Tcl была оспорена на том основании,
что при сборке самого tcl, поскольку это требует rpm-build-tcl,
в чрут встает сам tcl.  То есть получается что-то вроде круговой
сборочной зависимости tcl на tcl, хотя tcl в чруте в этом случае
фактически не используется.

Возвращаясь к теме.  Для сборки %name-специфичных пакетов элементом
полиси является обязательное (непосредственное или косвенное)
использование %name-devel для сборки.  В этом случае поддержка
rpm-build-%name в чруте происходит автоматически, и о ней не надо
помнить, если только специфические макросы не используются в
зависимостях пакета (но в большинстве случаев так быть не должно).

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 12:31:14AM +0400, Alexey Tourbin wrote:
> On Mon, Sep 24, 2007 at 01:48:14AM +0400, Alexey Tourbin wrote:
> > Если у кого-то остались вопросы, то думаю, что весь день 24 сентября
> > их будет очень уместно задавать.
> 
> Вопросов в этот бизнес-день не поступило.  Предварительное тестирование
> закончено.  В mash:~at/SRPMS/ выложена пачка подписанных RC-пакетов:
> 
> rpm-4.0.4-alt78.src.rpm
> rpm-build-mono-1.1-alt1.src.rpm
> rpm-build-python-0.31-alt1.src.rpm
> rpm-build-tcl-0.2.1-alt1.src.rpm
> tcl-8.4.15-alt2.src.rpm
> alternatives-0.3.1-alt1.src.rpm

Пачка пакетов обновилась в связи с разрешением вопросов по tcl.

rpm-build-tcl-0.2.1-alt2.src.rpm
rpm-4.0.4-alt78.src.rpm
rpm-build-mono-1.1-alt1.src.rpm
rpm-build-python-0.31-alt1.src.rpm
alternatives-0.3.1-alt1.src.rpm

Удалился tcl, добавился rpm-build-tcl alt2.  Он собран
с опцией --packager="Sergey Bolshakov ..." но подписан моим ключом.
Видимо, его лучше переподписать ключом incominger или ALT security
team (после проверки, которая нужна просто потому, что пакеты
проходят нестандартным путём; к тому же, имеет место разрешение
противоречий между maintainer'ами, что также может потребовать
формального подтверждения от кого-то ещё).

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070925 21:05]:
> Кроме того, текущий дизайн find-requires не позволяет
> сколько-нибудь простым способом при поиске зависимостей
> заменить "старые" скрипты из /usr/lib/rpm на "новые" где-то в
> %_builddir или %buildroot.
Да, не подумал.  Зато всегда можно переопределить %__tclsh, что с
успехом и делается.

Я бы переформулировал эту фразу немного по другому - текущий
дизайн скриптов поиска зависимостей (кроме rpm-build-perl ;-) не
позволяет динамически влиять (как минимум добавлять) на конечный
список зависимостей.  Да и rpm-build-perl делает это только
внутри себя.

-- 
Regards,
Sir Raorn.

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

Re: [devel] исполняемые/неисполняемые скрипты

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

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

On Mon, Sep 24, 2007 at 11:14:18AM +0300, Michael Shigorin wrote:

MS> (а по .*-docs? и -contrib было бы совсем хорошо off by default)

contribs не должны жить за пределами %doc, если они действительно
контрибы, и по факту не поддерживаются.

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

http://freesource.info
----------------------------------------------------------------------------
from specfile:
> # Sorry, I have not time:
> Requires: ruby-gnome2-full
Nor brain.
		-- at in #9601

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

Re: [devel] исполняемые/неисполняемые скрипты

[Michael Shigorin]

On Wed, Sep 26, 2007 at 04:23:49PM +0400, Денис Смирнов wrote:
> MS> (а по .*-docs? и -contrib было бы совсем хорошо off by default)
> contribs не должны жить за пределами %doc, если они
> действительно контрибы, и по факту не поддерживаются.

М-да?  Хорошо бы пересмотреть эти пакеты, но так сходу
не уверен:

$ Sisyphus/files> ls */RPMS/*-contrib-* | wc -l
56
$ Sisyphus/files> rpm -qp --qf='%{SOURCERPM}\n' */RPMS/*-contrib-* | sort -u | wc -l
17

Впрочем, проще замять тему. :)

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

Re: [devel] исполняемые/неисполняемые скрипты

[Alexey Tourbin]

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

On Wed, Sep 26, 2007 at 04:23:49PM +0400, Денис Смирнов wrote:
> On Mon, Sep 24, 2007 at 11:14:18AM +0300, Michael Shigorin wrote:
> MS> (а по .*-docs? и -contrib было бы совсем хорошо off by default)
> 
> contribs не должны жить за пределами %doc, если они действительно
> контрибы, и по факту не поддерживаются.

Не совсем.  Иногда есть смысл паковать в отдельный пакет "левые"
скрипты, которые всё же могут кому-то потребоваться (например,
для того, чтобы начать писать собственные скрипты).  Даже зависимости
у *-contrib -- не столь уж глупая идея, хотя иногда они как бы немного
и избыточны.

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

Re: [devel] исполняемые/неисполняемые скрипты

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

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

On Wed, Sep 26, 2007 at 03:33:14PM +0300, Michael Shigorin wrote:

> MS>> (а по .*-docs? и -contrib было бы совсем хорошо off by default)
>> contribs не должны жить за пределами %doc, если они
>> действительно контрибы, и по факту не поддерживаются.
MS> М-да?  Хорошо бы пересмотреть эти пакеты, но так сходу
MS> не уверен:
MS> $ Sisyphus/files> ls */RPMS/*-contrib-* | wc -l
MS> 56
MS> $ Sisyphus/files> rpm -qp --qf='%{SOURCERPM}\n' */RPMS/*-contrib-* | sort -u | wc -l
MS> 17
MS> Впрочем, проще замять тему. :)

Думаю многие contribs у нас поддерживаются куда лучше чем эти же contribs
в оригинале. Если же подразумевается что они "работать не могут, не будут,
и вообще они для read only) -- то их в %docs. Если же они хоть чуть-чуть
работают, да ставятся куда-нибудь в место откуда их могут случайно
исполнить -- в них должны искаться зависимости.

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

http://freesource.info
----------------------------------------------------------------------------
<aphlux> ГУ РК РИЦОКО - что за организация?
<thresh> анимешное что-то
<thresh> судя по "рицоко"

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

[devel] [JT] Re: исполняемые/неисполняемые скрипты

[Michael Shigorin]

On Thu, Sep 27, 2007 at 05:08:12PM +0400, Денис Смирнов wrote:
> Думаю многие contribs у нас поддерживаются куда лучше чем эти
> же contribs в оригинале. Если же подразумевается что они
> "работать не могут, не будут, и вообще они для read only) -- то
> их в %docs. Если же они хоть чуть-чуть работают, да ставятся
> куда-нибудь в место откуда их могут случайно исполнить -- в них
> должны искаться зависимости.

Слушай, будешь проявлять ультразамашки -- потребую _немедленно_
исправить #6042, благо исправление опять есть и ты про него 
в курсе :]  Ты же взялся собирать ppp?  Ну так давай шоб
комар наноноса не подточил.

(control сегодня уже голова не варила)

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070924 01:57]:
> Статус alt78 повышается с беты до RC.
> "Релиз должен быть сегодня".
О!  А поиск зависимостей в пост-скриптах есть?

-- 
Regards,
Sir Raorn.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Fri, Sep 28, 2007 at 02:24:58AM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070924 01:57]:
> > Статус alt78 повышается с беты до RC.
> > "Релиз должен быть сегодня".
> О!  А поиск зависимостей в пост-скриптах есть?

Нет.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070928 07:41]:
> > > Статус alt78 повышается с беты до RC.
> > > "Релиз должен быть сегодня".
> > О!  А поиск зависимостей в пост-скриптах есть?
> Нет.
А планируется?  Или есть какие-то подводные грабли?

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Fri, Sep 28, 2007 at 09:33:51AM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070928 07:41]:
> > > > Статус alt78 повышается с беты до RC.
> > > > "Релиз должен быть сегодня".
> > > О!  А поиск зависимостей в пост-скриптах есть?
> > Нет.
> А планируется?  Или есть какие-то подводные грабли?

Вроде в rpm-4.4.x есть альтернативная реализация.  Я предлагал свою
реализацию в #7409, но она была не совсем чистой с точки зрения rpmlib
API и чего-то ещё.

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

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Fri, Sep 28, 2007 at 09:33:51AM +0400, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [070928 07:41]:
> > > > Статус alt78 повышается с беты до RC.
> > > > "Релиз должен быть сегодня".
> > > О!  А поиск зависимостей в пост-скриптах есть?
> > Нет.
> А планируется?  Или есть какие-то подводные грабли?

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

Соответственно, нет смысла заставлять "среднего maintainer'а" заниматься
мартышкиным трудом -- писать какие-то однотипные пост-срипты.  Чем меньше
maintainer'у надо помнить, тем лучше.

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

[devel] pkgconfiglib.req

[Alexey Tourbin]

[-- Attachment #1.1: Type: text/plain, Size: 1946 bytes --]

On Tue, Sep 25, 2007 at 12:31:14AM +0400, Alexey Tourbin wrote:
> * Mon Sep 24 2007 Alexey Tourbin <at@altlinux> 4.0.4-alt78
> - implemented modular subsystem for find-requires and find-provides;
>   there's no separate doc yet, except for my protva2007-ru-short.pdf;
>   see also git changelog, especially commit 9717c128
> - improved /usr/lib/rpm/find-package algorithms
> - shell.req: non-executable scripts are now processed as well as executable
>   ones; also, more shebang variants are recognized, e.g. "#!/usr/bin/env bash"
> - symlinks.req: new dependency generator for external symbolic links
> - pkgconfig.req: pkg-config(1) errors no longer silently ignored
> - pkgconfiglib.req: new dependency analyzer for "Libs" field in *.pc files;
>   maps e.g. "-lfoo" -> /usr/lib/libfoo.so -> libfoo-devel
> 
> Здесь есть два изменения по сравнению с предыдущим alt78 beta:
> 
> 1) pkgconfiglib.req: это упомянуто в changelog'е.  Зависимости *-devel
> пакетов (c *.pc файлом) будут жестко цементироваться по (сборочной)
> хост-среде (т.е. по хешеровскому чруту).  Пока это скорее хорошо,
> чем плохо: зависимости между *-devel пакетами не должны быть слишком
> "виртуальными".  А именно, например, -ldb-4 должно давать зависимость
> на libdb4.4-devel, а не libdb4-devel.  В дальнейшем цементирование можно
> будет немного ослабить.

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

Рассосались некоторые питоновские анметы.

У *-devel пакетов добавились зависимости на другие *-devel пакеты
из-за pkgonfiglib.req.  В пакетах, которых добавилось слишком много
*-devel зависимостей, вероятно, поле Libs в *.pc файле является
избыточным (нужно перенести часть библиотек в Libs.private).

[-- Attachment #1.2: bilode2.diff.bz2 --]
[-- Type: application/x-bzip2, Size: 21250 bytes --]

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

[devel] libaprutil1-devel-1.2.8-alt2 /usr/lib/libapr-1.so

[Alexey Tourbin]

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

>  libaprutil1-devel-1.2.8-alt2	Provides	pkgconfig(apr-util-1) = 1.2.8
> +libaprutil1-devel-1.2.8-alt2	Requires	/usr/lib/libapr-1.so
>  libaprutil1-devel-1.2.8-alt2	Requires	coreutils

pkgconfiglib.req: /usr/src/tmp/aprutil1-buildroot/usr/lib/pkgconfig/apr-util-1.pc: /usr/lib/libapr-1.so provided by: libapr1 libapr1-devel
pkgconfiglib.req: /usr/src/tmp/aprutil1-buildroot/usr/lib/pkgconfig/apr-util-1.pc: libapr-1.so -> /usr/lib/libapr-1.so (raw, ambiguous)

Эта зависимость не является анметом.

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

Re: [devel] [JT] Re: исполняемые/неисполняемые скрипты

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

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

On Thu, Sep 27, 2007 at 11:53:43PM +0300, Michael Shigorin wrote:

>> Думаю многие contribs у нас поддерживаются куда лучше чем эти
>> же contribs в оригинале. Если же подразумевается что они
>> "работать не могут, не будут, и вообще они для read only) -- то
>> их в %docs. Если же они хоть чуть-чуть работают, да ставятся
>> куда-нибудь в место откуда их могут случайно исполнить -- в них
>> должны искаться зависимости.
MS> Слушай, будешь проявлять ультразамашки -- потребую _немедленно_
MS> исправить #6042, благо исправление опять есть и ты про него 
MS> в курсе :]  Ты же взялся собирать ppp?  Ну так давай шоб
MS> комар наноноса не подточил.
MS> (control сегодня уже голова не варила)

Миша, где ты увидел ультраэкстримизм? Если пакет есть, и устанавливается,
а потом вдруг оказывается что ему ещё десятка пакетов для работы не
хватает это бага. И то что для contribs работает автопоиск зависимостей
это фича, а не бага.

Я не увидел от тебя ни одного обоснования, почему поиск зависимостей в
контрибах это плохо.

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

http://freesource.info
----------------------------------------------------------------------------
Чем более сложна и совершенна программа, тем более неточные результаты она
выдает.

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

[devel] zziplib-devel-0.13.49-alt1

[Alexey Tourbin]

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

>  zziplib-devel-0.13.49-alt1	Provides	pkgconfig(zzip-sdl-config) = 1.2.12
> -zziplib-devel-0.13.49-alt1	Provides	pkgconfig(zzip-sdl-rwops) = 0.13.49
>  zziplib-devel-0.13.49-alt1	Provides	pkgconfig(zzip-zlib-config) = 1.2.3

pkgconfig.prov.files: /usr/src/tmp/zziplib-buildroot/usr/lib/pkgconfig/zzip-sdl-rwops.pc:  MGR bitmap, old format, 1-bit deep, 16-bit aligned


[at@hint1 RPMS]$ rpmpeek zziplib-devel-0.13.49-alt1.i586.rpm head ./usr/lib/pkgconfig/zzip-sdl-rwops.pc
zzipdatadir=/usr/share/zziplib
zzipsdlrwops=${zzipdatadir}/SDL
 
Name: zzip-sdl-rwops
Version: 0.13.49
Description: SDL_rwops for ZZipLib
Requires: zzip-sdl-config, zziplib
Cflags: -I${zzipsdlrwops}                                                                                                                    [at@hint1 RPMS]$ rpmpeek zziplib-devel-0.13.49-alt1.i586.rpm file ./usr/lib/pkgconfig/zzip-sdl-rwops.pc
./usr/lib/pkgconfig/zzip-sdl-rwops.pc: MGR bitmap, old format, 1-bit deep, 16-bit aligned
[at@hint1 RPMS]$

Программа file(1) глюковата.
/usr/share/magic/magic:0        string  zz      MGR bitmap, old format, 1-bit deep, 16-bit aligned

Смысл в том, что нельзя определять тип файла по первым двум
ASCII-буквам.  Нужно проверять как минимум несколько байтов
информации (по Шеннону-Колмогорову), прежде чем давать какой-то
специфический ответ.

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

[devel] WRONG pkgconfiglib.req

[Alexey Tourbin]

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

On Sat, Sep 29, 2007 at 01:45:37PM +0400, Alexey Tourbin wrote:
> У *-devel пакетов добавились зависимости на другие *-devel пакеты
> из-за pkgonfiglib.req.  В пакетах, которых добавилось слишком много
> *-devel зависимостей, вероятно, поле Libs в *.pc файле является
> избыточным (нужно перенести часть библиотек в Libs.private).

К сожалению, текущая реализация pkgconfiglib.req ОШИБОЧНА (о мама!).
Дело в том, что 'pkg-config --libs' транзитивно подставляет все
библиотеки.

$ grep Requires pango.pc
Requires: glib-2.0,gobject-2.0,gmodule-no-export-2.0
$ grep Lib pango.pc     
Libs: -lpango-1.0 -lm
$ pkg-config --libs-only-l pango.pc
-lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0  
$ 

Вставлять транзитивные зависимости в rpm-пакеты нельзя.
В связи с этим релиз alt78 откладывается.  Надеюсь за выходные
исправить pkgconfiglib.req.  В остальном никаких проблем не обнаружено.

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Alexey Tourbin]

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

On Tue, Sep 25, 2007 at 02:24:40AM +0400, Dmitry V. Levin wrote:
> > Когда пакет собрался, то надежды уступают место действительности.
> > Например, мы собирали пакет libfoo.src.rpm.  Одноименный пакет
> > libfoo.i586.rpm получит реальную зависимость на libdb-4.4.so.
> > Теперь встает вопрос, какую зависимость должен получить
> > libfoo-devel.i586.rpm пакет, если у него в *.pc файле указано
> > "-ldb-4".  Я считаю, что эта зависимость должна быть конкретной:
> > libdb4.4-devel.  То есть соответствовать содержимому чрута, в котором
> > что-то ещё слинковалось с libdb-4.4.so.
> 
> Логично.  Те немногие варианты, который в этой ситуации приводят к излишне
> жёсткой зависимости -- это когда -ldb-4 находится в Libs.private (тогда и
> libdb4-devel будет избыточным) или просто является лишней библиотекой,
> которую вычищает --as-needed.  Вероятно Libs.private лучше обрабатывать
> только в случае если в пакет упаковывается соответствующая статическая
> библиотека, а избыточный -ldb-4 можно считать заботой мантейнера.

Что ж ты сразу не сказал что 'pkg-config --libs' подставляет библиотеки
рекурсивно?!  С учетом этого обстоятельства все эти рассуждения
кардинально меняют смысл.  "Схлопывать" транзитивные зависимости нельзя.

Кстати вот
http://lists.altlinux.org/pipermail/sisyphus/2003-December/031990.html

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

Re: [devel] zziplib-devel-0.13.49-alt1

[Alexey Tourbin]

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

On Sat, Sep 29, 2007 at 03:51:57PM +0400, Alexey Tourbin wrote:
> Программа file(1) глюковата.
> /usr/share/magic/magic:0        string  zz      MGR bitmap, old format, 1-bit deep, 16-bit aligned
> 
> Смысл в том, что нельзя определять тип файла по первым двум
> ASCII-буквам.  Нужно проверять как минимум несколько байтов
> информации (по Шеннону-Колмогорову), прежде чем давать какой-то
> специфический ответ.

Поясню на всякий случай, что в двух ASCII-буквах содержится примерно
10-12 битов информации.  Может кто знает это дело и сможет объяснить
лучше.  Суть же в том что по 12 битам определить специфический тип
файла ну никак нельзя.

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

[devel] [RFC] -contrib policy proposal

[Michael Shigorin]

On Sat, Sep 29, 2007 at 02:38:37PM +0400, Денис Смирнов wrote:
> Я не увидел от тебя ни одного обоснования, почему поиск
> зависимостей в контрибах это плохо.

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

То, что работает в нашей среде -- может втягиваться в сам
пакет.  Даже предложил бы такой драфт, если никто не против:

---
Если создаётся подпакет -contrib с прилагаемыми к тарболу
архивами дополнительных скриптов и иных ресурсов, рекомендуется
либо отключить автоматический поиск зависимостей по нему
(FIXME: AutoReq: no), либо при возможности просмотреть содержимое
и включить то, что вообще может быть использовано на платформе
ALT Linux (например, специфичные для Windows или *BSD скрипты
включать в собранный пакет явно не имеет смысла).
---

м?

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

Re: [devel] rpm-build 4.0.4-alt78+ RC

[Dmitry V. Levin]

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

On Sat, Sep 29, 2007 at 09:09:41PM +0400, Alexey Tourbin wrote:
> On Tue, Sep 25, 2007 at 02:24:40AM +0400, Dmitry V. Levin wrote:
> > > Когда пакет собрался, то надежды уступают место действительности.
> > > Например, мы собирали пакет libfoo.src.rpm.  Одноименный пакет
> > > libfoo.i586.rpm получит реальную зависимость на libdb-4.4.so.
> > > Теперь встает вопрос, какую зависимость должен получить
> > > libfoo-devel.i586.rpm пакет, если у него в *.pc файле указано
> > > "-ldb-4".  Я считаю, что эта зависимость должна быть конкретной:
> > > libdb4.4-devel.  То есть соответствовать содержимому чрута, в котором
> > > что-то ещё слинковалось с libdb-4.4.so.
> > 
> > Логично.  Те немногие варианты, который в этой ситуации приводят к излишне
> > жёсткой зависимости -- это когда -ldb-4 находится в Libs.private (тогда и
> > libdb4-devel будет избыточным) или просто является лишней библиотекой,
> > которую вычищает --as-needed.  Вероятно Libs.private лучше обрабатывать
> > только в случае если в пакет упаковывается соответствующая статическая
> > библиотека, а избыточный -ldb-4 можно считать заботой мантейнера.
> 
> Что ж ты сразу не сказал что 'pkg-config --libs' подставляет библиотеки
> рекурсивно?!  С учетом этого обстоятельства все эти рассуждения
> кардинально меняют смысл.  "Схлопывать" транзитивные зависимости нельзя.
> 
> Кстати вот
> http://lists.altlinux.org/pipermail/sisyphus/2003-December/031990.html

С 'pkg-config --libs' приключилась какая-то странная история.
В январе 2004-го (pkg-config-0.15.0-alt3) рекурсия в нашем пакете была
выключена,
в апреле 2005-го (pkg-config-0.17) рекурсия была выключена upstream.
В pkg-config-0.18 рекурсия вновь вернулась, и новый мантейнер пакета, судя
по всему, этого не заметил.

Я попробую снова выключить рекурсию в 'pkg-config --libs' и посмотрю, как
это повлияет на сборку.


-- 
ldv

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

Re: [devel] pkg-config --libs

[Dmitry V. Levin]

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

On Mon, Oct 01, 2007 at 02:03:59AM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 29, 2007 at 09:09:41PM +0400, Alexey Tourbin wrote:
> > On Tue, Sep 25, 2007 at 02:24:40AM +0400, Dmitry V. Levin wrote:
> > > > Когда пакет собрался, то надежды уступают место действительности.
> > > > Например, мы собирали пакет libfoo.src.rpm.  Одноименный пакет
> > > > libfoo.i586.rpm получит реальную зависимость на libdb-4.4.so.
> > > > Теперь встает вопрос, какую зависимость должен получить
> > > > libfoo-devel.i586.rpm пакет, если у него в *.pc файле указано
> > > > "-ldb-4".  Я считаю, что эта зависимость должна быть конкретной:
> > > > libdb4.4-devel.  То есть соответствовать содержимому чрута, в котором
> > > > что-то ещё слинковалось с libdb-4.4.so.
> > > 
> > > Логично.  Те немногие варианты, который в этой ситуации приводят к излишне
> > > жёсткой зависимости -- это когда -ldb-4 находится в Libs.private (тогда и
> > > libdb4-devel будет избыточным) или просто является лишней библиотекой,
> > > которую вычищает --as-needed.  Вероятно Libs.private лучше обрабатывать
> > > только в случае если в пакет упаковывается соответствующая статическая
> > > библиотека, а избыточный -ldb-4 можно считать заботой мантейнера.
> > 
> > Что ж ты сразу не сказал что 'pkg-config --libs' подставляет библиотеки
> > рекурсивно?!  С учетом этого обстоятельства все эти рассуждения
> > кардинально меняют смысл.  "Схлопывать" транзитивные зависимости нельзя.
> > 
> > Кстати вот
> > http://lists.altlinux.org/pipermail/sisyphus/2003-December/031990.html
> 
> С 'pkg-config --libs' приключилась какая-то странная история.
> В январе 2004-го (pkg-config-0.15.0-alt3) рекурсия в нашем пакете была
> выключена,
> в апреле 2005-го (pkg-config-0.17) рекурсия была выключена upstream.
> В pkg-config-0.18 рекурсия вновь вернулась, и новый мантейнер пакета, судя
> по всему, этого не заметил.
> 
> Я попробую снова выключить рекурсию в 'pkg-config --libs' и посмотрю, как
> это повлияет на сборку.

Выключил:
http://git.altlinux.org/people/ldv/packages/?p=pkg-config.git;a=commit;h=v0.22-15-gd6c3b64


-- 
ldv

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

Re: [devel] pkg-config --libs

[Dmitry V. Levin]

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

On Tue, Oct 02, 2007 at 03:42:07AM +0400, Dmitry V. Levin wrote:
> On Mon, Oct 01, 2007 at 02:03:59AM +0400, Dmitry V. Levin wrote:
[...]
> > С 'pkg-config --libs' приключилась какая-то странная история.
> > В январе 2004-го (pkg-config-0.15.0-alt3) рекурсия в нашем пакете была
> > выключена,
> > в апреле 2005-го (pkg-config-0.17) рекурсия была выключена upstream.
> > В pkg-config-0.18 рекурсия вновь вернулась, и новый мантейнер пакета, судя
> > по всему, этого не заметил.
> > 
> > Я попробую снова выключить рекурсию в 'pkg-config --libs' и посмотрю, как
> > это повлияет на сборку.
> 
> Выключил:
> http://git.altlinux.org/people/ldv/packages/?p=pkg-config.git;a=commit;h=v0.22-15-gd6c3b64

Сломалась сборка около сотни пакетов.  Конечно, это происходит из-за
кривизны пакетов: например, некоторые пакеты используют gtk+-2.0 и
glib-2.0, но при этом вызывают только "pkg-config --libs gtk+-2.0" без
"pkg-config --libs glib-2.0".  Видимо, придётся рекурсию вернуть и
добавить какие-то параметры для включения/выключения рекурсии в --libs.


-- 
ldv

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

Re: [devel] pkg-config --libs

[Led]

2007/10/5, Dmitry V. Levin <ldv@altlinux.org>:
> On Tue, Oct 02, 2007 at 03:42:07AM +0400, Dmitry V. Levin wrote:
> > On Mon, Oct 01, 2007 at 02:03:59AM +0400, Dmitry V. Levin wrote:
> [...]
> > > С 'pkg-config --libs' приключилась какая-то странная история.
> > > В январе 2004-го (pkg-config-0.15.0-alt3) рекурсия в нашем пакете была
> > > выключена,
> > > в апреле 2005-го (pkg-config-0.17) рекурсия была выключена upstream.
> > > В pkg-config-0.18 рекурсия вновь вернулась, и новый мантейнер пакета, судя
> > > по всему, этого не заметил.
> > >
> > > Я попробую снова выключить рекурсию в 'pkg-config --libs' и посмотрю, как
> > > это повлияет на сборку.
> >
> > Выключил:
> > http://git.altlinux.org/people/ldv/packages/?p=pkg-config.git;a=commit;h=v0.22-15-gd6c3b64
>
> Сломалась сборка около сотни пакетов.  Конечно, это происходит из-за
> кривизны пакетов: например, некоторые пакеты используют gtk+-2.0 и
> glib-2.0, но при этом вызывают только "pkg-config --libs gtk+-2.0" без
> "pkg-config --libs glib-2.0".

> Видимо, придётся рекурсию вернуть и
> добавить какие-то параметры для включения/выключения рекурсии в --libs.

Да в xine именно так было. Исправил следующим образом:
-  PKG_CHECK_MODULES(GDK_PIXBUF, gdk-pixbuf-2.0,
+  PKG_CHECK_MODULES(GDK_PIXBUF, gdk-pixbuf-2.0 gobject-2.0 glib-2.0,

Так нормально будет?

-- 
Led.

Re: [devel] [RFC] -contrib policy proposal

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

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

On Mon, Oct 01, 2007 at 12:00:00AM +0300, Michael Shigorin wrote:

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

Что это свалка по-определению -- это понятно. Таки чем плох поиск
зависимостей? Это способ сделать пакет в меньшей степени свалкой.

 MS> То, что работает в нашей среде -- может втягиваться в сам
 MS> пакет.  Даже предложил бы такой драфт, если никто не против:

MS> Если создаётся подпакет -contrib с прилагаемыми к тарболу
MS> архивами дополнительных скриптов и иных ресурсов, рекомендуется
MS> либо отключить автоматический поиск зависимостей по нему
MS> (FIXME: AutoReq: no), либо при возможности просмотреть содержимое
MS> и включить то, что вообще может быть использовано на платформе
MS> ALT Linux (например, специфичные для Windows или *BSD скрипты
MS> включать в собранный пакет явно не имеет смысла).

Именно так.

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

http://freesource.info
----------------------------------------------------------------------------
Ёлки-палки, я и забыл, что man уже давно не мой пакет. :)
		-- ldv in #6988

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

Re: [devel] [RFC] -contrib policy proposal

[Michael Shigorin]

On Sun, Oct 21, 2007 at 02:52:02PM +0400, Денис Смирнов wrote:
> >> Я не увидел от тебя ни одного обоснования, почему поиск
> >> зависимостей в контрибах это плохо.
> MS> Потому что это свалка по определению, читай архивы devel@
> MS> -- обсуждалось не раз и не два.
> Что это свалка по-определению -- это понятно. Таки чем плох поиск
> зависимостей? Это способ сделать пакет в меньшей степени свалкой.

Потому что зависимости -- это уют.  Свалка и уют совместимы
слабо, не стоит даже и заморачиваться.

В качестве упражнения можешь попробовать навести порядок в первом
приближении на какой-нибудь подмосковной ;)

(если технически -- то в контрибе могут оказаться совсем разные
вещи, например, мои рубишные скриптики в контрибе etcnet уже,
наверное, вызвали пару ласковых слов при отрывании зависимости
на ruby; а ведь любой такой скрипт _имеет право_ требовать хоть
ядро 2.2, хоть оракл, хоть FlightGear -- но по статусу контриба
разбираться с его нужностью положено человеку, и если что нужное
можно почистить и обобщить -- то ему уже место в -utils, -tools,
самостоятельном проекте/пакете, но не в свалке "на всякий случай)

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

Re: [devel] [RFC] -contrib policy proposal

[led]

Sunday, 21 October 2007 14:54:48 Michael Shigorin написав:
> On Sun, Oct 21, 2007 at 02:52:02PM +0400, Денис Смирнов wrote:
> > >> Я не увидел от тебя ни одного обоснования, почему поиск
> > >> зависимостей в контрибах это плохо.
> >
> > MS> Потому что это свалка по определению, читай архивы devel@
> > MS> -- обсуждалось не раз и не два.
> > Что это свалка по-определению -- это понятно. Таки чем плох поиск
> > зависимостей? Это способ сделать пакет в меньшей степени свалкой.
>
> Потому что зависимости -- это уют.  Свалка и уют совместимы
> слабо, не стоит даже и заморачиваться.
>
> В качестве упражнения можешь попробовать навести порядок в первом
> приближении на какой-нибудь подмосковной ;)
>
> (если технически -- то в контрибе могут оказаться совсем разные
> вещи, например, мои рубишные скриптики в контрибе etcnet уже,
> наверное, вызвали пару ласковых слов при отрывании зависимости
> на ruby; а ведь любой такой скрипт _имеет право_ требовать хоть
> ядро 2.2, хоть оракл, хоть FlightGear -- но по статусу контриба
> разбираться с его нужностью положено человеку, и если что нужное
> можно почистить и обобщить -- то ему уже место в -utils, -tools,
> самостоятельном проекте/пакете, но не в свалке "на всякий случай)

+1
"Свалка contrib" - это ИМХО временное явление. По-хорошему - эту свалку нужно 
потихоньку "разгребать" и прекладывать необходимое в %_bindir и субпакеты 
*-{tools,utils}. Не всегда это, конечно, получается, по крайней мере - не 
сразу :(

___
Led

[devel] [JT] Re: [RFC] -contrib policy proposal

[Michael Shigorin]

On Sun, Oct 21, 2007 at 07:04:16PM +0300, led@altlinux.ru wrote:
> "Свалка contrib" - это ИМХО временное явление. По-хорошему -
> эту свалку нужно потихоньку "разгребать" и прекладывать
> необходимое в %_bindir и субпакеты *-{tools,utils}. Не всегда
> это, конечно, получается, по крайней мере - не сразу :(

Это дело заинтересованных пользователей/разработчиков 
в первую очередь; майнтейнеров -- постольку поскольку,
ну или по мере принадлежности к п.1 IMHO ;)

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