[devel] pkgconfiglib.req

[devel] pkgconfiglib.req

[Alexey M. Tourbin]

Иногда бывает так, что с новым devel-пакетом перестает что-то собираться
из-за добавившихся библиотек для линковки в *.pc файле.  Здесь есть два
подхода.  Первый подход -- это, если добавленные библиотеки на самом
деле излишни, то мы получаем ценную информацию, чтобы дать кому-то
подзатыльник (точнее, чтобы убрать ненужные библиотеки из Libs в новом
пакете).  С другой стороны, раздача подзатыльников методом поломки
репозитария не кажется мне вполне технологичным развлечением.

Второй подход -- это, если добавленные библиотеки на самом деле не
лишние, добить новых *-devel зависимостей на соответствующие пакеты.
Кроме всего прочего, этот подход относительно легко перепоручить
автоматике.

Поэтому предлагаю замыкать зависимости между *-devel пакетами по
содержимому поля Libs в *.pc файлах.

Алгоритм, который реализован ниже, не слишком точно мимикрирует
перебор путей в ld (в частности, *.a библиотеки не просматриваются).
Тем не мене, мне пока не приходит в голову конфигурация, даже, допустим,
патологическая, при которой может получиться неправильный результат.

ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
до тех пор, пока он кому-нибудь не понадобится.

В своей хост-системе я обнаружил 2 *.pc файла из не-devel пакетов,
которые имеют некоторые проблемы при попытке их обработки:

$ rpm -qf /usr/lib/pkgconfig/libgdiplus.pc
libgdiplus-1.2.4-alt1
$ rpm -qf /usr/lib/pkgconfig/avahi-qt3.pc 
libavahi-qt3-0.6.20-alt2
$ 

Некоторые подробности на этот счет приведены ниже.


Changelog since `4.0.4-alt77-67-g63ac11f' follows:
commit 0e085c0a8388be44d06afe1a1f4b88aa8895ad2e
Author: Alexey Tourbin <at@altlinux>
Date:   Tue Aug 28 20:10:35 2007 +0400

    pkgconfiglib.req: new pkgconfig.req mode (makes dependencies on Libs)
    
    This will grab libraries from ^Libs: clause and map each library
    to rpm dependency, which is typically lib*-devel package.
    
    $ grep ^Libs: /usr/lib/pkgconfig/directfb.pc
    Libs: -ldirectfb -lpthread -ldl -lz
    $
    
    It works like this:
    
    $ ln -s pkgconfig.req.in scripts/pkgconfiglib.req.in
    $ scripts/pkgconfiglib.req.in -v /usr/lib/pkgconfig/directfb.pc
    pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libdirectfb.so -> libdirectfb-devel
    libdirectfb-devel
    pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libz.so -> zlib-devel
    zlib-devel
    pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libfusion.so -> libdirectfb-devel
    libdirectfb-devel
    pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libdirect.so -> libdirectfb-devel
    libdirectfb-devel
    pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libpthread.so -> glibc-devel (skip)
    pkgconfiglib.req.in: /usr/lib/pkgconfig/directfb.pc: libdl.so -> glibc-devel (skip)
    $
    
    Some minor problems:
    
    $ scripts/pkgconfiglib.req.in /usr/lib/pkgconfig/*.pc >/dev/null
    pkgconfiglib.req.in: /usr/lib/pkgconfig/avahi-qt3.pc: cannot find libavahi-qt3.so library path (skip)
    pkgconfiglib.req.in: /usr/lib/pkgconfig/libgdiplus.pc: cannot find libexif.so library path (skip)
    pkgconfiglib.req.in: /usr/lib/pkgconfig/valgrind.pc: cannot find libcoregrind.so library path (skip)
    pkgconfiglib.req.in: /usr/lib/pkgconfig/valgrind.pc: cannot find libvex.so library path (skip)
    pkgconfiglib.req.in: /usr/lib/pkgconfig/valgrind.pc: cannot find libgcc.so library path (skip)
    $

Full diff since `4.0.4-alt77-67-g63ac11f' follows:
diff --git a/rpm-4_0.spec b/rpm-4_0.spec
index a7ace2a..c167300 100644
--- a/rpm-4_0.spec
+++ b/rpm-4_0.spec
@@ -474,6 +474,7 @@ fi
 %rpmattr %_rpmlibdir/lib.*
 %rpmattr %_rpmlibdir/pam.*
 %rpmattr %_rpmlibdir/pkgconfig.*
+%rpmattr %_rpmlibdir/pkgconfiglib.*
 %rpmattr %_rpmlibdir/shell.*
 %rpmattr %_rpmlibdir/shebang.*
 %rpmattr %_rpmlibdir/static.*
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index d93d477..e58108a 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -51,4 +51,6 @@ config_SCRIPTS = \
 
 install-data-local:
 	@LN_S@ pkgconfig.req $(DESTDIR)$(configdir)/pkgconfig.prov
+	@LN_S@ pkgconfig.req $(DESTDIR)$(configdir)/pkgconfiglib.req
 	@LN_S@ pkgconfig.req.files $(DESTDIR)$(configdir)/pkgconfig.prov.files
+	@LN_S@ pkgconfig.req.files $(DESTDIR)$(configdir)/pkgconfiglib.req.files
diff --git a/scripts/pkgconfig.req.in b/scripts/pkgconfig.req.in
index 37391d4..95d0210 100755
--- a/scripts/pkgconfig.req.in
+++ b/scripts/pkgconfig.req.in
@@ -58,8 +58,55 @@ PkgconfigProv()
 	done
 }
 
+PkgconfigLibReq()
+{
+	local f="$1" l L; shift
+	l=$(pkg-config --print-errors --libs-only-l "$f") || Fatal "failed to process $f"
+	L=$(pkg-config --print-errors --libs-only-L "$f") || Fatal "failed to process $f"
+	l=$(echo '' $l |sed -e 's/ -l/ /g')
+	L=$(echo '' $L |sed -e 's/ -L/ /g')
+	local lib libdir
+	for lib in $l; do
+		lib=lib$lib.so
+		if [ -n "${RPM_BUILD_ROOT-}" ]; then
+			for libdir in $L "$RPM_LIBDIR"; do
+				libdir=${libdir%/}
+				[ -f "$RPM_BUILD_ROOT$libdir/$lib" ] || continue
+				# The library is under RPM_BUILD_ROOT.
+				# Nothing is required.  Do next lib.
+				Verbose "$f: $lib -> \$RPM_BUILD_ROOT$libdir/$lib (skip)"
+				continue 2
+			done
+		fi
+		for libdir in $L "$RPM_LIBDIR"; do
+			libdir=${libdir%/}
+			[ -f "$libdir/$lib" ] || continue
+			# The library is found in the host system.
+			# Generate rpm dependency and do next lib.
+			local pkg n
+			pkg=$(rpmquery --whatprovides --queryformat='%{NAME}\n' "$libdir/$lib" |sort -u)
+			n=$(set -- $pkg; echo $#)
+			if [ "$pkg" = glibc-devel ]; then
+				Verbose "$f: $lib -> $pkg (skip)"
+			elif [ $n -eq 1 ]; then
+				Verbose "$f: $lib -> $pkg"
+				printf '%s\n' "$pkg"
+			elif [ $n -gt 1 ]; then
+				Info "$f: $libdir/$lib provided by:$(echo '' $pkg)"
+				Info "$f: $lib -> $libdir/$lib (raw, ambiguous)"
+				printf '%s\n' "$libdir/$lib"
+			else
+				Info "$f: cannot map $lib to rpm dependency (skip)"
+			fi
+			continue 2
+		done
+		Info "$f: cannot find $lib library path (skip)"
+	done
+}
+
 case "${0##*/}" in
 	pkgconfig.req*) ArgvFileAction PkgconfigReq "$@" ;;
 	pkgconfig.prov*) ArgvFileAction PkgconfigProv "$@" ;;
+	pkgconfiglib.req*) ArgvFileAction PkgconfigLibReq "$@" ;;
 	*) Fatal "req/prov method not recognized" ;;
 esac

Re: [devel] pkgconfiglib.req

[Alexey Tourbin]

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

