[devel] Q: rxvt-unicode vs xinitrc

[devel] Q: rxvt-unicode vs xinitrc

[Евгений Терешков]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Наблюдаю такое:

~$ rpm -e --test xterm
ошибка: удаление этих пакетов нарушит зависимости:
	xvt нужен для xinitrc-2.4.28-alt1
~$ rpm -qR xinitrc |grep xvt
xvt
~$ rpm -q --provides rxvt-unicode
rxvt-unicode = 9.02-alt1
/usr/bin/xvt  
~$ rpm -q --provides xterm
xvt  
/usr/bin/xvt  
xterm = 234-alt1
~$ rpm -q xinitrc rxvt-unicode xterm
xinitrc-2.4.28-alt1
rxvt-unicode-9.02-alt1
xterm-234-alt1

На кого правильнее багу вешать, rxvt-unicode или xinitrc ? Или как надо?

- -- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iEYEARECAAYFAkfUJc4ACgkQU3UGRj5hQchZzQCfVtLP8cgAjDzqWC6GDjWFs+Fp
+6wAmgI7LTwqIhmuhpHcYmdKvJIM/VSd
=L4zu
-----END PGP SIGNATURE-----

Re: [devel] Q: rxvt-unicode vs xinitrc

[Alexey Gladkov]

Евгений Терешков wrote:
> ~$ rpm -q xinitrc rxvt-unicode xterm
> xinitrc-2.4.28-alt1
> rxvt-unicode-9.02-alt1
> xterm-234-alt1

Видимо на rxvt-unicode. Он не провайдит xvt.

-- 
Rgrds, legion

Re: [devel] Q: rxvt-unicode vs xinitrc

[Евгений Терешков]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexey Gladkov пишет:

> Евгений Терешков wrote:
>> ~$ rpm -q xinitrc rxvt-unicode xterm
>> xinitrc-2.4.28-alt1
>> rxvt-unicode-9.02-alt1
>> xterm-234-alt1
> Видимо на rxvt-unicode. Он не провайдит xvt.

Он провайдит /usr/bin/xvt, как видно.

Я наверное более к at@ обращался: как там оно сейчас должно быть?
Абсолютные пути или имена бинарников?

P.S.:
$ rpm -q rpm
rpm-4.0.4-alt89 

у меня, если это важно.

- -- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iEYEARECAAYFAkfUOkYACgkQU3UGRj5hQcgk+gCgzDYbDv8GrhHD89i5MGmbKFHF
008An3Up8DVseAurU92P9CDI3ENLQ1Kx
=lm76
-----END PGP SIGNATURE-----

Re: [devel] Q: rxvt-unicode vs xinitrc

[Alexey Tourbin]

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

On Mon, Mar 10, 2008 at 01:00:45AM +0700, Евгений Терешков wrote:
> ~$ rpm -e --test xterm
> ошибка: удаление этих пакетов нарушит зависимости:
> 	xvt нужен для xinitrc-2.4.28-alt1
> ~$ rpm -qR xinitrc |grep xvt
> xvt
> ~$ rpm -q --provides rxvt-unicode
> rxvt-unicode = 9.02-alt1
> /usr/bin/xvt  
> ~$ rpm -q --provides xterm
> xvt  
> /usr/bin/xvt  
> xterm = 234-alt1
> ~$ rpm -q xinitrc rxvt-unicode xterm
> xinitrc-2.4.28-alt1
> rxvt-unicode-9.02-alt1
> xterm-234-alt1
> 
> На кого правильнее багу вешать, rxvt-unicode или xinitrc ? Или как надо?

$ apt-cache showpkg /usr/bin/xvt |grep -A99 '^Reverse Provides:'
Reverse Provides: 
xterm 234-alt1
rxvt-unicode 9.02-alt1
kdebase-wm 3.5.9-alt1
kdebase-common 3.5.9-alt1
kde4base-konsole 4.0.1-alt1
gnome-terminal 2.18.4-alt2
aterm 1.0.1-alt1
Eterm 0.9.3-alt2
$ apt-cache showpkg xvt |grep -A99 '^Reverse Provides:'         
Reverse Provides: 
xterm 234-alt1
kdebase-wm 3.5.9-alt1
kde4base-konsole 4.0.1-alt1
aterm 1.0.1-alt1
Eterm 0.9.3-alt2
$ 

В принципе бардачок имеется.  Какого рожна kdebase-wm предоставляет
/usr/bin/xvt сказать с ходу трудно.

Вообще же файловая зависимость на /usr/bin/xvt у xinitrc кажется мне
более правильной.  Если xinitrc запускает /usr/bin/xvt, то нет ничего
лучше, чем просто требовать /usr/bin/xvt.  Поскольку /usr/bin/xvt
является альтернативой, то alternatives.prov должен автоматически
прописать "Provides: /usr/bin/xvt" у всех пакетов, которые претендуют
на эту альтернативу.  А вот "Provides: xvt" Пушкин не напишет.

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

Re: [devel] Q: rxvt-unicode vs xinitrc

[Andrey Rahmatullin]

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

On Mon, Mar 10, 2008 at 06:46:22AM +0300, Alexey Tourbin wrote:
> В принципе бардачок имеется..  Какого рожна kdebase-wm предоставляет
> /usr/bin/xvt сказать с ходу трудно.
$ realpath /usr/bin/xvt
/usr/bin/konsole
$ rpm -qf /usr/bin/konsole
kdebase-wm-3.5.9-alt1


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Если уж вы пользуетесь Сизифом, то о проблемах надо сообщать, а не
откатываться молча на старую версию.
		-- vsu in sisyphus@

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

Re: [devel] Q: rxvt-unicode vs xinitrc

[Евгений Терешков]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexey Tourbin пишет:

>> На кого правильнее багу вешать, rxvt-unicode или xinitrc ? Или как надо?

Так на кого?

> /usr/bin/xvt сказать с ходу трудно.

konsole

> Вообще же файловая зависимость на /usr/bin/xvt у xinitrc кажется мне
> более правильной.  Если xinitrc запускает /usr/bin/xvt, то нет ничего
> лучше, чем просто требовать /usr/bin/xvt.  Поскольку /usr/bin/xvt
> является альтернативой, то alternatives.prov должен автоматически
> прописать "Provides: /usr/bin/xvt" у всех пакетов, которые претендуют
> на эту альтернативу.  А вот "Provides: xvt" Пушкин не напишет.

runwm из пакета xinitrc запускает xvt по пути относительно $PATH. И требует
соответсвенно не по абсолютному пути.

Получается, что надо чинить xterm, xinitrc (и ещё что-то, список выше
скипнут) чтобы они требовали и провайдили полный путь?

- -- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iEYEARECAAYFAkfVBWAACgkQU3UGRj5hQcitVACfWFUF4lP9qMCnZJZO42Ujjnis
XyoAoJCBJSkI1HHoxBD6lY+LnA/cT6qA
=xng0
-----END PGP SIGNATURE-----

[devel] contents_index provides (rxvt-unicode vs xinitrc)

[Alexey Tourbin]

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

On Mon, Mar 10, 2008 at 04:54:39PM +0700, Евгений Терешков wrote:
> > Вообще же файловая зависимость на /usr/bin/xvt у xinitrc кажется мне
> > более правильной.  Если xinitrc запускает /usr/bin/xvt, то нет ничего
> > лучше, чем просто требовать /usr/bin/xvt.  Поскольку /usr/bin/xvt
> > является альтернативой, то alternatives.prov должен автоматически
> > прописать "Provides: /usr/bin/xvt" у всех пакетов, которые претендуют
> > на эту альтернативу.  А вот "Provides: xvt" Пушкин не напишет.
> 
> runwm из пакета xinitrc запускает xvt по пути относительно $PATH. И требует
> соответсвенно не по абсолютному пути.

У нас пока не поддерживаются виртуальные зависимости вида
executable(xvt).  В общем, требовать путь к альтернативе --
не самый плохой вариант (а может быть и самый хороший).

Собственно, если бы при сборке пакета xinitrc в сборочном чруте
стоял хотя бы один из пакетов с альтернативой xvt, то зависимость
на /usr/bin/xvt появилась бы автоматиически.