On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote:
> Иногда бывает так, что с новым devel-пакетом перестает что-то собираться
> из-за добавившихся библиотек для линковки в *.pc файле.  Здесь есть два
> подхода.  Первый подход -- это, если добавленные библиотеки на самом
> деле излишни, то мы получаем ценную информацию, чтобы дать кому-то
> подзатыльник (точнее, чтобы убрать ненужные библиотеки из Libs в новом
> пакете).  С другой стороны, раздача подзатыльников методом поломки
> репозитария не кажется мне вполне технологичным развлечением.
> 
> Второй подход -- это, если добавленные библиотеки на самом деле не
> лишние, добить новых *-devel зависимостей на соответствующие пакеты.
> Кроме всего прочего, этот подход относительно легко перепоручить
> автоматике.
> 
> Поэтому предлагаю замыкать зависимости между *-devel пакетами по
> содержимому поля Libs в *.pc файлах.

Взялся проанализировать содержимое noarch пакетов.

$ pwd
/ALT/Sisyphus/files/noarch/RPMS
$ rpmfile . |grep $'\\.pc\t' 
gnome-doc-utils-0.10.3-alt2.noarch.rpm  /usr/share/pkgconfig/gnome-doc-utils.pc 100644  ASCII text
gnome-doc-utils-0.10.3-alt2.noarch.rpm  /usr/share/pkgconfig/xml2po.pc  100644  ASCII text
gnome-icon-theme-2.18.0-alt1.noarch.rpm /usr/share/pkgconfig/gnome-icon-theme.pc        100644  ASCII English text
gnome-mime-data-2.18.0-alt1.noarch.rpm  /usr/share/pkgconfig/gnome-mime-data-2.0.pc     100644  ASCII text
gtk-doc-1.8-alt1.noarch.rpm     /usr/share/pkgconfig/gtk-doc.pc 100644  ASCII text
i386-mingw32msvc-SDL-devel-1.2.11-alt1.noarch.rpm       /usr/i386-mingw32msvc/lib/pkgconfig/sdl.pc      100644  ASCII text
i386-mingw32msvc-libogg-devel-1.1.2-alt3.noarch.rpm     /usr/i386-mingw32msvc/lib/pkgconfig/ogg.pc      100644  ASCII text
i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm     /usr/lib/pkgconfig/i386-mingw32msvc-libpng.pc   120777  symbolic link to `i386-mingw32msvc-libpng12.pc'
i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm     /usr/lib/pkgconfig/i386-mingw32msvc-libpng12.pc 100644  ASCII text
i386-mingw32msvc-libssl-devel-0.9.8a-alt1.noarch.rpm    /usr/i386-mingw32msvc/lib/pkgconfig/libcrypto.pc        100644  ASCII text
i386-mingw32msvc-libssl-devel-0.9.8a-alt1.noarch.rpm    /usr/i386-mingw32msvc/lib/pkgconfig/libssl.pc   100644  ASCII text
i386-mingw32msvc-libssl-devel-0.9.8a-alt1.noarch.rpm    /usr/i386-mingw32msvc/lib/pkgconfig/openssl.pc  100644  ASCII text
i386-mingw32msvc-libvorbis-devel-1.1.0-alt2.noarch.rpm  /usr/i386-mingw32msvc/lib/pkgconfig/vorbis.pc   100644  ASCII English text
i386-mingw32msvc-libvorbis-devel-1.1.0-alt2.noarch.rpm  /usr/i386-mingw32msvc/lib/pkgconfig/vorbisenc.pc        100644  ASCII text
i386-mingw32msvc-libvorbis-devel-1.1.0-alt2.noarch.rpm  /usr/i386-mingw32msvc/lib/pkgconfig/vorbisfile.pc       100644  ASCII text
i386-mingw32msvc-libxml2-devel-2.6.20-alt1.noarch.rpm   /usr/i386-mingw32msvc/lib/pkgconfig/libxml-2.0.pc       100644  ASCII text
i386-mingw32msvc-libxslt-devel-1.1.14-alt1.noarch.rpm   /usr/i386-mingw32msvc/lib/pkgconfig/libexslt.pc 100644  ASCII text
i386-mingw32msvc-libxslt-devel-1.1.14-alt1.noarch.rpm   /usr/i386-mingw32msvc/lib/pkgconfig/libxslt.pc  100644  ASCII text
icon-naming-utils-0.8.2-alt1.noarch.rpm /usr/share/pkgconfig/icon-naming-utils.pc       100644  ASCII English text
iso-codes-devel-0.58-alt1.noarch.rpm    /usr/share/pkgconfig/iso-codes.pc       100644  ASCII text
libice-sharp-devel-3.2.0-alt1.noarch.rpm        /usr/lib/pkgconfig/glacier2cs.pc        100644  ASCII text
libice-sharp-devel-3.2.0-alt1.noarch.rpm        /usr/lib/pkgconfig/iceboxcs.pc  100644  ASCII text
libice-sharp-devel-3.2.0-alt1.noarch.rpm        /usr/lib/pkgconfig/icecs.pc     100644  ASCII text
libice-sharp-devel-3.2.0-alt1.noarch.rpm        /usr/lib/pkgconfig/icegridcs.pc 100644  ASCII text
libice-sharp-devel-3.2.0-alt1.noarch.rpm        /usr/lib/pkgconfig/icepatch2cs.pc       100644  ASCII text
libice-sharp-devel-3.2.0-alt1.noarch.rpm        /usr/lib/pkgconfig/icestormcs.pc        100644  ASCII text
xorg-x11-bitmaps-1.0.1-alt2.1.noarch.rpm        /usr/share/pkgconfig/xbitmaps.pc        100644  ASCII text
$

Хочу заметить, что в pkgconfig.req.files отбираются только файлы
в %_libdir/pkgconfig и /usr/share/pkgconfig, так что
/usr/i386-mingw32msvc/**/*.pc не создаст ложных зависимостей,
эти файлы просто не будут обрабатываться.

ОБРАТИМ ВНИМАНИЕ НА ИСПОЛЬЗОВАНИЕ /usr/lib/pkgconfig/ в noarch пакетах.
БУДЕТ ЛИ ЭТО РАБОТАТЬ НА x86_64?

[at@hint1 ~]$ hsh --init
[at@hint1 ~]$ hsh-install libice-sharp-devel
...
[at@hint1 ~]$ hsh-shell --rooter
[root@hint1 .in]# grep -i ^name /usr/lib/pkgconfig/icestormcs.pc
name = icestormcs
Name: ${name}
[root@hint1 .in]# pkg-config --print-errors --modversion icestormcs
Package icestormcs was not found in the pkg-config search path.
Perhaps you should add the directory containing `icestormcs.pc'
to the PKG_CONFIG_PATH environment variable
No package 'icestormcs' found
[root@hint1 .in]# mv /usr/lib/pkgconfig/*.pc /usr/lib64/pkgconfig/
[root@hint1 .in]# pkg-config --print-errors --modversion icestormcs
3.2.0
[root@hint1 .in]# 

ВОТ ТАК ТАК!  В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig!
Прошу maintainer'а pkg-config прокомментировать эту ситуацию.

Теперь делаю такой финт ушами чтобы посмотреть что лежит внутри
этих *.pc файлов:

$ rpmfile . |grep $'\\.pc\t' |cut -f1 |sort -u |xargs -n1 -I RPM rpmpeek RPM find ./usr -name '*.pc' -exec egrep -iH '^(req|libs)' {} \;
./usr/share/pkgconfig/xml2po.pc:Requires: libxml-2.0
./usr/share/pkgconfig/gnome-icon-theme.pc:Requires:
./usr/share/pkgconfig/gnome-icon-theme.pc:Libs:
./usr/share/pkgconfig/gnome-mime-data-2.0.pc:Requires:
./usr/share/pkgconfig/gnome-mime-data-2.0.pc:Libs:
./usr/i386-mingw32msvc/lib/pkgconfig/sdl.pc:Requires:
./usr/i386-mingw32msvc/lib/pkgconfig/sdl.pc:Libs: -L${libdir}  -lmingw32 -lSDLmain -lSDL  -mwindows
./usr/i386-mingw32msvc/lib/pkgconfig/ogg.pc:Requires:
./usr/i386-mingw32msvc/lib/pkgconfig/ogg.pc:Libs: -L${libdir} -logg
./usr/lib/pkgconfig/i386-mingw32msvc-libpng12.pc:Libs: -lpng12
./usr/lib/pkgconfig/i386-mingw32msvc-libpng.pc:Libs: -lpng12
./usr/i386-mingw32msvc/lib/pkgconfig/openssl.pc:Requires:
./usr/i386-mingw32msvc/lib/pkgconfig/openssl.pc:Libs: -L${libdir} -lssl -lcrypto -lwsock32 -lgdi32 -lz
./usr/i386-mingw32msvc/lib/pkgconfig/libssl.pc:Requires:
./usr/i386-mingw32msvc/lib/pkgconfig/libssl.pc:Libs: -L${libdir} -lssl -lcrypto -lwsock32 -lgdi32 -lz
./usr/i386-mingw32msvc/lib/pkgconfig/libcrypto.pc:Requires:
./usr/i386-mingw32msvc/lib/pkgconfig/libcrypto.pc:Libs: -L${libdir} -lcrypto -lwsock32 -lgdi32 -lz
./usr/i386-mingw32msvc/lib/pkgconfig/vorbisfile.pc:Requires: vorbis ogg
./usr/i386-mingw32msvc/lib/pkgconfig/vorbisfile.pc:Libs: -L${libdir} -lvorbisfile
./usr/i386-mingw32msvc/lib/pkgconfig/vorbisenc.pc:Requires: vorbis
./usr/i386-mingw32msvc/lib/pkgconfig/vorbisenc.pc:Libs: -L${libdir} -lvorbisenc
./usr/i386-mingw32msvc/lib/pkgconfig/vorbis.pc:Requires: ogg
./usr/i386-mingw32msvc/lib/pkgconfig/vorbis.pc:Libs: -L${libdir} -lvorbis
./usr/i386-mingw32msvc/lib/pkgconfig/libxml-2.0.pc:Requires:
./usr/i386-mingw32msvc/lib/pkgconfig/libxml-2.0.pc:Libs: -L${libdir} -lxml2  -lz  -liconv
./usr/i386-mingw32msvc/lib/pkgconfig/libxslt.pc:Requires: libxml-2.0
./usr/i386-mingw32msvc/lib/pkgconfig/libxslt.pc:Libs: -L${libdir} -lxslt  -L/usr/i386-mingw32msvc/lib -lxml2 -lz -liconv
./usr/i386-mingw32msvc/lib/pkgconfig/libexslt.pc:Requires: libxml-2.0
./usr/i386-mingw32msvc/lib/pkgconfig/libexslt.pc:Libs: -L${libdir} -lexslt -lxslt  -L/usr/i386-mingw32msvc/lib -lxml2 -lz -liconv
./usr/share/pkgconfig/icon-naming-utils.pc:Requires:
./usr/share/pkgconfig/icon-naming-utils.pc:Libs:
./usr/lib/pkgconfig/icestormcs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll
./usr/lib/pkgconfig/icestormcs.pc:Requires: icecs = ${version}
./usr/lib/pkgconfig/icepatch2cs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll
./usr/lib/pkgconfig/icepatch2cs.pc:Requires: icecs = ${version}
./usr/lib/pkgconfig/icegridcs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll
./usr/lib/pkgconfig/icegridcs.pc:Requires: icecs = ${version}
./usr/lib/pkgconfig/icecs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll
./usr/lib/pkgconfig/iceboxcs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll
./usr/lib/pkgconfig/iceboxcs.pc:Requires: icecs = ${version}
./usr/lib/pkgconfig/glacier2cs.pc:Libs: -r:${mono_root}/lib/mono/gac/${name}/${version}.0__1f998c50fec78381/${name}.dll
./usr/lib/pkgconfig/glacier2cs.pc:Requires: icecs = ${version}
./usr/share/pkgconfig/xbitmaps.pc:Libs:
$

К счастью, библиотек нигде нет (кроме i386-mingw32msvc и mono).
Однако интересно, что xml2po.pc (gnome-doc-utils) требует libxml-2.0.
Это как раз та проблема семантики pkg-config зависимостей, которую
я недвано упоминал.  По видимому, смысл в том, что gnome-doc-utils
требует пакет xml-utils (который собирается из libxml2).  Но, таким
образом, ЗАВИСИМОСТИ pkg-config НЕ ЯВЛЯЕТСЯ чисто devel ЗАВИСИМОСТЯМИ
для сборки других пакетов.  То есть это плохая, допотопная система
зависимостей, в которой BuildRequires, Requires: lib%name.so.0 и
Requires: lib%name-devel свалено всё в одну кучу.  Единственный
приемлемый способ отражать эту систему зависимостей в rpm, это
переместить все *.pc файлы в *-devel пакеты.  Но и в *-devel
пакетах в Libs находятся левые библиотеки, которые использовались
только для сборки самого этого пакта.  Такие библиотеки нужно переносить
в Libs.private.

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

Re: [devel] /usr/lib/pkgconfig vs noarch

[Dmitry V. Levin]

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

On Tue, Aug 28, 2007 at 11:55:29PM +0400, Alexey Tourbin wrote:
[...]
> ОБРАТИМ ВНИМАНИЕ НА ИСПОЛЬЗОВАНИЕ /usr/lib/pkgconfig/ в noarch пакетах.
> БУДЕТ ЛИ ЭТО РАБОТАТЬ НА x86_64?

Нет, не будет, поскольку /usr/lib/pkgconfig не входит в список поиска на
x86_64, см. pkg-config(1) на тему PKG_CONFIG_PATH.

[...]
> ВОТ ТАК ТАК!  В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig!

+1

> Прошу maintainer'а pkg-config прокомментировать эту ситуацию.

Можно смело добавлять соответствующую проверку в sisyphus_check/rpm-build.
Патчи приветствуются.


-- 
ldv

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