$ rpm -ql xinitrc |xargs grep -w xvt 
/etc/X11/Xsession:                      export BROWSER="xvt -e $n"
/usr/bin/runwm:         echo "xvt -geometry 100x25+0+0 $@"
/usr/bin/runwm:         xvt -geometry 100x25+0+0 &
$ /usr/lib/rpm/shell.req -v /usr/bin/runwm
shell.req: /usr/bin/runwm: cat -> /bin/cat -> coreutils (via contents_index_bin)
coreutils
shell.req: /usr/bin/runwm: xvt -> /usr/bin/xvt -> ... (via host_env)
shell.req: /usr/bin/runwm: /usr/bin/xvt -> /usr/bin/xvt -> /usr/bin/xvt (alternative)
/usr/bin/xvt
$ 

То есть здесь проблема в том, что /usr/bin/xvt отсутствует в
contents_index (потому что альтернатива на запакована как файл в пакете,
а создаётся только после установки).  Поэтому остаётся искать
/usr/bin/xvt только в хост-системе.  И, таким образом, при сборке
в хешере зависимость на /usr/bin/xvt теряется.

Я вот думаю, стоит ли дополнить contents_index альтернативами.

> Получается, что надо чинить xterm, xinitrc (и ещё что-то, список выше
> скипнут) чтобы они требовали и провайдили полный путь?

Путь альтернативы провайдится автоматически.
/usr/lib/rpm/alternatives.prov

То есть "Provides: /usr/bin/xvt" где надо появится автоматически.
А вот "Provides: xvt" Пушкин не напишет.

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

Re: [devel] contents_index provides (rxvt-unicode vs xinitrc)

[Alexey Tourbin]

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

On Mon, Mar 10, 2008 at 01:17:55PM +0300, Alexey Tourbin wrote:
> Собственно, если бы при сборке пакета xinitrc в сборочном чруте
> стоял хотя бы один из пакетов с альтернативой xvt, то зависимость
> на /usr/bin/xvt появилась бы автоматиически.
> 
> $ rpm -ql xinitrc |xargs grep -w xvt 
> /etc/X11/Xsession:                      export BROWSER="xvt -e $n"
> /usr/bin/runwm:         echo "xvt -geometry 100x25+0+0 $@"
> /usr/bin/runwm:         xvt -geometry 100x25+0+0 &
> $ /usr/lib/rpm/shell.req -v /usr/bin/runwm
> shell.req: /usr/bin/runwm: cat -> /bin/cat -> coreutils (via contents_index_bin)
> coreutils
> shell.req: /usr/bin/runwm: xvt -> /usr/bin/xvt -> ... (via host_env)
> shell.req: /usr/bin/runwm: /usr/bin/xvt -> /usr/bin/xvt -> /usr/bin/xvt (alternative)
> /usr/bin/xvt
> $ 
> 
> То есть здесь проблема в том, что /usr/bin/xvt отсутствует в
> contents_index (потому что альтернатива на запакована как файл в пакете,
> а создаётся только после установки).  Поэтому остаётся искать
> /usr/bin/xvt только в хост-системе.  И, таким образом, при сборке
> в хешере зависимость на /usr/bin/xvt теряется.

/ALT/beehive/success/xinitrc-2.4.28-alt1:
   121  find-requires: running scripts (files,lib,pam,perl,pkgconfig,pkgconfiglib,python,shebang,shell,static,symlinks)
   122  shell.req: /usr/src/tmp/xinitrc-buildroot/usr/bin/runwm: xvt not found (skip)

> Я вот думаю, стоит ли дополнить contents_index альтернативами.

Точнее, если какой-либо путь предоставляется пакетом, но не запакован
в нём, то в contents_index можно добавлять mapping путь -> путь.
Альтернативы в таком случае являются частным случаем этого
правила.  Другой случай -- /usr/bin/python.

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

Re: [devel] contents_index provides (rxvt-unicode vs xinitrc)

[Alexey Tourbin]

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

On Mon, Mar 10, 2008 at 01:37:45PM +0300, Alexey Tourbin wrote:
> On Mon, Mar 10, 2008 at 01:17:55PM +0300, Alexey Tourbin wrote:
> > Собственно, если бы при сборке пакета xinitrc в сборочном чруте
> > стоял хотя бы один из пакетов с альтернативой xvt, то зависимость
> > на /usr/bin/xvt появилась бы автоматиически.
> > 
> > $ rpm -ql xinitrc |xargs grep -w xvt 
> > /etc/X11/Xsession:                      export BROWSER="xvt -e $n"
> > /usr/bin/runwm:         echo "xvt -geometry 100x25+0+0 $@"
> > /usr/bin/runwm:         xvt -geometry 100x25+0+0 &
> > $ /usr/lib/rpm/shell.req -v /usr/bin/runwm
> > shell.req: /usr/bin/runwm: cat -> /bin/cat -> coreutils (via contents_index_bin)
> > coreutils
> > shell.req: /usr/bin/runwm: xvt -> /usr/bin/xvt -> ... (via host_env)
> > shell.req: /usr/bin/runwm: /usr/bin/xvt -> /usr/bin/xvt -> /usr/bin/xvt (alternative)
> > /usr/bin/xvt
> > $ 
> > 
> > То есть здесь проблема в том, что /usr/bin/xvt отсутствует в
> > contents_index (потому что альтернатива на запакована как файл в пакете,
> > а создаётся только после установки).  Поэтому остаётся искать
> > /usr/bin/xvt только в хост-системе.  И, таким образом, при сборке
> > в хешере зависимость на /usr/bin/xvt теряется.
> 
> /ALT/beehive/success/xinitrc-2.4.28-alt1:
>    121  find-requires: running scripts (files,lib,pam,perl,pkgconfig,pkgconfiglib,python,shebang,shell,static,symlinks)
>    122  shell.req: /usr/src/tmp/xinitrc-buildroot/usr/bin/runwm: xvt not found (skip)
> 
> > Я вот думаю, стоит ли дополнить contents_index альтернативами.
> 
> Точнее, если какой-либо путь предоставляется пакетом, но не запакован
> в нём, то в contents_index можно добавлять mapping путь -> путь.
> Альтернативы в таком случае являются частным случаем этого
> правила.  Другой случай -- /usr/bin/python.

Короче, я подготовил новую версию пакета sisyphus, который используется
для генерации репозитария (в том числе и для генерации contents_index).
Теперь у пакета xinitrc должна появиться автоматическая зависимость на
/usr/bin/xvt.  Вот основное изменение.

commit 923a806dd766aee0eeac505e18a1b3189af6aa8e
Author: Alexey Tourbin <at@altlinux>
Date:   Mon Mar 10 16:46:18 2008 +0300

    sisyphus_gen_contents: do alternatives-like virtual paths
    
    Consider xinitrc package, which cannot resolve "xvt" dependency:
    shell.req: /usr/src/tmp/xinitrc-buildroot/usr/bin/runwm: xvt not found (skip)
    
    This is because /usr/bin/xvt is an alternative, and it has not been
    listed in contens_index_bin.  Also note that /usr/bin/xvt did not exist
    in hasher chroot, that's why fallback to host-system lookup did not work,
    too.  We've simply lost the dependency.
    
    To fix this, we need to list alternatives-like virtual paths in
    contents_index files.  A path is virtual iff it is not packaged but
    explicitly provided by the package.  Virutal paths should always map
    to themselves, because most of them are alternatives (if there is only
    one package in the repo that provides some alternative, we still want
    file-level dependency on the alternative).

diff --git a/bin/sisyphus_gen_contents b/bin/sisyphus_gen_contents
index 84d3ac1..7de6b82 100644
--- a/bin/sisyphus_gen_contents
+++ b/bin/sisyphus_gen_contents
@@ -47,18 +47,28 @@ WORKDIR="$(mktemp -d -t "$PROG.XXXXXXXXXX")"
 find -mindepth 1 -maxdepth 1 -name \*.rpm -print0 |
 	xargs -r0 rpmquery -p --qf '[%{FILENAMES}\t%{NAME}\n]' -- |
 	fgrep -v ' ' |