Re: [devel] pkgconfiglib.req

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [070828 23:57]:
> i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm     /usr/lib/pkgconfig/i386-mingw32msvc-libpng.pc   120777  symbolic link to `i386-mingw32msvc-libpng12.pc'
> i386-mingw32msvc-libpng-devel-1.2.8-alt2.noarch.rpm     /usr/lib/pkgconfig/i386-mingw32msvc-libpng12.pc 100644  ASCII text
Это бага.  Не должно оно лежать в /usr/lib/pkgconfig/...

-- 
Regards,
Sir Raorn.

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

Re: [devel] pkgconfiglib.req

[Alexey Rusakov]

On Tue, 28 Aug 2007 23:55:29 +0400
Alexey Tourbin wrote:

> ВОТ ТАК ТАК!  В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig!
Совершенно справедливо. *.pc файлы для noarch пакетов
кладутся в /usr/share/pkgconfig как архитектурно-независимое место.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

Re: [devel] /usr/lib/pkgconfig vs noarch

[Alexey Tourbin]

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

On Wed, Aug 29, 2007 at 12:12:18AM +0400, Dmitry V. Levin wrote:
> > ВОТ ТАК ТАК!  В noarch ПАКЕТАХ НЕ ДОЛЖНО БЫТЬ /usr/lib/pkgconfig!
> 
> +1
> 
> > Прошу maintainer'а pkg-config прокомментировать эту ситуацию.
> 
> Можно смело добавлять соответствующую проверку в sisyphus_check/rpm-build.
> Патчи приветствуются.

А вот смотри-ка.  Я пересобрал libice-sharp на x86_64 и у него
это дело поставилось в /usr/lib64/pkgconfig/.  Из этого простого
обстоятельства вытекает условие: если noarch пакет на i586 и x86_64
в результате собрался с отличающимся списком файлов (в данном случае
с /usr/lib на i586 и /usr/lib64 на x86_64), то он должен получить
reject от incoming'а.  Эта нехитрая техника решает ЦЕЛЫЙ КЛАСС ПРОБЛЕМ
c noarch-пакетам.

МЫ НЕ МОЖЕМ ДОБАВИТЬ в sisyphus_check ВСЁ ЗНАНИЕ о том, какие именно
(недопустимые) отличия могут появиться при сборке noarch пакетов на
разных архитектурах.  Мы не можем ждать милостей от природы, так проще
взять и сравнить!  А природа проста и не роскошествует излишними
причинами вещей. :)  Раз отличаются значит reject.

Я посмотрел документацию legion'а к giter-factory, что-то меня это
нисколько не обнадёжило насчет возможности внедрения первичного
тестирования перед публикацией.  Скорее разочаровало.

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

Re: [devel] /usr/lib/pkgconfig vs noarch

[Alexey Tourbin]

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

On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote:
> А вот смотри-ка.  Я пересобрал libice-sharp на x86_64 и у него
> это дело поставилось в /usr/lib64/pkgconfig/.  Из этого простого
> обстоятельства вытекает условие: если noarch пакет на i586 и x86_64
> в результате собрался с отличающимся списком файлов (в данном случае
> с /usr/lib на i586 и /usr/lib64 на x86_64), то он должен получить
> reject от incoming'а.  Эта нехитрая техника решает ЦЕЛЫЙ КЛАСС ПРОБЛЕМ
> c noarch-пакетам.

Кстати, если сравнивать ещё и зависимости, то это решает также проблему,
когда в noarch пакетах что-то компилируется, а noarch стоит по недосмотру.
Псокольку бинарные зависимости отличаются на '(64bit)'.

Собрался сделать новую проверку в sisyphus_check и теперь даже не знаю
делать или нет.  На другом уровне всё решается гораздо проще.

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

[devel] sisyphus_check noarch

[Alexey Tourbin]

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

On Wed, Aug 29, 2007 at 01:07:23AM +0400, Alexey Tourbin wrote:
> Собрался сделать новую проверку в sisyphus_check и теперь даже не знаю
> делать или нет.  На другом уровне всё решается гораздо проще.

Предлагаю сделать две проверки:

check_arch_paths -- на non-64 архитектуре не может быть /usr/lib64/*.

check_arch_deps -- на noarch архитектуре в Requires не может быть
rtld(GNU_HASH).

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

Теперь посмотрим, что произойдёт с noarch пакетом у которого там это
дело pkg-config.  Если incominger собирает noarch пакеты как на i586,
так и на x86_64, то на x86_64 проверка check_arch_paths обломится,
потому что arch=noarch.  Значит, "накрытие" есть.  Теперь, однако, опять
всё упирается в логику работы incoming'а.  Пропустит ли он noarch пакет,
который собрался на i586 и не собрался на x86_64?

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

Re: [devel] pkgconfiglib.req

[Igor Zubkov]

2007/8/28, Alexey M. Tourbin:
> ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> до тех пор, пока он кому-нибудь не понадобится.

А кроме того, *.pc файл в пакете приводит к излишним зависимостям в
этом пакете. Как пример, python-module-dbus и python-module-gst. Оба
уже пофикшены.

-- 
icesik

Re: [devel] /usr/lib/pkgconfig vs noarch

[Dmitry V. Levin]

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

On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote:
[...]
> Я посмотрел документацию legion'а к giter-factory, что-то меня это
> нисколько не обнадёжило насчет возможности внедрения первичного
> тестирования перед публикацией.  Скорее разочаровало.

Что именно разочаровало?


-- 
ldv

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

[devel] giter-factory

[Alexey Tourbin]

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

On Wed, Aug 29, 2007 at 07:56:32PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote:
> [...]
> > Я посмотрел документацию legion'а к giter-factory, что-то меня это
> > нисколько не обнадёжило насчет возможности внедрения первичного
> > тестирования перед публикацией.  Скорее разочаровало.
> 
> Что именно разочаровало?

Цитата из giter-factory/doc/info.tex:

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

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

	После удачной пересборки пакет сразу же публикуется. Следующие
	пакеты из очереди пересобираются уже на новом публичном
	репозитории.

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

Преимущество тут только в том, что пересборка/публикация происходит
очень быстро, но это просто сопособ очень быстро всё пустить под откос.
Даже сейчас "ответственный товарищ, формирующий сизиф", играет
созидательную роль, не пропуская (hopefully) вручную "очень плохие
пакеты".  Просто исключить эту роль, не дав ничего взамен, нельзя.

Мое альтернативное видение такое: прошёл пакет и пересобрался.
Формируется новый временный сизиф с этим пакетом, и на этом временном
сизифе выполняется ряд проверок.  Если все проверки прошли успешно,
то временный сизиф становится текущим ("коммит"), и очередь
продвигается.  Если же некоторые проверки не прошли, то пакт ставится
на подтверждение вручную.  Подтвердить или отменить может а) maintainer
б) ответственный товарищ в) чьи пакеты сломались.  В детали полтики
подтверждения и отмены пока вдаваться не буду.

Если предусмотрена схема с подтверждением вручную, тогда вся идея
"наивной сериализаци" летит в тартарары.  Подтверждение может поступить
через час, через два или три, через день, а может и не поступить вовсе
(имплицитная отмена).  Скорость продвижения очереди не должна
зависеть от человеческого фактора, которым является продвижение вручную.
Если пакет ставится не подтверждение, то создается "временный бранч"
с "временным сизифом".  Очередь продвигается с предыдущего состояния,
то есть "коммита" в мэйнлайн не происходит.  Если приходит подтверждение
вручную, то нужно сделать "мёрж" между временным сизифом с проблемным
пакетом и текущим хедом мэйнлайна.  Получается прозрачная аналогия
с гитовскими коммитами:
	
	 /M merged pkg2 with pkg4
	* | confirmed pkg2
	| * pkg4 success
	* | pkg3 problems: please confirm
	 `* pkg2 success
	  * pkg1 success

В чем состоит мёрж я сейчас объяснять не буду.  Если прошло достаточно
много времени, то мёрж уже может стать невозможным.  В таком случае pkg2
"ребейсится" на pkg4 (текущий хед мэйнлайна) и его сборка/тестирование
проходит заново.  Если характеристики после ребейса репозитария получаются
не хуже, чем характеристики репозитария до ребейса, то подтверждение
считатется действительным.  В противном случае генерируется новый запрос
на подтверждение.

Такие пироги.

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

Re: [devel] giter-factory

[Dmitry V. Levin]

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