-	sort -u >"$WORKDIR"/list
+	sort -u >"$WORKDIR"/f-list
+
+# generate path-like provides list.
+find -mindepth 1 -maxdepth 1 -name \*.rpm -print0 |
+	xargs -r0 rpmquery -p --qf '[%{PROVIDENAME}\t%{NAME}\n]' -- |
+	grep '^/' |
+	fgrep -v ')' |
+	fgrep -v ' ' |
+	sort -u >"$WORKDIR"/p-list
 
 cd "$WORKDIR"
 
-# find dups.
-cut -f1 <list |
+# find file dups.
+cut -f1 <f-list |
 	uniq -c |
-	awk '{if ($1 != "1") printf("%s\t%s\n",$2,$2)}' >dups
+	awk '{if ($1 != "1") printf("%s\t%s\n",$2,$2)}' >f-dups
+
+# generate alternatives-like virtual path list.
+comm -13 f-list p-list >vp-list
 
-# find uniquie lines.
-cut -f1 dups |
-	join -v1 list - |
-	tr -s ' ' '\t' >uniq
+# virtual paths should always map to themselves.
+cut -f1 <vp-list |
+	awk '{printf("%s\t%s\n",$1,$1)}' >vp-force-dups
 
-sort -u dups uniq
+sort -u -k1,1 vp-force-dups f-dups f-list

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

Re: [devel] contents_index provides (rxvt-unicode vs xinitrc)

[Евгений Терешков]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexey Tourbin пишет:

> Короче, я подготовил новую версию пакета sisyphus, который используется

Странно, мне о таком пакете неизвестно :-)

В общем, мне идти и вешать баги на xterm и xinitrc (получается, что прав
лишь майнтаинер rxvt-unicode), чтобы вручную не требовали и не провайдили
xvt в спеках? После публикаций какой версий какого пакета можно будет это
чинить? Или что для этого нужно?

- -- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iEYEARECAAYFAkfVc2QACgkQU3UGRj5hQcj0OQCgtJvnCLhRdaR0WgESmle6tkAz
AtMAniyJCyZ9ab5i5InovE/yJcintumu
=ULTy
-----END PGP SIGNATURE-----

[devel] alternatives provides (contents_index provides)

[Alexey Tourbin]

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

On Tue, Mar 11, 2008 at 12:44:03AM +0700, Евгений Терешков wrote:
> В общем, мне идти и вешать баги на xterm и xinitrc (получается, что прав
> лишь майнтаинер rxvt-unicode), чтобы вручную не требовали и не провайдили
> xvt в спеках? После публикаций какой версий какого пакета можно будет это
> чинить? Или что для этого нужно?

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

Надо ещё посмотреть, где какие нестыковки есть.  Желательно ещё
переделать alternatives.prov, чтобы он выставлял зависимость в более
правильном подпакете.  Если описание альтернативы packages.d/%name
и таргет альтернативы (бинарь) запакованы в разных подпакетах, то
сейчас автоматический provides появляется в подпакете с описанием
альтернативы, а не в пакете, который содержит бинарь (а последнее
было бы правильнее).

Например, сейчас у пакета kdebase-common появился автоматический
provides:

$ rpm -qp --provides /ALT/Sisyphus/files/i586/RPMS/kdebase-common-3.5.9-alt1.i586.rpm |grep ^/
/usr/bin/xvt  
$ 

из-за того, что в нём содержится описание альтернативы

$ rpm -qlvp /ALT/Sisyphus/files/i586/RPMS/kdebase-common-3.5.9-alt1.i586.rpm |grep alternatives
-rw-r--r--    1 root    root               33 Feb 29 06:04 /etc/alternatives/packages.d/kdebase
$ rpmpeek /ALT/Sisyphus/files/i586/RPMS/kdebase-common-3.5.9-alt1.i586.rpm grep ^/ ./etc/alternatives/packages.d/kdebase
/usr/bin/xvt    /usr/bin/konsole        15
$ 

тогда как /usr/bin/konsole запакован в kdebase-wm.

alternatives.prov всё же проверяет, что таргет альтренативы существует
в %buildroot'е, но с раскладом по подпакетам дело обстоит сложнее.

Вот список "неправильных альтернатив" (из логов сборки) -- provides
не добавляется.

gcc4.1-4.1.2-alt2:alternatives.prov:
    /usr/src/tmp/gcc4.1-buildroot/etc/alternatives/packages.d/c++4.1:
	target /usr/bin/i586-alt-linux-c++filt-4.1 for /usr/bin/i586-alt-linux-c++filt not found under RPM_BUILD_ROOT
java-1.5.0-sun-0:1.5.0.13-alt1:alternatives.prov:
    /usr/src/tmp/java-1.5.0-sun-buildroot/etc/alternatives/packages.d/j2se1.5-sun-javaws:
	target /usr/lib/jvm/java-1.5.0-sun-1.5.0.13/jre/javaws/javaws-alt for /usr/bin/javaws not found under RPM_BUILD_ROOT
wsdl4j-0:1.6.2-alt2_2jpp1.7:alternatives.prov:
    /usr/src/tmp/wsdl4j-buildroot/etc/alternatives/packages.d/qname_wsdl4j:
	target /usr/share/java/wsdl4j-qname.jar for /usr/share/java/qname.jar not found under RPM_BUILD_ROOT
jdkgcj-0.3.3-alt11:alternatives.prov:
    /usr/src/tmp/jdkgcj-buildroot/etc/alternatives/packages.d/jdkgcj-javac:
	target /usr/lib/jdkgcj/j2se.sh for /etc/profile.d/j2se.sh not found under RPM_BUILD_ROOT
jdkgcj-0.3.3-alt11:alternatives.prov:
    /usr/src/tmp/jdkgcj-buildroot/etc/alternatives/packages.d/jdkgcj-javac:
	target /usr/lib/jdkgcj/j2se.csh for /etc/profile.d/j2se.csh not found under RPM_BUILD_ROOT
gcc3.4-3.4.5-alt7:alternatives.prov:
    /usr/src/tmp/gcc3.4-buildroot/etc/alternatives/packages.d/c++3.4:
	target /usr/bin/i586-alt-linux-c++filt-3.4 for /usr/bin/i586-alt-linux-c++filt not found under RPM_BUILD_ROOT
java-1.6.0-sun-0:1.6.0.03-alt1:alternatives.prov:
    /usr/src/tmp/java-1.6.0-sun-buildroot/etc/alternatives/packages.d/j2se1.6-sun-javaws:
	target /usr/lib/jvm/java-1.6.0-sun-1.6.0.03/jre/javaws/javaws-alt for /usr/bin/javaws not found under RPM_BUILD_ROOT
java-1.4.2-sun-0:1.4.2.16-alt1:alternatives.prov:
    /usr/src/tmp/java-1.4.2-sun-buildroot/etc/alternatives/packages.d/j2se1.4-sun-javaws:
	target /usr/lib/jvm/jre-1.4.2-sun/bin/javaws for /usr/share/javaws not found under RPM_BUILD_ROOT
java-1.7.0-openjdk-0:1.7.0.13-alt3:alternatives.prov:
    /usr/src/tmp/java-1.7.0-openjdk-buildroot/etc/alternatives/packages.d/j2se1.7-openjdk-javac:
	target /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.13/bin/HtmlConverter for /usr/bin/HtmlConverter not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-x11 for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-nox for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-mule for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-mule-nextaw for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-nomule for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-nomule-nextaw for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-nox-mule for /usr/bin/xemacs not found under RPM_BUILD_ROOT
xemacsen-0.4-alt1:alternatives.prov:
    /usr/src/tmp/xemacsen-buildroot/etc/alternatives/packages.d/xemacs:
	target /usr/bin/xemacs-nox-nomule for /usr/bin/xemacs not found under RPM_BUILD_ROOT
vim-4:7.1.267-alt1:alternatives.prov:
    /usr/src/tmp/vim-buildroot/etc/alternatives/packages.d/vim-X11:
	target /usr/bin/vim-X11 for /usr/bin/vim not found under RPM_BUILD_ROOT

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