On Wed, Aug 29, 2007 at 09:05:12PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 29, 2007 at 07:56:32PM +0400, Dmitry V. Levin wrote:
> > On Wed, Aug 29, 2007 at 12:47:25AM +0400, Alexey Tourbin wrote:
> > [...]
> > > Я посмотрел документацию legion'а к giter-factory, что-то меня это
> > > нисколько не обнадёжило насчет возможности внедрения первичного
> > > тестирования перед публикацией.  Скорее разочаровало.
> > 
> > Что именно разочаровало?
> 
> Цитата из giter-factory/doc/info.tex:
> 
> 	Как только указание получено, репозиторий встаёт в очередь на
> 	сборку. Все запросы от разных пользователей сериализуются по
> 	времени.
> 
> 	Процесс пересборки параллелится по архитектурам, но не по
> 	положению в очереди. Такой подход позволяет просто сформировать
> 	порядок сборки зависимых пакетов.
> 
> 	После удачной пересборки пакет сразу же публикуется. Следующие
> 	пакеты из очереди пересобираются уже на новом публичном
> 	репозитории.
> 
> Это я называю "наивная сериализация".  Прошёл "очень плохой пакет"
> и сразу же опубликовался, полсизифа перестало собираться; отозвать
> сборку задним числом уже нельзя.
> 
> Преимущество тут только в том, что пересборка/публикация происходит
> очень быстро, но это просто сопособ очень быстро всё пустить под откос.
> Даже сейчас "ответственный товарищ, формирующий сизиф", играет
> созидательную роль, не пропуская (hopefully) вручную "очень плохие
> пакеты".  Просто исключить эту роль, не дав ничего взамен, нельзя.
> 
> Мое альтернативное видение такое: прошёл пакет и пересобрался.
> Формируется новый временный сизиф с этим пакетом, и на этом временном
> сизифе выполняется ряд проверок.  Если все проверки прошли успешно,
> то временный сизиф становится текущим ("коммит"), и очередь
> продвигается.  Если же некоторые проверки не прошли, то пакт ставится
> на подтверждение вручную.  Подтвердить или отменить может а) maintainer
> б) ответственный товарищ в) чьи пакеты сломались.  В детали полтики
> подтверждения и отмены пока вдаваться не буду.
> 
> Если предусмотрена схема с подтверждением вручную, тогда вся идея
> "наивной сериализаци" летит в тартарары.  Подтверждение может поступить
> через час, через два или три, через день, а может и не поступить вовсе
> (имплицитная отмена).  Скорость продвижения очереди не должна
> зависеть от человеческого фактора, которым является продвижение вручную.
> Если пакет ставится не подтверждение, то создается "временный бранч"
> с "временным сизифом".  Очередь продвигается с предыдущего состояния,
> то есть "коммита" в мэйнлайн не происходит.  Если приходит подтверждение
> вручную, то нужно сделать "мёрж" между временным сизифом с проблемным
> пакетом и текущим хедом мэйнлайна.  Получается прозрачная аналогия
> с гитовскими коммитами:
> 	
> 	 /M merged pkg2 with pkg4
> 	* | confirmed pkg2
> 	| * pkg4 success
> 	* | pkg3 problems: please confirm
> 	 `* pkg2 success
> 	  * pkg1 success
> 
> В чем состоит мёрж я сейчас объяснять не буду.  Если прошло достаточно
> много времени, то мёрж уже может стать невозможным.  В таком случае pkg2
> "ребейсится" на pkg4 (текущий хед мэйнлайна) и его сборка/тестирование
> проходит заново.  Если характеристики после ребейса репозитария получаются
> не хуже, чем характеристики репозитария до ребейса, то подтверждение
> считатется действительным.  В противном случае генерируется новый запрос
> на подтверждение.
> 
> Такие пироги.

Сколько у тебя уйдёт времени, чтобы всё это реализовать?


-- 
ldv

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

Re: [devel] giter-factory

[Alexey Tourbin]

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

On Wed, Aug 29, 2007 at 11:29:42PM +0400, Dmitry V. Levin wrote:
> > Такие пироги.
> Сколько у тебя уйдёт времени, чтобы всё это реализовать?

Это ещё не продумано до конца.
Не знаю.  Буду дальше думать.

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

Re: [devel] giter-factory

[Alexey Tourbin]

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

On Wed, Aug 29, 2007 at 11:37:07PM +0400, Alexey Tourbin wrote:
> On Wed, Aug 29, 2007 at 11:29:42PM +0400, Dmitry V. Levin wrote:
> > > Такие пироги.
> > Сколько у тебя уйдёт времени, чтобы всё это реализовать?
> 
> Это ещё не продумано до конца.
> Не знаю.  Буду дальше думать.

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

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

Я мыслю в следующих категориях.  На вход пришел src.rpm пакет.
На выходе мы получаем либо новое состояние сизифа, либо отлуп
maintainer'у (при некоем запоминании состояния для последующего
подтверждения).

Соответственно, задачу girar я представляю себе так: проверить
репозитарий и сформировать trusted src.rpm с валидным полем Packager;
либо дать отлуп прямо здесь.

Итого, на входе есть src.rpm пакет.  У меня нарисовался следующий
фрагментарный "псевдо-шелл" код, который отчасти проясняет, "чего
мы хотим".  Его нужно читать снизу вверх.

#!/bin/sh

exit_hander()
{
	sisyphus_unlock
}

srpm_check_version()
{
	srpm_find_sisyphus_version
	if srpm_found_sisyphus_version; then
		srpm_ensure_newer_version
	fi
}

srpm_build()
{
	parallel srpm_build_arch `all_arches`
	srpm_built_ok `primary_arches`
	srpm_check_if_noarch
}

srpm_test_arch_unmets()
{
	dump_sisyphus_unmets
	dump_my_sisyphus_unmets
	check_new_unmets
}

srpm_test_arch()
{
	make_my_arch_sisyphus
	srpm_test_arch_unmets
}

srpm_test()
{
	parallel srpm_test_arch `primary_arches`
}

srpm_init
sisyphus_lock_r
srpm_check_acl
srpm_check_verison
srpm_build
srpm_test
sisypuhs_lock_w
srpm_commit

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

Re: [devel] giter-factory

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 01:02:39AM +0400, Alexey Tourbin wrote:
[...]
> Соответственно, задачу girar я представляю себе так: проверить
> репозитарий и сформировать trusted src.rpm с валидным полем Packager;
> либо дать отлуп прямо здесь.
> 
> Итого, на входе есть src.rpm пакет.

А зачем нужен этот trusted src.rpm?
Я полагал, что без него можно обойтись.


-- 
ldv

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

Re: [devel] giter-factory

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 01:11:32AM +0400, Dmitry V. Levin wrote:
> On Thu, Aug 30, 2007 at 01:02:39AM +0400, Alexey Tourbin wrote:
> [...]
> > Соответственно, задачу girar я представляю себе так: проверить
> > репозитарий и сформировать trusted src.rpm с валидным полем Packager;
> > либо дать отлуп прямо здесь.
> > 
> > Итого, на входе есть src.rpm пакет.
> 
> А зачем нужен этот trusted src.rpm?
> Я полагал, что без него можно обойтись.

Тестирование пересборкой полагается на то, что можно очень быстро узнать
BuildRequires зависимости всех src.rpm пакетов в текущем сизифе.

То есть вопрос такой: есть один или несколько новых
*-%version-%release.%arch.rpm пакетов.  Что нужно пересобрать?
Если есть готовые src.rpm пакеты, то мы делаем сначала rpm -qpR
(в оптимизированном цикле) и извлекаем BuildRequires; а потом
делаем --print-uris (в оптимизированном цикле) и получаем
для каких src.rpm пакетов в билдрут встает один из новых пакетов
*-%version-%release.%arch.rpm.

Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую
процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет
и дальше уже можно узнать его BuildRequires зависимости, как раньше.

Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm
пакета не слишком сильно меняются в зависимости от среды, в которой был
выполнен rpm -bs.  То есть, не на столько сильно, чтобы кардинально
менять список пакетов в билдруте при "незначительном" изменении
репозитария.

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

Re: [devel] giter-factory

[Dmitry V. Levin]

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

On Thu, Aug 30, 2007 at 01:47:01AM +0400, Alexey Tourbin wrote:
> On Thu, Aug 30, 2007 at 01:11:32AM +0400, Dmitry V. Levin wrote:
> > On Thu, Aug 30, 2007 at 01:02:39AM +0400, Alexey Tourbin wrote:
> > [...]
> > > Соответственно, задачу girar я представляю себе так: проверить
> > > репозитарий и сформировать trusted src.rpm с валидным полем Packager;
> > > либо дать отлуп прямо здесь.
> > > 
> > > Итого, на входе есть src.rpm пакет.
> > 
> > А зачем нужен этот trusted src.rpm?
> > Я полагал, что без него можно обойтись.
> 
> Тестирование пересборкой полагается на то, что можно очень быстро узнать
> BuildRequires зависимости всех src.rpm пакетов в текущем сизифе.
>
> То есть вопрос такой: есть один или несколько новых
> *-%version-%release.%arch.rpm пакетов.  Что нужно пересобрать?
> Если есть готовые src.rpm пакеты, то мы делаем сначала rpm -qpR
> (в оптимизированном цикле) и извлекаем BuildRequires; а потом
> делаем --print-uris (в оптимизированном цикле) и получаем
> для каких src.rpm пакетов в билдрут встает один из новых пакетов
> *-%version-%release.%arch.rpm.
> 
> Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую
> процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет
> и дальше уже можно узнать его BuildRequires зависимости, как раньше.

Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет.
Т.е. в данном случае srpm-пакет есть.
Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся.

> Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm
> пакета не слишком сильно меняются в зависимости от среды, в которой был
> выполнен rpm -bs.  То есть, не на столько сильно, чтобы кардинально
> менять список пакетов в билдруте при "незначительном" изменении
> репозитария.

Как правило, мы можем на это рассчитывать, не так ли?


-- 
ldv

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

Re: [devel] giter-factory

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 01:55:53AM +0400, Dmitry V. Levin wrote:
> > Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую
> > процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет
> > и дальше уже можно узнать его BuildRequires зависимости, как раньше.
> 
> Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет.
> Т.е. в данном случае srpm-пакет есть.
> Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся.

Мне так неудобно думать. :)  "Собрался src.rpm пакет в самом конце"
это слишком нетрадиционно.  Нужно либо целиком отказываться от src.rpm
пакетов как класса, либо (с точностью до 1-1 соответствия) допускать,
что src.rpm есть на входе.

> > Здесь есть неявная пресуппозиция, что BuildRequires зависимости src.rpm
> > пакета не слишком сильно меняются в зависимости от среды, в которой был
> > выполнен rpm -bs.  То есть, не на столько сильно, чтобы кардинально
> > менять список пакетов в билдруте при "незначительном" изменении
> > репозитария.
> Как правило, мы можем на это рассчитывать, не так ли?

Мы должны рассчитывать, что BuildRequires зависимости src.rpm пакета
фиксированы с точностью до версий в пределах архитектуры.

К примеру, зависимость BuildRequires: apache2 >= %apache2_version
является в этом отношении допустимой.  То есть при прохождении новой
версии пакета apache2 билдрут изменится в части подпакетов apache2,
то есть мы обнаруживаем что пакет с таким BuildRequires подлежит
пересборке.

BuildRequires зависимости в пределах архитектуры означают что
напр. можно писать

%ifarch arm
%def_without not_yet_package
%else
%def_with not_yet_package
BuildRequires: not_yet_package
%endif

Это уже означает отказ от src.rpm пакетов, потому что их зависимости
отличаются на разных архитектурах; но констрейнты о которых я говорю
сохраняются.

Недопустимыми BuildRequiers зависимостями являются зависимости типа
BuildRequires: %(rpm -qR libxml2)
BuildRequires: %([ $RANDOM -lt 32 ] && echo foo || echo libbar-devel)

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

Короче, при полном отказе от src.rpm пакетов можно per-arch кешировать
некоторую часть его хедера.

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

Re: [devel] giter-factory

[Kirill A. Shutemov]

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

On [Thu, 30.08.2007 02:26], Alexey Tourbin wrote:

[...]

> %ifarch arm

%ifarch %arm

> %def_without not_yet_package
> %else
> %def_with not_yet_package
> BuildRequires: not_yet_package
> %endif

[...]

> Короче, при полном отказе от src.rpm пакетов можно per-arch кешировать
> некоторую часть его хедера.

nosrc.rpm ?

-- 
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] giter-factory

[Kirill A. Shutemov]

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

On [Thu, 30.08.2007 01:02], Alexey Tourbin wrote:
> Предлагаю начать обмен мнениями с того, чтобы уточнить, чего мы хотим, и
> детализировать это достаточно четко, но не доходя до особенностей
> реализации, т.е. не доходя до анатомии шелл-кода в виде грепов и т.д.

Лично мне хотелось бы децентрализации сборки. Хотя бы per arch.
Это помогло бы мне поддерживать репозиторий под ARM до того как он будет
включён в Сизиф.
Я вижу это как получение команд на сборку через почту.

-- 
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] /usr/lib/pkgconfig vs noarch

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

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

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

AT> Кстати, если сравнивать ещё и зависимости, то это решает также проблему,
AT> когда в noarch пакетах что-то компилируется, а noarch стоит по недосмотру.
AT> Псокольку бинарные зависимости отличаются на '(64bit)'.

Я правильно понимаю что у noarch пакета в принципе не должно быть
зависимости на что-либо (64bit), ибо он должен ставиться хоть на arm, хоть
на микрокалькулятор?

В этом случае можно обойтись без сравнения -- если noarch пакет при сборке
на x86_64 имеет такую зависимость, он неправильный.

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

http://freesource.info
----------------------------------------------------------------------------
>subversion-1.1.2-alt2
постараюсь в ближайшее время найти это самое время и залить 1.1.3
		-- svd in devel@

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

Re: [devel] giter-factory

[Alexey Tourbin]

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

On Thu, Aug 30, 2007 at 01:55:53AM +0400, Dmitry V. Levin wrote:
> > Если же у нас нет src.rpm пакетов, тогда нужно запускать очень дорогую
> > процедуру: для каждого gear-репозитария типа сформировать src.rpm пакет
> > и дальше уже можно узнать его BuildRequires зависимости, как раньше.
> 
> Если пакет попал в Сизиф, то был собран и хранится его srpm-пакет.
> Т.е. в данном случае srpm-пакет есть.
> Но у собираемого пакета srpm-пакета нет до тех пор, пока он не соберётся.

А если у src.rpm пакета получаются разные BuildRequires в зависимости
от архитектуры?  Или в зависимости от флагов --with/--without?
Насколько я понимаю, это один из факторов в пользу отказа от src.rpm
как первичной формы публикации исходников.  А в случае с gear получается
более сложное преобразование gear -> pkg.tar -> src.rpm, где последний
является уже продуктом нетривиальных вычислений.

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

В любом случае, если src.rpm существенно отличается при сборке на разных
платформах или в зависимости от ещё каких-то обстоятельств, то результат
является по сути непубликуемым.  Какой из них публиковать?  Природа
проста: "плавающий" результат ненадёжен публикации не подлежит.

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

Re: [devel] giter-factory

[Michael Shigorin]

On Wed, Aug 29, 2007 at 09:05:12PM +0400, Alexey Tourbin wrote:
> 	После удачной пересборки пакет сразу же публикуется. Следующие
> 	пакеты из очереди пересобираются уже на новом публичном
> 	репозитории.
> 
> Это я называю "наивная сериализация".  Прошёл "очень плохой пакет"
> и сразу же опубликовался, полсизифа перестало собираться; отозвать
> сборку задним числом уже нельзя.

И ведь сколько переливается про "карманы", и ведь автор sandman
вполне досягаем...

> Преимущество тут только в том, что пересборка/публикация происходит
> очень быстро, но это просто сопособ очень быстро всё пустить под откос.
> Даже сейчас "ответственный товарищ, формирующий сизиф", играет
> созидательную роль, не пропуская (hopefully) вручную "очень плохие
> пакеты".  Просто исключить эту роль, не дав ничего взамен, нельзя.

2 legion: примерно об этом и на конференции пытался сказать, 
да и при обсуждении _осмысленности_ сверхзвуковой _публикации_.

> Мое альтернативное видение такое: прошёл пакет и пересобрался.
> Формируется новый временный сизиф с этим пакетом, и на этом
> временном сизифе выполняется ряд проверок.  Если все проверки
> прошли успешно, то временный сизиф становится текущим
> ("коммит"), и очередь продвигается.

Кластеры изменений так тоже возможно делать становится.
Например, недавнее со шрифтами или любой soname change.

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

Re: [devel] pkgconfiglib.req

[Michael Shigorin]

On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote:
> ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> до тех пор, пока он кому-нибудь не понадобится.

Вот это бы хорошо в sisyphus_check, для начала как warning.

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

Re: [devel] giter-factory

[Aleksey Avdeev]

Alexey Tourbin пишет:
...
> 
> В общем, у меня есть некоторый набор "правильных идей", он касается
> первичного тестирования пакетов при сборке из gear.  Большая часть этих
> идей была озвучена здесь (в списке devel@), некоторые принципиально
> важные пояснения были в частной переписке.  Я могу продублировать
> пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень
> хорошо понимать, о чем идет речь.

  Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.)

-- 

С уважением. Алексей.

Re: [devel] giter-factory

[Alexey Tourbin]

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

On Mon, Sep 17, 2007 at 12:13:53AM +0300, Michael Shigorin wrote:
> > Преимущество тут только в том, что пересборка/публикация происходит
> > очень быстро, но это просто сопособ очень быстро всё пустить под откос.
> > Даже сейчас "ответственный товарищ, формирующий сизиф", играет
> > созидательную роль, не пропуская (hopefully) вручную "очень плохие
> > пакеты".  Просто исключить эту роль, не дав ничего взамен, нельзя.
> 
> 2 legion: примерно об этом и на конференции пытался сказать, 
> да и при обсуждении _осмысленности_ сверхзвуковой _публикации_.
> 
> > Мое альтернативное видение такое: прошёл пакет и пересобрался.
> > Формируется новый временный сизиф с этим пакетом, и на этом
> > временном сизифе выполняется ряд проверок.  Если все проверки
> > прошли успешно, то временный сизиф становится текущим
> > ("коммит"), и очередь продвигается.
> 
> Кластеры изменений так тоже возможно делать становится.
> Например, недавнее со шрифтами или любой soname change.

Миша.  Кластеры пакетов как идея это скорее глупость.  В частной
переписке at <-> ldv,legion я сформулировал более общую и красивую идею
"мёржа" веток репозитария.  Ветки это задания (один или более пакетов в
"кармане"), которые не прошли подтверждение на автомате.  Мёрж это некая
операция применения изменений относительно других изменений.  Мёрж
*отлично* соответствует критерию фальсификационизма: он либо возможен,
либо не возможен.  Ещё бы тебе понимать, что такое критерий
фальсификационизма.

В общем, у меня есть некоторый набор "правильных идей", он касается
первичного тестирования пакетов при сборке из gear.  Большая часть этих
идей была озвучена здесь (в списке devel@), некоторые принципиально
важные пояснения были в частной переписке.  Я могу продублировать
пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень
хорошо понимать, о чем идет речь.

В целом всё описанное более чем возможно.  Нужно просто браться за дело,
но у меня в ближайшее время не будет на это много времени.

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

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

[devel] giter-factory idea

[Alexey Tourbin]

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

On Mon, Sep 17, 2007 at 01:32:46AM +0400, Aleksey Avdeev wrote:
> > В общем, у меня есть некоторый набор "правильных идей", он касается
> > первичного тестирования пакетов при сборке из gear.  Большая часть этих
> > идей была озвучена здесь (в списке devel@), некоторые принципиально
> > важные пояснения были в частной переписке.  Я могу продублировать
> > пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень
> > хорошо понимать, о чем идет речь.
> 
>   Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.)

Ваш стиль коммитов в git.alt не слишком обнадеживает насчет
продуктивности обдумывания.  Тем не менее.

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

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

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

-- 

> > В схеме с подтверждением вручную очень желательно иметь идентификатор [задания]
> Что это "подтверждение вручную" ?

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

Значит, в автоматической системе перед публикацией будет выполняться
ряд проверок.  Минимально что должно проверяться -- это целостность
репозитария при внедрении в него новых пакетов.  В частности это
unmet'ы и возможность инициализации нового билдрута.  Представляешь
что будет если пакет опубликовался и --initroot перестал работать?!

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

Соответственно, если обнаружена "подозрительная ситуация", то пакет
(точнее, весь task) ставится "на подтверждение вручную".  Думаю что
можно будет обнаруживать разные классы атак на целостность репозитария.
В зависимости от классификации атаки подтверждения со стороны самого
maintainer'а может быть достаточно или не достаточно (во втором случае
требуется подтверждение со стороны "авторитета", т.е. грубо говоря
ldv|legion).

Подтверждение вручную ломает всю идею сериализации.  Если task встал
на подтверждение вручную, то этот task не должен задерживать продвижение
очереди.  Соответственно, могут возникать очень нетривиальные ситуации:
что делать с подтверждением вручную, если оно пришло слишком поздно,
и фигурально выражаясь, погода изменилась и ветер дует теперь дует в
другую сторону?  Но и тут можно кое-что придумать.  В простейшем случае
можно просто перекладывать "старые" пакеты в "новый" репозитарий, но на
самом деле это никуда не годится.  Здесь помогает аналогия мёржа.  Нужно
"смёржить" старые пакеты из "бранча" (таска), который встал на
подтверждение вручную, в текущий бранч master (новый репозитарий).
Стратегии мёржа могут быть разные.  Простейшая стратегия это как раз
нормальная формализация "перекладывания пакетов".  В бранче сидит
"операция мёржа", которая активизируется при подтверждении вручную:

        rm pkg1-subpkg1-v1.i586.rpm
        rm pkg1-subpkg2-v1.i586.rpm
        rm pkg1-v1.src.rpm
        add pkg1-subpkg1-v2.i586.rpm
        add pkg1-subpkg2-v2.i586.rpm
        add pkg1-v2.src.rpm

Если все команды rm могут быть выполнены на master'е, то данный мёрж 
всё ещё возможен.  Если же мёрж невозможен, то таск отменяется.  Можно
будет делать что-то типа авто-ребейса.

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

-- 

На самом деле rm и add должны выполняться с большей гранулярностью.

        rm name SVR filename
        add name SVR filename

Гранулярность в rm страхует от удаления новой сборки в которой
добавился serial.  А гранулярность add страхует от того, что пакет
с именем name но другим SVR/filename был уже добавлен.

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

-- 

> Я хочу сократить вмешательство человека до минимума.
> [...]

Я попытался раскрыть идею в соседнем письме.  Смысл как раз в том, чтобы
формализовать весь набор действий, который выполняет квалифицированный 
специалист при проверке и подписи репозитария.  То есть работы на самом
деле должно сократиться.  То что	<...делается...>
вручную или полу-автоматически при помощи каких-то скриптов, будет
преподнесено на блюдечке с голубой каёмочкой.

Более того, большую часть "подтверждений вручную" можно будет отдать
на откуп самим maintainer'ам.  Пускай сами подтверждают или отменяют,
чево они там насобирали.  Подтверждение со стороны авторитета явно
требуется только при "конфликтах".  Например я добавил в пакет perl
подпакет coreutils.  То есть может быть конфликт между двумя
maintainer'ами.  Проверка acl по src.rpm проходит, а при попытке
преложить пакеты в репозитарий ничего не получается.  Тут-то и может
потребоваться "авторитетное" подтверждение.

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

Плюс аналогичная проверка, конечно же, нужна на provides/obsolets,
чтобы не было конфликта претензий.

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

Re: [devel] pkgconfiglib.req

[Alexey Rusakov]

On Mon, 17 Sep 2007 00:17:01 +0300
Michael Shigorin wrote:

> On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote:
> > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> > до тех пор, пока он кому-нибудь не понадобится.
> 
> Вот это бы хорошо в sisyphus_check, для начала как warning.
+1

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

Re: [devel] giter-factory idea

[Aleksey Avdeev]

Alexey Tourbin пишет:
> On Mon, Sep 17, 2007 at 01:32:46AM +0400, Aleksey Avdeev wrote:
>>> В общем, у меня есть некоторый набор "правильных идей", он касается
>>> первичного тестирования пакетов при сборке из gear.  Большая часть этих
>>> идей была озвучена здесь (в списке devel@), некоторые принципиально
>>> важные пояснения были в частной переписке.  Я могу продублировать
>>> пояснения здесь, хотя вряд ли это что-то даст, потому что нужно очень
>>> хорошо понимать, о чем идет речь.
>>   Хотелось бы услышать. (Для возможности подумать идею в фоновом режиме.)
> 
> Ваш стиль коммитов в git.alt не слишком обнадеживает насчет
> продуктивности обдумывания.

  А что с ними не так, если не секрет?

>  Тем не менее.

  Спасибо.

-- 

С уважением. Алексей.

Re: [devel] pkgconfiglib.req

[Alexey Tourbin]

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

On Mon, Sep 17, 2007 at 02:50:25AM +0400, Alexey Rusakov wrote:
> > On Tue, Aug 28, 2007 at 09:11:00PM +0400, Alexey M. Tourbin wrote:
> > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> > > до тех пор, пока он кому-нибудь не понадобится.
> > 
> > Вот это бы хорошо в sisyphus_check, для начала как warning.
> +1

Чево плюс один, берите и делайте.
Но учтите что в sisyphus_check ворнингов на данный момент нету,
это формальный инструмент который дает ответ да/нет.

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

Re: [devel] giter-factory idea

[Alexey Tourbin]

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

On Mon, Sep 17, 2007 at 03:01:52AM +0400, Aleksey Avdeev wrote:
> > Ваш стиль коммитов в git.alt не слишком обнадеживает насчет
> > продуктивности обдумывания.
> 
>   А что с ними не так, если не секрет?

У Вас слишком много бранчей.  Так что когда винт начинает трещать
а postfix напрягаться -- я точно знаю: Алексей Авдеев прислал пачку
ценных писем про apache2.

Что с ним не так Вам виднее.  Но в принципе такие прецеденты нагрузки
на postfix у меня были раньше только при очень неудачных пересборках
сизифа (из-за того, что я получаю все письма от робота на "CC: qa@").

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

Re: [devel] giter-factory idea

[Aleksey Avdeev]

Alexey Tourbin пишет:
> On Mon, Sep 17, 2007 at 03:01:52AM +0400, Aleksey Avdeev wrote:
>>> Ваш стиль коммитов в git.alt не слишком обнадеживает насчет
>>> продуктивности обдумывания.
>>   А что с ними не так, если не секрет?
> 
> У Вас слишком много бранчей.  Так что когда винт начинает трещать
> а postfix напрягаться -- я точно знаю: Алексей Авдеев прислал пачку
> ценных писем про apache2.
> 
> Что с ним не так Вам виднее.  Но в принципе такие прецеденты нагрузки
> на postfix у меня были раньше только при очень неудачных пересборках
> сизифа (из-за того, что я получаю все письма от робота на "CC: qa@").

  Такое количество бранчей вестма удобно, т. к. позволяет отделять мух
от котлет явным образом. :-)

  Основных причины 2:

1. Упрощается выдирание самомтоятельных кусков для использования где-то
ещё (spec`и, gettext`овские переводы и пр.).

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

  И, похоже, 1 обусловлена моим незнанием правельных путей:

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

PS: Вашему postfix -- моё сочувствие. :-)

-- 

С уважением. Алексей.

Re: [devel] giter-factory

[Michael Shigorin]

On Mon, Sep 17, 2007 at 01:36:55AM +0400, Alexey Tourbin wrote:
> > Кластеры изменений так тоже возможно делать становится.
> > Например, недавнее со шрифтами или любой soname change.
> Миша.  Кластеры пакетов как идея это скорее глупость.

Возможно, я-то сказал "кластеры изменений".

> В частной переписке at <-> ldv,legion я сформулировал более
> общую и красивую идею "мёржа" веток репозитария.  Ветки это
> задания (один или более пакетов в "кармане"), которые не прошли
> подтверждение на автомате.

Ещё бы тебе понимать Layne's Law of Debate... :)

Если вдруг сталкивался с использованием sandman, то примерно
о том и речь, только без слова "ветки".

> В общем, у меня есть некоторый набор "правильных идей", он
> касается первичного тестирования пакетов при сборке из gear.
> Большая часть этих идей была озвучена здесь (в списке devel@),
> некоторые принципиально важные пояснения были в частной
> переписке.  Я могу продублировать пояснения здесь, хотя вряд ли
> это что-то даст, потому что нужно очень хорошо понимать, о чем
> идет речь.

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

PS: :)

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

Re: [devel] UQ: git-clone git.alt: unable to chdir or not a git archive

[Pavlov Konstantin]

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

On Tue, Sep 18, 2007 at 01:09:50PM +0300, Michael Shigorin wrote:
> On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote:
> > > > Вот это бы хорошо в sisyphus_check, для начала как warning.
> > > +1
> > Чево плюс один, берите и делайте.
> 
> По ходу дела:
> 
> http://git.altlinux.org/people/sbolshakov/packages/sisyphus_check.git
> -- есть, а вот clone не едет:
> 
> hasher32:~/git> git-clone git.alt:people/sbolshakov/packages/sisyphus_check.git
> Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/
> RSA host key for IP address '194.107.17.12' not in list of known hosts.
> fatal: 'people/sbolshakov/packages/sisyphus_check.git': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> fetch-pack from 'git.alt:people/sbolshakov/packages/sisyphus_check.git' failed.
> 
> Мало того, склонировать ldv тоже не получается:
> 
> hasher32:~/git> git-clone git.alt:people/ldv/packages/sisyphus_check.git 
> Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/
> RSA host key for IP address '194.107.17.12' not in list of known hosts.
> fatal: 'people/ldv/packages/sisyphus_check.git': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> fetch-pack from 'git.alt:people/ldv/packages/sisyphus_check.git' failed.
> 
> ???!?

Ты слэш перед people забыл.

-- 
А вот ZODB3.3 это, конечно, большой шаг вперед. Прощай ExtensionClass ;).
Я уже начал перепирать свои коды туда.
		-- cray in devel@

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

[devel] UQ: git-clone git.alt: unable to chdir or not a git archive

[Michael Shigorin]

On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote:
> > > Вот это бы хорошо в sisyphus_check, для начала как warning.
> > +1
> Чево плюс один, берите и делайте.

По ходу дела:

http://git.altlinux.org/people/sbolshakov/packages/sisyphus_check.git
-- есть, а вот clone не едет:

hasher32:~/git> git-clone git.alt:people/sbolshakov/packages/sisyphus_check.git
Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/
RSA host key for IP address '194.107.17.12' not in list of known hosts.
fatal: 'people/sbolshakov/packages/sisyphus_check.git': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
fetch-pack from 'git.alt:people/sbolshakov/packages/sisyphus_check.git' failed.

Мало того, склонировать ldv тоже не получается:

hasher32:~/git> git-clone git.alt:people/ldv/packages/sisyphus_check.git 
Initialized empty Git repository in /home/mike/git/sisyphus_check/.git/
RSA host key for IP address '194.107.17.12' not in list of known hosts.
fatal: 'people/ldv/packages/sisyphus_check.git': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
fetch-pack from 'git.alt:people/ldv/packages/sisyphus_check.git' failed.

???!?

> Но учтите что в sisyphus_check ворнингов на данный момент нету,
> это формальный инструмент который дает ответ да/нет.

stderr ему тоже оторвали?  Типа, "да, но".

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

[devel] отбой, спасибо, сам дурак

[Michael Shigorin]

On Tue, Sep 18, 2007 at 02:09:22PM +0400, Pavlov Konstantin wrote:
> > ???!?
> Ты слэш перед people забыл.

Спасибо, пошёл заваривать зелёный чай...

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

Re: [devel] pkgconfiglib.req

[Michael Shigorin]

On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote:
> > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> > > > до тех пор, пока он кому-нибудь не понадобится.
> > > Вот это бы хорошо в sisyphus_check, для начала как warning.
> > +1
> Чево плюс один, берите и делайте.

Тоже мне бином Ньютона.  Заодно добавил tests/:
http://git.altlinux.org/people/mike/packages/?p=sisyphus_check.git;a=commitdiff;h=560f46b205749c2963231330a32eb20c895f12f1

PS: спасибо led@ за возвратное снимание меня с ручника 
по части теста на -devel. :)

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

Re: [devel] pkgconfiglib.req

[Alexey Rusakov]

On Tue, 18 Sep 2007 14:44:39 +0300
Michael Shigorin wrote:

> On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote:
> > > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> > > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> > > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> > > > > до тех пор, пока он кому-нибудь не понадобится.
> > > > Вот это бы хорошо в sisyphus_check, для начала как warning.
> > > +1
> > Чево плюс один, берите и делайте.
> 
> Тоже мне бином Ньютона.  Заодно добавил tests/:
> http://git.altlinux.org/people/mike/packages/?p=sisyphus_check.git;a=commitdiff;h=560f46b205749c2963231330a32eb20c895f12f1
Вай, Миша, огромное спасибо. Люблю порядок :)

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[devel] *.pc -devel

[Alexey Tourbin]

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

On Tue, Sep 18, 2007 at 02:44:39PM +0300, Michael Shigorin wrote:
> On Mon, Sep 17, 2007 at 09:36:31AM +0400, Alexey Tourbin wrote:
> > > > > ДАННОЕ ИЗМЕНЕНИЕ, и не одно оно, ОКОНЧАТЕЛЬНО ПЕРЕВОДИТ *.pc ФАЙЛЫ
> > > > > В СТАТУС "ДЛЯ *-devel ПАКЕТОВ".  Уважаемые товарищи maintaner'ы!
> > > > > Кладите *.pc файл в *-devel подпакет, либо не пакуйте его вообще,
> > > > > до тех пор, пока он кому-нибудь не понадобится.
> > > > Вот это бы хорошо в sisyphus_check, для начала как warning.
> > > +1
> > Чево плюс один, берите и делайте.
> 
> Тоже мне бином Ньютона.  Заодно добавил tests/:
> http://git.altlinux.org/people/mike/packages/?p=sisyphus_check.git;a=commitdiff;h=560f46b205749c2963231330a32eb20c895f12f1
> 
> PS: спасибо led@ за возвратное снимание меня с ручника 
> по части теста на -devel. :)

Ох.  Я наверное всё-таки поспешил сделать вывод, что все *.pc файлы
нужно вынести в -devel пакеты.  Это не всегда решает проблему.
А проблема в неопределенной семантике pkgconfig зависимостей.
То есть там нет расслоения на BuildRequires, Requires: lib%name.so.0
и Requires: lib%name-devel.  Я об этом писал.

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

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

Переформулирую критерий включений *.pc файлов в пакеты.
Файлы *.pc, как правило, должны входить в -devel пакеты.
Это соответствует превалирующей семантике lib%name-devel.

С другой стороны, pkgconfig зависимости иногда "снижаются"
вниз по топологии пакетов до уровня /usr/bin.  Если *.pc файл находится
в таком не-devel пакете, то ТРЕБУЕТСЯ, чтобы зависимости этого *.pc
файла, в том числе транзитивные, не содержали каких-либо -devel пакетов.
*.pc файл без зависимостей заведомо удовлетворяет этому требованию.
Зависимости *.pc файлов можно подчистить вручную, если они
альтернативным образом хорошо обнаруживаются (при помощи find-requires).

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

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