Re: [devel] alternatives provides (contents_index provides)

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [080311 11:32]:
> vim-4:7.1.267-alt1:alternatives.prov:
>     /usr/src/tmp/vim-buildroot/etc/alternatives/packages.d/vim-X11:
> 	target /usr/bin/vim-X11 for /usr/bin/vim not found under RPM_BUILD_ROOT
vim-X11 это тоже альтернатива.  Как тут поступать?

-- 
Regards,
Sir Raorn.

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

Re: [devel] alternatives provides (contents_index provides)

[Alexey Tourbin]

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

On Tue, Mar 11, 2008 at 11:53:11AM +0300, Alexey I. Froloff wrote:
> * Alexey Tourbin <at@> [080311 11:32]:
> > vim-4:7.1.267-alt1:alternatives.prov:
> >     /usr/src/tmp/vim-buildroot/etc/alternatives/packages.d/vim-X11:
> > 	target /usr/bin/vim-X11 for /usr/bin/vim not found under RPM_BUILD_ROOT
> vim-X11 это тоже альтернатива.  Как тут поступать?

Альтернатива сидит на альтернативе -- это только для опытных старпёров.
То есть скрипт не может автоматически прописать provides для
альтернативы, если нет уверенности, что таргет альтернативы существует
где-то "здесь же".  Потому что тот, кто требует альтренативу,
рассчитывает на то, что она будет фактически доступна сразу после
установки.  Proivdes придётся вручную прописывать "там".

Вот ещё более сложный случай:

$ cat /etc/alternatives/packages.d/xemacs
/usr/bin/xemacs /usr/bin/xemacs-x11             80
/usr/bin/xemacs /usr/bin/xemacs-nox             70
/usr/bin/xemacs /usr/bin/xemacs-mule            60
/usr/bin/xemacs /usr/bin/xemacs-mule-nextaw     50
/usr/bin/xemacs /usr/bin/xemacs-nomule          40
/usr/bin/xemacs /usr/bin/xemacs-nomule-nextaw   30
/usr/bin/xemacs /usr/bin/xemacs-nox-mule        20
/usr/bin/xemacs /usr/bin/xemacs-nox-nomule      10
$ rpm -qf /etc/alternatives/packages.d/xemacs
xemacsen-0.4-alt1
$

Здесь нельзя автоматически прописать "Provides: /usr/bin/xemacs"
потому что установка пакета xemacsen не влечёт за собой работающего
/usr/bin/xemacs, здесь просто описано, как быть с альтернативой,
если/когда появятся таргеты.

Ну и вообще эта конструкция несколько сомнитальная -- она ведь
не избавляет держателей таргетов от необходимости дёргать
"%register_alternatives xemacs".  Значит, не удаётся окончательно
отвязать работу с альтернативами от сборки таргетов.

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

Re: [devel] alternatives provides (contents_index provides)

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Tourbin <at-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:
[skipped]
 > Вот ещё более сложный случай:

 > $ cat /etc/alternatives/packages.d/xemacs
 > /usr/bin/xemacs /usr/bin/xemacs-x11             80
 > /usr/bin/xemacs /usr/bin/xemacs-nox             70
 > /usr/bin/xemacs /usr/bin/xemacs-mule            60
 > /usr/bin/xemacs /usr/bin/xemacs-mule-nextaw     50
 > /usr/bin/xemacs /usr/bin/xemacs-nomule          40
 > /usr/bin/xemacs /usr/bin/xemacs-nomule-nextaw   30
 > /usr/bin/xemacs /usr/bin/xemacs-nox-mule        20
 > /usr/bin/xemacs /usr/bin/xemacs-nox-nomule      10
 > $ rpm -qf /etc/alternatives/packages.d/xemacs
 > xemacsen-0.4-alt1
 > $

 > Здесь нельзя автоматически прописать "Provides: /usr/bin/xemacs"
 > потому что установка пакета xemacsen не влечёт за собой работающего
 > /usr/bin/xemacs, здесь просто описано, как быть с альтернативой,
 > если/когда появятся таргеты.

that was my intention.
Нельзя -- и не надо, это наши внутри'xemacs'овые проблемы.
Я сильно сомневаюсь, что когда-либо возникнет потребитель
зависимости /usr/bin/xemacs.

--