[devel] rpm 4.0.4-alt79

[devel] rpm 4.0.4-alt79

[Alexey Tourbin]

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

* Mon Oct 29 2007 Alexey Tourbin <at@altlinux> 4.0.4-alt79
- shell.req: implemented strong self-requires elimination within
  a package; if ANY shell script defines function "foo", dependencies
  on "foo" are discarded in all shell scripts throughout the package;
  a warning is issued if e.g. /usr/bin/foo executable is available
- pkgconfiglib.req: new dependency generator for "Libs" field in *.pc
  files; maps e.g. "-lfoo" -> /usr/lib/libfoo.so -> libfoo-devel

Некоторые мелкие изменения не отражены в changelog'е.
"Сломался" всего один пакет:

clamav-0.92-alt0.rc2
pkgconfig.prov: /usr/src/tmp/clamav-buildroot/usr/lib/pkgconfig/libclamav.pc: invalid pkg-config output: libclamav = 3:1:0

Версию "pkgconfig(libclamav) = 3:1:0" нельзя "нормально" отобразить
в rpm-версию.  Короче, двоеточие не входит в список допустимых символов,
которые могут быть в Version в *.pc файле.  Видимо, в libclamav.pc стоит
"сырая" версия библиотеки в стиле libtool, которую нужно преобразовать в
3.1.0.  Так это делается в некоторых других пакетах, в которых в *.pc
файле используется "преобразованная" версия libtool (напр.
libfreetype-2.3.5).

К этому письму приложен список изменившихся зависимостей у пакетов (было
две синхронные или почти синхронные пересборки сизифа с alt78 и alt79,
так что изменившиеся зависимости известны точно или почти точно).
Я этот список выборочно прокомментирую.

[-- Attachment #1.2: bilode.diff.gz --]
[-- Type: application/x-gzip, Size: 6176 bytes --]

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

Re: [devel] rpm 4.0.4-alt79

[Alexey Tourbin]

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

>  SuSEfirewall2-3.6_SVNr175-alt0	Requires	coreutils
> -SuSEfirewall2-3.6_SVNr175-alt0	Requires	module-init-tools
>  SuSEfirewall2-3.6_SVNr175-alt0	Requires	perl(Net/DNS.pm)

shell.req выдает честное предупреждение, что имеется "конфликт" между
функцией внутри пакета и executable за пределами пакета.  Этот конфликт
решается в пользу функции внутри пакета, потому что как бы считается,
что связи внутри пакета сильнее, чем между пакетами.  Однако это грубое
эвристическое правильно делает не всегда то, что нужно.

shell.req: /usr/src/tmp/SuSEfirewall2-buildroot/sbin/SuSEfirewall2: modprobe() is possibly used before its definition
shell.req: /usr/src/tmp/SuSEfirewall2-buildroot/sbin/SuSEfirewall2: modprobe() has execuatable candidate: modprobe -> module-init-tools (skip)
shell.req: /usr/src/tmp/SuSEfirewall2-buildroot/etc/sysconfig/scripts/SuSEfirewall2-qdisc: modprobe() is possibly defined in /usr/src/tmp/SuSEfirewall2-buildroot/sbin/SuSEfirewall2
shell.req: /usr/src/tmp/SuSEfirewall2-buildroot/etc/sysconfig/scripts/SuSEfirewall2-qdisc: modprobe() has execuatable candidate: modprobe -> module-init-tools (skip)

Вот кусочек скрипта /sbin/SuSEfirewall2:

   271  if [ "$MODE" = debug ]; then
   272      IPTABLES="iptables"
   273      iptables()
   274      {
   275          echo iptables "$@"
   276      }
   277      IP6TABLES="ip6tables"
   278      ip6tables()
   279      {
   280          echo ip6tables "$@"
   281      }
   282      TC="tc"
   283      tc()
   284      {
   285          echo tc "$@"
   286      }
   287      modprobe()
   288      {
   289          echo modprobe "$@"
   290      }
   291  else

Функция modprobe имеет приоритет над внешней командой modprobe.

Здесь меня смущает то, что функция modprobe определена условно,
и диагностика "used before its definition" по-видимому, неправильная.
Я ещё над этим подумаю, но в целом чуда здесь ждать не следует.
То есть rpm-build сработал скорее правильно.

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

[devel] alsa-utils-1.0.14-alt3

[Alexey Tourbin]

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

>  alsa-utils-1.0.14-alt3	Requires	gawk
> -alsa-utils-1.0.14-alt3	Requires	gettext
>  alsa-utils-1.0.14-alt3	Requires	grep

Аналогичная ситуация -- определена функция gettext(), которая
"конкурирует" с /usr/bin/gettext.

shell.req: /usr/src/tmp/alsa-utils-buildroot/usr/sbin/alsaconf: gettext() is possibly used before its definition
shell.req: /usr/src/tmp/alsa-utils-buildroot/usr/sbin/alsaconf: gettext() has execuatable candidate: gettext -> gettext (skip)

    33  # i18n stuff
    34  if test "$USE_NLS" = "yes" && which gettext > /dev/null; then
    35    xecho() {
    36      gettext -s "$*"
    37    }
    38  else
    39    xecho() {
    40      echo "$*"
    41    }
    42    gettext() {
    43      echo -n "$*"
    44    }
    45  fi

Пока прошу в связи с этим ничего не делать.

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

[devel] backupninja-0.9.4-alt1

[Alexey Tourbin]

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

>  backupninja-0.9.4-alt1	Requires	findutils
> -backupninja-0.9.4-alt1	Requires	glibc-utils
>  backupninja-0.9.4-alt1	Requires(rpmlib)	rpmlib(CompressedFileNames) <= 3.0.4-1

shell.req: /usr/src/tmp/backupninja-buildroot/usr/sbin/backupninja: getconf() is possibly defined in /usr/src/tmp/backupninja-buildroot/usr/lib/backupninja/tools
shell.req: /usr/src/tmp/backupninja-buildroot/usr/sbin/backupninja: getconf() has execuatable candidate: getconf -> glibc-utils (skip)

shell.req: /usr/src/tmp/backupninja-buildroot/usr/sbin/ninjahelper: getconf() is possibly defined in /usr/src/tmp/backupninja-buildroot/usr/lib/backupninja/tools
shell.req: /usr/src/tmp/backupninja-buildroot/usr/sbin/ninjahelper: getconf() has execuatable candidate: getconf -> glibc-utils (skip)

Зависимость на glibc-utils исчезла правильно.

/usr/lib/backupninja/tools:
    40  function getconf() {
    41          CURRENT_PARAM=$1
    42          ret=`awk -f $libdirectory/parseini S=$CURRENT_SECTION P=$CURRENT_PARAM $CURRENT_CONF_FILE`
    43          # if nothing is returned, set the default
    44          if [ "$ret" == "" -a "$2" != "" ]; then
    45                  ret="$2"
    46          fi
    47  
    48          # replace * with %, so that it is not globbed.
    49          ret="${ret//\\*/__star__}"
    50  
    51          # this is weird, but single quotes are needed to 
    52          # allow for returned values with spaces. $ret is still expanded
    53          # because it is in an 'eval' statement.
    54          eval $1='$ret'
    55  }

/usr/sbin/backupninja:
   420  . $libdirectory/tools
   ...
   426  getconf configdirectory /etc/backup.d
   427  getconf scriptdirectory /usr/share/backupninja

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

[devel] bmpx-devel-0.40.9-alt1

[Alexey Tourbin]

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

>  bmpx-devel-0.40.9-alt1	Provides	pkgconfig(bmp-2.0) = 0.40.9
> +bmpx-devel-0.40.9-alt1	Requires	libdbus-devel
> +bmpx-devel-0.40.9-alt1	Requires	libdbus-glib-devel
>  bmpx-devel-0.40.9-alt1	Requires	pkgconfig(dbus-1)

$ rpmpeek bmpx-devel-0.40.9-alt1.i586.rpm grep Libs: ./usr/lib/pkgconfig/bmp-2.0.pc
Libs: -ldbus-1 -ldbus-glib-1
$ rpmpeek bmpx-devel-0.40.9-alt1.i586.rpm grep Requires: ./usr/lib/pkgconfig/bmp-2.0.pc
Requires: dbus-1 dbus-glib-1 glib-2.0
$

В принципе, с одной стороны, зависимости, прожденные через Libs,
во многих случаях дублируют зависимости указанные в Requires.
В данном случае напр. добавилась зависимость на libdbus-devel
при том, что уже была зависимость на pkgconfig(dbus-1).
С другой стороны, ничего плохого в более жестких зависимостях
у devel-пакетов я пока не вижу.

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

[devel] compiz-devel-0.6.2-alt2

[Alexey Tourbin]

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

>  compiz-devel-0.6.2-alt2	Requires	compiz = 0.6.2-alt2
> +compiz-devel-0.6.2-alt2	Requires	libX11-devel
> +compiz-devel-0.6.2-alt2	Requires	libXrender-devel
>  compiz-devel-0.6.2-alt2	Requires	pkgconfig(ice)

$ rpmpeek compiz-devel-0.6.2-alt2.i586.rpm sh -c 'grep ^Libs:.\*-l ./usr/lib/pkgconfig/*.pc'
./usr/lib/pkgconfig/libdecoration.pc:Libs: -lXrender -lX11 -ldecoration
$

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

[devel] compizconfig-python-devel-0.6.0-alt1

[Alexey Tourbin]

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

>  compizconfig-python-devel-0.6.0-alt1	Requires	compizconfig-python = 0.6.0-alt1
> +compizconfig-python-devel-0.6.0-alt1	Requires	glib2-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libICE-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libSM-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libXcomposite-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libXdamage-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libXfixes-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libXinerama-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libXrandr-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libcompizconfig-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libstartup-notification-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libxml2-devel
> +compizconfig-python-devel-0.6.0-alt1	Requires	libxslt-devel
>  compizconfig-python-devel-0.6.0-alt1	Requires	pkgconfig(glib-2.0) >= 2.6

$ rpmpeek compizconfig-python-devel-0.6.0-alt1.i586.rpm sh -c 'grep ^Libs:.\*-l ./usr/lib/pkgconfig/*.pc'
Libs: -lcompizconfig -lXcomposite -lXdamage -lXrandr -lXinerama -lSM -lxslt -lstartup-notification-1 -lXfixes -lICE -lxml2 -lglib-2.0 -lcompizconfig
$

Слишком много библиотек указано в Libs.  Часть из них, наверное, нужно
переместить в Libs.private.  Общий принцип примерно такой: в Libs нужно
указывать только те библиотеки, функции которых явно подцепляются из
хедеров этого же *-devel пакета.  На практике это чаще всего означает,
что в Libs нужно указывать только одну саму эту библиотеку, которая
лежит в пакете.  Однако здесь бывают тонкости.  Если в хедерах явно
или косвенно используются функции их других хедеров (из других пакетов),
то это может дополнительно потребовать линковки с соответствующими
библиотеками.

Напр.

/usr/include/this.h:
#include <that.h>
#define this_foo() \
	that_foo()

/usr/lib/pkgconfig/this.pc:
Requires: that
Libs: -lthis -lthat

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

[devel] emerald-devel-0.5.2-alt1

[Alexey Tourbin]

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

>  emerald-devel-0.5.2-alt1	Provides	pkgconfig(emeraldengine) = 0.5.2
> +emerald-devel-0.5.2-alt1	Requires	compiz-devel
>  emerald-devel-0.5.2-alt1	Requires	emerald = 0.5.2-alt1
> +emerald-devel-0.5.2-alt1	Requires	fontconfig-devel
> +emerald-devel-0.5.2-alt1	Requires	glib2-devel
> +emerald-devel-0.5.2-alt1	Requires	libX11-devel
> +emerald-devel-0.5.2-alt1	Requires	libXrender-devel
> +emerald-devel-0.5.2-alt1	Requires	libatk-devel
> +emerald-devel-0.5.2-alt1	Requires	libcairo-devel
> +emerald-devel-0.5.2-alt1	Requires	libfreetype-devel
> +emerald-devel-0.5.2-alt1	Requires	libgtk+2-common-devel
> +emerald-devel-0.5.2-alt1	Requires	libgtk+2-devel
> +emerald-devel-0.5.2-alt1	Requires	libpango-devel
> +emerald-devel-0.5.2-alt1	Requires	libstartup-notification-devel
> +emerald-devel-0.5.2-alt1	Requires	libwnck-devel
>  emerald-devel-0.5.2-alt1	Requires	pkgconfig(gtk+-2.0) >= 2.8.0
> @@ -24466,2 +24492,3 @@
>  emerald-devel-0.5.2-alt1	Requires	pkgconfig(xrender) >= 0.8.4
> +emerald-devel-0.5.2-alt1	Requires	zlib-devel
>  emerald-devel-0.5.2-alt1	Requires(rpmlib)	rpmlib(CompressedFileNames) <= 3.0.4-1

В Libs: указано очень много библиотек.
Наверное, большую их часть нужно переместит в Libs.private.

$ rpmpeek emerald-devel-0.5.2-alt1.i586.rpm sh -c 'grep ^Libs:.\*-l ./usr/lib/pkgconfig/*.pc'
Libs: -lwnck-1 -lgtk-x11-2.0 -lstartup-notification-1 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -ldecoration -lXrender -lX11 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lfontconfig -lfreetype -lz -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
$ 

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

[devel] etcnet-0.9.4-alt1

[Alexey Tourbin]

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

>  etcnet-0.9.4-alt1	Provides	network-config-subsystem
> -etcnet-0.9.4-alt1	Requires	/etc/rc.d/init.d(ExecIfExecutable)
> -etcnet-0.9.4-alt1	Requires	/etc/rc.d/init.d(SourceIfNotEmpty)
> -etcnet-0.9.4-alt1	Requires	/etc/rc.d/init.d(is_yes)
>  etcnet-0.9.4-alt1	Requires	bash

Здесь вот какой неприятный катаклизм: некоторые функции, стандартные
для /etc/init.d/functions, где-то определяются в этом пакете повторно.

/etc/net/scripts/functions:
   101  ExecIfExecutable()
   102  {
   103          local f
   104          f="$1"
   105          shift
   106          [ -x "$f" ] && "$f" "$@"
   107  }

/etc/rc.d/init.d/network:
     7  # ALTLinux: Do not load RH compatibility interface.
     8  WITHOUT_RC_COMPAT=1
     9
    10  SCRIPTDIR=/etc/net/scripts
    11  if [ ! -s $SCRIPTDIR/functions ]; then
    12          echo "Error: $SCRIPTDIR/functions not found!"
    13          exit 1
    14  fi
    15  export VERBOSE=on
    16  export PROGRESS=on
    17  # In certain cases we receive preset variables, some of those are not
    18  # what we want to accept.
    19  export HOST=
    20  . $SCRIPTDIR/functions
    21  pickup_defaults
    22  . $SCRIPTDIR/functions-fw
    23  SourceIfNotEmpty /etc/sysconfig/network
    24  export IFACEDIR SCRIPTDIR NETPROFILE NETHOST
    25  LOCKFILE=/var/lock/subsys/network

Другими словами, в скрипте /etc/rc.d/init.d/network "стандартная
библиотека" /etc/rc.d/init.d/functions вообще не подключается,
и, таким образом, ослабление зависимостей на /etc/rc.d/init.d(...)
в данном случае правильное.

Но я не уверен, что это правильно в общем случае.  То есть здесь
конфликтуют два механизма разрешение зависимостей: 1) через определение
функции в другом файле в пределах одного пакета; 2) через
.../.provides.sh с явным списком функций, которые могут использовать
скрипты в этом каталоге.  Я не знаю, какой из этих мезанизмов должен
иметь приоритет.  Фактически имеет место разрешение неопределенности
("мы слишком мало знаем"), поэтому однозначно правильного ответа быть
не может.  Может быть лишь "более правильный" ответ, то есть можно
найти более приемлемый ответ для большего количества случаев.

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

Re: [devel] etcnet-0.9.4-alt1

[Denis Ovsienko]

> >  etcnet-0.9.4-alt1	Provides	network-config-subsystem
> > -etcnet-0.9.4-alt1	Requires	/etc/rc.d/init.d
> > (ExecIfExecutable) -etcnet-0.9.4-alt1
> > Requires	/etc/rc.d/init.d(SourceIfNotEmpty)
> > -etcnet-0.9.4-alt1	Requires	/etc/rc.d/init.d(is_yes)
> > etcnet-0.9.4-alt1	Requires	bash
> 
> Здесь вот какой неприятный катаклизм: некоторые функции, стандартные
> для /etc/init.d/functions, где-то определяются в этом пакете повторно.

Это не дубль, а самостоятельная ветвь развития. Кроме взятого из
init.d/functions там улучшилось и добавилось ещё много чего.

[...]
> Другими словами, в скрипте /etc/rc.d/init.d/network "стандартная
> библиотека" /etc/rc.d/init.d/functions вообще не подключается,

Совершенно верно. Это уже года полтора-два как сложилось.

> и, таким образом, ослабление зависимостей на /etc/rc.d/init.d(...)
> в данном случае правильное.
> 
> Но я не уверен, что это правильно в общем случае.  То есть здесь
> конфликтуют два механизма разрешение зависимостей: 1) через
> определение функции в другом файле в пределах одного пакета; 2) через
> .../.provides.sh с явным списком функций, которые могут использовать
> скрипты в этом каталоге.  Я не знаю, какой из этих мезанизмов должен
> иметь приоритет.  Фактически имеет место разрешение неопределенности
> ("мы слишком мало знаем"), поэтому однозначно правильного ответа быть
> не может.  Может быть лишь "более правильный" ответ, то есть можно
> найти более приемлемый ответ для большего количества случаев.

Вот этого я так и не понял. Мне нужно будет регулировать etcnet.spec или
можно оставить как есть?

-- 
    DO4-UANIC

Re: [devel] etcnet-0.9.4-alt1

[Alexey Tourbin]

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

On Sat, Nov 03, 2007 at 11:28:01PM +0300, Denis Ovsienko wrote:
> Вот этого я так и не понял. Мне нужно будет регулировать etcnet.spec или
> можно оставить как есть?

Оставить как есть.

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

[devel] f-spot-0.3.5-alt2 (mono)

[Alexey Tourbin]

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

>  f-spot-0.3.5-alt2	Provides	/usr/lib/f-spot/libfspotjpegtran.so.0
> -f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.21188
> +f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.18552
>  f-spot-0.3.5-alt2	Provides	mono(NDesk.DBus) = 1.0.0.0
> @@ -27252,3 +27276,3 @@
>  f-spot-0.3.5-alt2	Provides	mono(google-sharp) = 0.1.0.0
> -f-spot-0.3.5-alt2	Provides	mono(libgphoto2-sharp) = 1.0.2861.21205
> +f-spot-0.3.5-alt2	Provides	mono(libgphoto2-sharp) = 1.0.2862.18570
>  f-spot-0.3.5-alt2	Requires	bash

У mono "плавают" зависимости, это уже не первый раз такое вылезает,
а почему я прямо сейчас сказать не могу.  Гадость там какая-то
определённая имеется.

Я прошу уважаемых товарищей maintainer'ов собрать побольше (полезных)
mono-пакетов, чтобы regression тестирование давало больше информации
для выявления закономерностей.

У меня где-то в todo имеется rpm-build-mono, но поскольку кажется что
специалистов по этому делу особо нет и многие моновские пакеты
собираются по принципу довести сборку до победного конца и при случае
бессистемно захачить что-нибудь в процессе, то я не знаю, с кем это
обсудить.

Тема такая: синхронизация *.dll и *.dll.config файлов на предмет
разрешения зависимостей в soname'ы.

Например в last-exit.spec используется вот такая диковатая конструкция:

    25  # find out versions of DllImport'ed libraries
    26  BuildRequires(pre): libnotify libX11
    27  %define libnotify_so %(rpm -ql libnotify | fgrep -m1 otify.so. | xargs basename)
    28  %define libX11_so %(rpm -ql libX11 | fgrep -m1 libX11.so. | xargs basename)
    29  %define libc_so %(rpm -ql glibc-core | fgrep -m1 libc.so | xargs basename)
    30  %define libgdk_so %(rpm -ql libgtk+2 | fgrep -m1 gdk-x11-2.0 | xargs basename)
    31  %ifarch x86_64
    32  %define bits ()(64bit)
    33  %else
    34  %define bits %nil
    35  %endif
    36  Requires: %libnotify_so%bits %libX11_so%bits %libc_so%bits %libgdk_so%bits
    37  
    38  
    39  %description
    40  A free GTK-based Last.fm player.
    41  
    42  %prep
    43  %setup
    44  sed -i '/DllImport/s/"notify"/"%libnotify_so"/' src/*.cs
    45  sed -i '/DllImport/s/"libX11"/"%libX11_so"/' src/*.cs
    46  sed -i '/DllImport/s/"libc"/"%libc_so"/' src/*.cs
    47  sed -i '/DllImport/s/"gdk-x11-2.0"/"%libgdk_so"/' src/*.cs

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

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Andrey Rahmatullin]

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

On Sat, Nov 03, 2007 at 02:26:41AM +0300, Alexey Tourbin wrote:
> > -f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.21188
> > +f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.18552

А зачем зависимость на четвёртый знак?
Официально четвёртый знак можно менять не ломая ABI, а ставить
AssemblyVersion("1.0.*") даже рекомендуют (при этом компилятор от NetFX
ставит 3-е число от дня, а 4-е случайным).

В f-spot::FlickrNet/AssemblyInfo.cs наблюдаем
[assembly: AssemblyVersion("2.1.2.*")], чтд.


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

Диалап и медленно и дорого и не комфортно для остальных членов семьи...
		-- genix in community@

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Alexey Tourbin]

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

On Sat, Nov 03, 2007 at 02:04:16PM +0500, Andrey Rahmatullin wrote:
> On Sat, Nov 03, 2007 at 02:26:41AM +0300, Alexey Tourbin wrote:
> > > -f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.21188
> > > +f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.18552
> 
> А зачем зависимость на четвёртый знак?
> Официально четвёртый знак можно менять не ломая ABI, а ставить

Где прочитать официальное про разрешение версий?

> AssemblyVersion("1.0.*") даже рекомендуют (при этом компилятор от NetFX
> ставит 3-е число от дня, а 4-е случайным).

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Andrey Rahmatullin]

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

On Sat, Nov 03, 2007 at 10:10:24PM +0300, Alexey Tourbin wrote:
> > А зачем зависимость на четвёртый знак?
> > Официально четвёртый знак можно менять не ломая ABI, а ставить
> Где прочитать официальное про разрешение версий?
Ну.. MSDN..
http://msdn2.microsoft.com/en-us/library/system.version.aspx


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

<wRAR> зато по-прежнему модно су-без-минуса
<Lost> m31: юзай _только_ su -
<wRAR> ну вот и где об этом написано?
<Lost> wRAR: в любой книжке по убунте
<php-coder> wRAR: добавь в фортунки будет хоть куда сослаться :)

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Alexey Tourbin]

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

On Sun, Nov 04, 2007 at 02:27:49PM +0500, Andrey Rahmatullin wrote:
> On Sat, Nov 03, 2007 at 10:10:24PM +0300, Alexey Tourbin wrote:
> > > А зачем зависимость на четвёртый знак?
> > > Официально четвёртый знак можно менять не ломая ABI, а ставить
> > Где прочитать официальное про разрешение версий?
> Ну.. MSDN..
> http://msdn2.microsoft.com/en-us/library/system.version.aspx

Я не понял, сколько цифр необходимо и достаточно сохранить для
разрешения зависимостей -- две или три?  То есть где в mono/
находится код загрузчика зависимостей, который определят,
подходит версия или нет, если требуемая и имеющаяся версии
в точности не совпадают?

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Andrey Rahmatullin]

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

On Sun, Nov 04, 2007 at 05:44:51PM +0300, Alexey Tourbin wrote:
> Я не понял, сколько цифр необходимо и достаточно сохранить для
> разрешения зависимостей -- две или три?  То есть где в mono/
> находится код загрузчика зависимостей, который определят,
> подходит версия или нет, если требуемая и имеющаяся версии
> в точности не совпадают?
Так.
Я почитал умных книжек и понял, что неверно всё это дело понимал.
Во-1-х, Рихтер явно рекомендует выносить "1.0.*" из AssemblyInfo.cs и
писать честные версии.
Во-2-х, версии для библиотек в GAC, _кроме стандартных_
(mono/metadata/assembly.c::framework_assemblies[]) проверяются целиком.
Версии для библиотек не в GAC (т.е. локальных) не проверяются вообще.

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

<Lost> Force the use, Luke :)

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Alexey Tourbin]

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

On Sun, Nov 04, 2007 at 11:38:42PM +0500, Andrey Rahmatullin wrote:
> Я почитал умных книжек и понял, что неверно всё это дело понимал.
> Во-1-х, Рихтер явно рекомендует выносить "1.0.*" из AssemblyInfo.cs и
> писать честные версии.
> Во-2-х, версии для библиотек в GAC, _кроме стандартных_
> (mono/metadata/assembly.c::framework_assemblies[]) проверяются целиком.
> Версии для библиотек не в GAC (т.е. локальных) не проверяются вообще.

У меня пока появилась такая идея: писать Requires на эти стандартные
библиотеки с двумя цифрами, а Provides в двух штуках -- как с двумя,
так и с четырьмя цифрами.  Т.е.

Requires: mono(mscorlib) = 1.0

Provides: mono(mscorlib) = 1.0
Provides: mono(mscorlib) = 1.0.5000.0

Кстати, сейчас уже есть хак в зависимостях на тему "неподходящих черырех
цифр" у стандартных *.dll файлов.

/usr/lib/rpm/mono.req:
    73                                  # Allow rpm deps to be resolved for 1.0 profile version
    74                                  if (VERSION=="1.0.3300.0")
    75                                          OP=">="
    76                                  else
    77                                          OP="="

Это код из mono-*/scripts/mono-find-requires.in.
Хак это потому что зависимость ">=" здесь неправильная,
просто по смыслу требуется усечение точности.

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Alexey Tourbin]

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

On Sun, Nov 04, 2007 at 11:38:42PM +0500, Andrey Rahmatullin wrote:
> Во-2-х, версии для библиотек в GAC, _кроме стандартных_
> (mono/metadata/assembly.c::framework_assemblies[]) проверяются целиком.

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

commit 06197dbbfa6382897aa697d1d6c4a68c538a80ba
Author: Alexey Tourbin <at@altlinux>
Date:   Mon Nov 5 00:37:33 2007 +0300

    use simplified 2-digit versioning for standard *.dll libraries
    
    $ ./mono.req /usr/lib/mono/gtk-sharp/gsf-sharp.dll
    mono(glib-sharp) = 2.10.0.0
    mono(mscorlib) = 1.0
    $ ./mono.prov /usr/lib/mono/1.0/mscorlib.dll
    mono(mscorlib) = 1.0.5000.0
    mono(mscorlib) = 1.0
    $

Мне теперь не особо понятно, как ты хочешь отпилить дотнет 1.0
от дотнета 2.0.  Ведь gsf-sharp по-прежнему показывает на 1.0.
Значит, прежде, чем распиливать дотнет 1.0 и дотнет 2.0, нужно
убедиться, что зависимости в сизифе явно складываются в пользу
одного из этих дотнетов.  Какого же из них?

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Andrey Rahmatullin]

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

On Mon, Nov 05, 2007 at 12:59:12AM +0300, Alexey Tourbin wrote:
> Я не совсем понял, как происходит remap версий.
Требования к версиям стандартных библиотек игнорируются, я так понял.
Ну, кроме mscorlib, наверно.

> Мне теперь не особо понятно, как ты хочешь отпилить дотнет 1.0
> от дотнета 2.0.  Ведь gsf-sharp по-прежнему показывает на 1.0.
Ну ей, например, не нужен System.Data от 1.0.

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

<henker> мда. достался хостинг. ssh древний, апач древний, пхп ваще падает на
         древней либсе..
<dottedmag> henker: дареному хостингу в libc не смотрят

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

Re: [devel] Versioning (mono)

[Ildar Mulyukov]

On 05.11.2007 17:29:43, Andrey Rahmatullin wrote:
> On Mon, Nov 05, 2007 at 12:59:12AM +0300, Alexey Tourbin wrote:
> > Я не совсем понял, как происходит remap версий.
> Требования к версиям стандартных библиотек игнорируются, я так понял.  
> Ну, кроме mscorlib, наверно.
> 
>> Мне теперь не особо понятно, как ты хочешь отпилить дотнет 1.0 от  
>> дотнета 2.0.  Ведь gsf-sharp по-прежнему показывает на 1.0.
> Ну ей, например, не нужен System.Data от 1.0.



Господа!

Изучение матчасти, как всегда, дало непревзойдённый результат. Привожу  
выдержку с M$SN:
Versioning

Each assembly has a 128-bit version number that is presented as a set  
of four decimal pieces: Major.Minor.Build.Revision
For example, an assembly might have the version number 3.5.0.126.
By default, an assembly will only use types from the exact same  
assembly (name and version number) that it was built and tested with.  
That is, if you have an assembly that uses a type from version 1.0.0.2  
of another assembly, it will (by default) not use the same type from  
version 1.0.0.4 of the other assembly. This use of both name and  
version to identify referenced assemblies helps avoid the "DLL Hell"  
problem of upgrades to one application breaking other applications.

(http://msdn2.microsoft.com/en-us/library/ms973231.aspx)

Что это означает:
1. Значащие цифры для ABI - первые две (Major.Minor). Это - строгое  
требование.
2. /Желательно/ учитывать последние две при (динамической) линковке.  
Это, боюсь, мы не потянем. И для OpenSource это не так уж важно. И  
вообще к дистростроению это не относится.
3. Различия между системными и несистемными библиотеками нет.

Так что, очевидно, придётся снова (немного) править  rpm-build-mono.  
Мэйнтейнеру f-spot просьба не беспокоиться.

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Versioning (mono)

[Alexey Tourbin]

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

On Thu, Nov 08, 2007 at 07:43:02PM +0600, Ildar Mulyukov wrote:
> Изучение матчасти, как всегда, дало непревзойдённый результат. Привожу  
> выдержку с M$SN:
> Versioning
> 
> Each assembly has a 128-bit version number that is presented as a set  
> of four decimal pieces: Major.Minor.Build.Revision
> For example, an assembly might have the version number 3.5.0.126.
> By default, an assembly will only use types from the exact same  
> assembly (name and version number) that it was built and tested with.  
> That is, if you have an assembly that uses a type from version 1.0.0.2  
> of another assembly, it will (by default) not use the same type from  
> version 1.0.0.4 of the other assembly. This use of both name and  
> version to identify referenced assemblies helps avoid the "DLL Hell"  
> problem of upgrades to one application breaking other applications.
> 
> (http://msdn2.microsoft.com/en-us/library/ms973231.aspx)
> 
> Что это означает:
> 1. Значащие цифры для ABI - первые две (Major.Minor). Это - строгое  
> требование.
> 2. /Желательно/ учитывать последние две при (динамической) линковке.  
> Это, боюсь, мы не потянем. И для OpenSource это не так уж важно. И  
> вообще к дистростроению это не относится.
> 3. Различия между системными и несистемными библиотеками нет.
> 
> Так что, очевидно, придётся снова (немного) править  rpm-build-mono.  
> Мэйнтейнеру f-spot просьба не беспокоиться.

Теперь посмотрите код mono, и объясните, так ли это в точности там
реализовано.

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

Re: [devel] Versioning (mono)

[Andrey Rahmatullin]

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

On Thu, Nov 08, 2007 at 07:43:02PM +0600, Ildar Mulyukov wrote:
> Изучение матчасти, как всегда, дало непревзойдённый результат.
Разумеется.

> Привожу  выдержку с M$SN:
Вообще-то я её здесь уже пересказывал.

> 1. Значащие цифры для ABI - первые две (Major.Minor). Это - строгое  
> требование.
Баян.
> 2. /Желательно/ учитывать последние две при (динамической) линковке.  
Не понял, что в данном случае названо динамической линковкой.
Прошу пояснить, как предлагается бороться с тем, что при обновлении
библиотеки не запустится ничего, с ней связанного, даже если её ABI не
поменялся.
> 3. Различия между системными и несистемными библиотеками нет.
Системными называются библиотеки в GAC или часть проекта Mono?
Если 1-е - читай про игнорирование версий при загрузке private asstmblies.
Если 2-е - читай mono/metadata/assembly.c::mono_assembly_remap_version()

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

>ps: куплю билеты на матч ldv--rider, т.к. пока изложенные ими
>позиции существенно противоречат друг другу ;[
Организуем на linuxfest. Билеты в танцевальный партер -- $50.
		-- aen in devel-kernel@

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

Re: [devel] Versioning (mono)

[Alexey Tourbin]

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

On Thu, Nov 08, 2007 at 09:00:11PM +0500, Andrey Rahmatullin wrote:
> > 3. Различия между системными и несистемными библиотеками нет.
> Системными называются библиотеки в GAC или часть проекта Mono?
> Если 1-е - читай про игнорирование версий при загрузке private asstmblies.
> Если 2-е - читай mono/metadata/assembly.c::mono_assembly_remap_version()

Я сделал по своеку разумению.
1) Сисок mono_assembly_remap_version захардкоден в mono.req/mono.prov и
предоставляется в двух шутках, напр.
mono(mscorlib) = 1.0
mono(mscorlib) = 1.0.5000.0
2) Библиотеки этого списка требуются в первом виде.
3) Все остальные библиотеки из /usr/lib/mono/gac предоставляются и
требуются только во втором виде.
4) Библиотеки за пределами /usr/lib/mono/gac не предоставляютсф вообще, НО
5) Работает (пока только "точный") self-requires elimination в пределах
пакета, то есть при точном совпадении версии представляемой/требуемой
библиотек она не будет требоваться.

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

Re: [devel] Versioning (mono)

[Ildar Mulyukov]

	Уважаемый Андрей,

On 08.11.2007 22:00:11, Andrey Rahmatullin wrote:
> On Thu, Nov 08, 2007 at 07:43:02PM +0600, Ildar Mulyukov wrote:
> > Изучение матчасти, как всегда, дало непревзойдённый результат.
> Разумеется.
> 
> > Привожу  выдержку с M$SN:
> Вообще-то я её здесь уже пересказывал.

К сожалению, в Вашем пересказе я не очень хорошо понял. Но тут моя вина.

> > 1. Значащие цифры для ABI - первые две (Major.Minor). Это - строгое
> > требование.
> Баян.

Я рад, что это всем уже понятно. Хотя судя по тому, какие выводы сделал  
Алексей, тут ещё надо разъяснять. :-(

> > 2. /Желательно/ учитывать последние две при (динамической) линковке.
> Не понял, что в данном случае названо динамической линковкой.

Загрузка *.dll, нужных для запуска данной программы.
> Прошу пояснить, как предлагается бороться с тем, что при обновлении  
> библиотеки не запустится ничего, с ней связанного, даже если её ABI  
> не поменялся.

Можно примеры? У меня есть обратные примеры.

> > 3. Различия между системными и несистемными библиотеками нет.
> Системными называются библиотеки в GAC или часть проекта Mono?
> Если 1-е - читай про игнорирование версий при загрузке private  
> asstmblies.
> Если 2-е - читай  
> mono/metadata/assembly.c::mono_assembly_remap_version()

В данном случае это системные в понимании Турбина (этот пункт писался  
специально для него) - те, которые выходят из mono.src.rpm

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Versioning (mono)

[Andrey Rahmatullin]

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

On Fri, Nov 09, 2007 at 11:23:35AM +0600, Ildar Mulyukov wrote:
> > > 1. Значащие цифры для ABI - первые две (Major.Minor). Это - строгое
> > > требование.
> > Баян.
> Я рад, что это всем уже понятно. Хотя судя по тому, какие выводы сделал  
> Алексей, тут ещё надо разъяснять. :-(
Я не вижу, как эти рекомендации помогут в простановке зависимостей.
Зависимости должны отражать _достаточное_ для запуску программы. В данном
случае это fully qualified имя сборки из .assembly, включающее все 4 цифры
версии.

> > > 2. /Желательно/ учитывать последние две при (динамической) линковке.
> > Не понял, что в данном случае названо динамической линковкой.
> Загрузка *.dll, нужных для запуска данной программы.
Загрузка производится кодом mono, как можно при этом что-то учитывать или
не учитывать?

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


wrar@wrars-comp ~/tmp $ >1.cs
class A { public static void Main() {  ByteFX.Data.Common.Connection c = new ByteFX.Data.Common.Connection(); }}
wrar@wrars-comp ~/tmp $ gmcs 1.cs -r:ByteFX.Data
1.cs(1,70): warning CS0219: The variable `c' is assigned but its value is never used
Compilation succeeded - 1 warning(s)
wrar@wrars-comp ~/tmp $ monodis 1.exe>1.il
wrar@wrars-comp ~/tmp $ subst 's,\(.*\.module\).*,\1,' 1.il
wrar@wrars-comp ~/tmp $ subst 's,0:7:6:2,0:7:6:0,' 1.il
wrar@wrars-comp ~/tmp $ ilasm2 1.il /exe /output:2.exe
Assembling '1.il' , no listing file, to exe --> '2.exe'

Operation completed successfully
wrar@wrars-comp ~/tmp $ mono 2.exe

** (2.exe:349): WARNING **: The following assembly referenced from
/home/wrar/tmp/2.exe could not be loaded:
     Assembly:   ByteFX.Data    (assemblyref_index=1)
     Version:    0.7.6.0
     Public Key: 0738eb9f132ed756



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

Виноват, забыл, что у меня alias xmms=beep-media-player.
		-- avm in devel@

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

Re: [devel] Versioning (mono)

[Ildar Mulyukov]

  Ну что ж, любопытно.

On 09.11.2007 11:40:13, Andrey Rahmatullin wrote:
> On Fri, Nov 09, 2007 at 11:23:35AM +0600, Ildar Mulyukov wrote:
> > > > 1. Значащие цифры для ABI - первые две (Major.Minor). Это -  
> строгое
> > > > требование.
> > > Баян.
> > Я рад, что это всем уже понятно. Хотя судя по тому, какие выводы  
> сделал
> > Алексей, тут ещё надо разъяснять. :-(
> Я не вижу, как эти рекомендации помогут в простановке зависимостей.  
> Зависимости должны отражать _достаточное_ для запуску программы. В  
> данном случае это fully qualified имя сборки из .assembly, включающее  
> все 4 цифры версии.

Это так по факту работы mono (Вы привели пример). Но по спецификации -  
не так. Вывод: баг моно?

> > > > 2. /Желательно/ учитывать последние две при (динамической)  
> линковке.
> > > Не понял, что в данном случае названо динамической линковкой.
> > Загрузка *.dll, нужных для запуска данной программы.
> Загрузка производится кодом mono, как можно при этом что-то учитывать  
> или не учитывать?
Этот пункт был просто пересказом документации, который, по идее, должен  
был подсказать, как решать нашу задачу проставления зависимостей.

> > > Прошу пояснить, как предлагается бороться с тем, что при  
> обновлении
> > > библиотеки не запустится ничего, с ней связанного, даже если её  
> ABI
> > > не поменялся.
> > Можно примеры? У меня есть обратные примеры.
> ...
> wrar@wrars-comp ~/tmp $ mono 2.exe
> ** (2.exe:349): WARNING **: The following assembly referenced from
> /home/wrar/tmp/2.exe could not be loaded:
>      Assembly:   ByteFX.Data    (assemblyref_index=1)
>      Version:    0.7.6.0
>      Public Key: 0738eb9f132ed756

Думаю, надо повесить на моно. Вы как считаете?

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] Versioning (mono)

[Andrey Rahmatullin]

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

On Fri, Nov 09, 2007 at 11:49:41AM +0600, Ildar Mulyukov wrote:
> Это так по факту работы mono (Вы привели пример). Но по спецификации -  
> не так. Вывод: баг моно?
По, гм, спецификации используется fully qualified name.
http://msdn2.microsoft.com/en-us/library/yx7xezcf(vs.80).aspx и по
ссылкам.
Везде, где сказано про отличия первых двух цифр от последних - имеется в
виду не линковка, а ABI.

> Думаю, надо повесить на моно. Вы как считаете?
Нет, см.выше.

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

В локалке шифрование тоже не помешает.
Популяция ангелов в локалке очень малочисленна.
		-- mrkooll in community@

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

Re: [devel] Versioning (mono)

[Ildar Mulyukov]

On 09.11.2007 11:59:40, Andrey Rahmatullin wrote:
> On Fri, Nov 09, 2007 at 11:49:41AM +0600, Ildar Mulyukov wrote:
>> Это так по факту работы mono (Вы привели пример). Но по спецификации  
>> - не так. Вывод: баг моно?
> По, гм, спецификации используется fully qualified name.
> http://msdn2.microsoft.com/en-us/library/yx7xezcf(vs.80).aspx и по
> ссылкам.
> Везде, где сказано про отличия первых двух цифр от последних -  
> имеется в виду не линковка, а ABI.

Похоже, что Вы правы, а я заблуждался. Хотя такое положение дел мне  
кажется странным и неестественным.

Тогда, выходит, Алексей сделал всё исключительно правильно - так, как и  
должно быть?

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Ildar Mulyukov]

On 03.11.2007 05:26:41, Alexey Tourbin wrote:
> >  f-spot-0.3.5-alt2	Provides	  
> /usr/lib/f-spot/libfspotjpegtran.so.0
> > -f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.21188
> > +f-spot-0.3.5-alt2	Provides	mono(FlickrNet) = 2.1.2.18552
> >  f-spot-0.3.5-alt2	Provides	mono(NDesk.DBus) = 1.0.0.0
> > @@ -27252,3 +27276,3 @@
> >  f-spot-0.3.5-alt2	Provides	mono(google-sharp) = 0.1.0.0
> > -f-spot-0.3.5-alt2	Provides	mono(libgphoto2-sharp) =  
> 1.0.2861.21205
> > +f-spot-0.3.5-alt2	Provides	mono(libgphoto2-sharp) =  
> 1.0.2862.18570
> >  f-spot-0.3.5-alt2	Requires	bash
> 
> У mono "плавают" зависимости, это уже не первый раз такое вылезает, а  
> почему я прямо сейчас сказать не могу.  Гадость там какая-то  
> определённая имеется.
В прошлый раз это был nemerle? С тем пакетом я могу объяснить, те  
включали SVN rev в версию сборки ^W^W^W^W^W^W^W
Нет, я вспомнил, они включали туда hash(time()). Я попросил - и они  
поправили это безобразие.

> Я прошу уважаемых товарищей maintainer'ов собрать побольше (полезных)  
> mono-пакетов, чтобы regression тестирование давало больше информации  
> для выявления закономерностей.
Алексей, я полагаю закономерности тут просто нет. Это просто некоторые  
пакеты надо пофиксить.

> У меня где-то в todo имеется rpm-build-mono, но поскольку кажется что  
> специалистов по этому делу особо нет

У меня тоже в todo имеется rpm-build-mono, вернее внимательно прочитать  
Вашу новую версию. Пока до "внимательно почитать" глаза не дошли. Но  
обсуждать проблемы и помогать я готов. Только, конечно, надо в первую  
очередь озаботить мэйнтейнера f-spot.

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

это так :-)

> то я не знаю, с кем это обсудить.

Андрей, Вы да я - уже кворум. Глядишь, Шабалин присоединится, ещё кто...

> Тема такая: синхронизация *.dll и *.dll.config файлов на предмет  
> разрешения зависимостей в soname'ы.
> Например в last-exit.spec используется вот такая диковатая  
> конструкция:
>     25  # find out versions of DllImport'ed libraries
>     26  BuildRequires(pre): libnotify libX11
>     27  %define libnotify_so %(rpm -ql libnotify | fgrep -m1  
> otify.so. | xargs basename)
>     28  %define libX11_so %(rpm -ql libX11 | fgrep -m1 libX11.so. |  
> xargs basename)
>     29  %define libc_so %(rpm -ql glibc-core | fgrep -m1 libc.so |  
> xargs basename)
>     30  %define libgdk_so %(rpm -ql libgtk+2 | fgrep -m1 gdk-x11-2.0  
> | xargs basename)
>     31  %ifarch x86_64
>     32  %define bits ()(64bit)
>     33  %else
>     34  %define bits %nil
>     35  %endif
>     36  Requires: %libnotify_so%bits %libX11_so%bits %libc_so%bits  
> %libgdk_so%bits
>     37
>     38
>     39  %description
>     40  A free GTK-based Last.fm player.
>     41
>     42  %prep
>     43  %setup
>     44  sed -i '/DllImport/s/"notify"/"%libnotify_so"/' src/*.cs
>     45  sed -i '/DllImport/s/"libX11"/"%libX11_so"/' src/*.cs
>     46  sed -i '/DllImport/s/"libc"/"%libc_so"/' src/*.cs
>     47  sed -i '/DllImport/s/"gdk-x11-2.0"/"%libgdk_so"/' src/*.cs
> Ясно, что здесь нужно системное решение для целого класса такого рода
> проблем.

Так. Видимо, речь идёт о доделке rpm-build-mono, чтобы он изменял  
*.dll.config примерно таки же образом?

Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Victor Forsyuk]

On Mon, Nov 05, 2007 at 01:29:23PM +0600, Ildar Mulyukov <ildar@altlinux.ru> wrote:

> > У меня где-то в todo имеется rpm-build-mono, но поскольку кажется что  
> > специалистов по этому делу особо нет
> 
> У меня тоже в todo имеется rpm-build-mono, вернее внимательно прочитать  
> Вашу новую версию. Пока до "внимательно почитать" глаза не дошли. Но  
> обсуждать проблемы и помогать я готов. Только, конечно, надо в первую  
> очередь озаботить мэйнтейнера f-spot.

Я не против, чтобы меня озаботили. Объясните только, чем я должен
озаботиться. :)

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Ildar Mulyukov]

On 05.11.2007 15:28:33, Victor Forsyuk wrote:
> On Mon, Nov 05, 2007 at 01:29:23PM +0600, Ildar Mulyukov  
> <ildar@altlinux.ru> wrote:
> 
> > > У меня где-то в todo имеется rpm-build-mono, но поскольку кажется  
> что
> > > специалистов по этому делу особо нет
> >
> > У меня тоже в todo имеется rpm-build-mono, вернее внимательно  
> прочитать
> > Вашу новую версию. Пока до "внимательно почитать" глаза не дошли. Но
> > обсуждать проблемы и помогать я готов. Только, конечно, надо в  
> первую
> > очередь озаботить мэйнтейнера f-spot.
> 
> Я не против, чтобы меня озаботили. Объясните только, чем я должен
> озаботиться. :)

Отлично! Постановка проблемы:
при каждой компиляции f-spot меняется Provides. Надо бы это проверить и  
найти виноватых ;)

С уважением, Ильдар
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Alexey Tourbin]

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

On Mon, Nov 05, 2007 at 03:51:36PM +0600, Ildar Mulyukov wrote:
> Отлично! Постановка проблемы:
> при каждой компиляции f-spot меняется Provides. Надо бы это проверить и  
> найти виноватых ;)

У него вообще не должно быть Provides, в смысле те которые меняются.
Это нужно решить на уровне rpm-build-mono.

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Victor Forsyuk]

On Mon, Nov 05, 2007 at 03:51:36PM +0600, Ildar Mulyukov <ildar@altlinux.ru> wrote:
> On 05.11.2007 15:28:33, Victor Forsyuk wrote:
> > On Mon, Nov 05, 2007 at 01:29:23PM +0600, Ildar Mulyukov  
> > <ildar@altlinux.ru> wrote:
> > 
> > > > У меня где-то в todo имеется rpm-build-mono, но поскольку кажется  
> > что
> > > > специалистов по этому делу особо нет
> > >
> > > У меня тоже в todo имеется rpm-build-mono, вернее внимательно  
> > прочитать
> > > Вашу новую версию. Пока до "внимательно почитать" глаза не дошли. Но
> > > обсуждать проблемы и помогать я готов. Только, конечно, надо в  
> > первую
> > > очередь озаботить мэйнтейнера f-spot.
> > 
> > Я не против, чтобы меня озаботили. Объясните только, чем я должен
> > озаботиться. :)
> 
> Отлично! Постановка проблемы:
> при каждой компиляции f-spot меняется Provides. Надо бы это проверить и  
> найти виноватых ;)

Тогда, извините, но это не ко мне. :) Я совсем не спец в моно, точко-сетке и
всей сопутствующей кучке технологий. Я собрал f-spot только из желания иметь
в сизифе еще один неплохой фото-софт.

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

Re: [devel] f-spot-0.3.5-alt2 (mono)

[Ildar Mulyukov]

On 05.11.2007 20:33:16, Victor Forsyuk wrote:
> Тогда, извините, но это не ко мне. :) Я совсем не спец в моно,  
> точко-сетке и всей сопутствующей кучке технологий. Я собрал f-spot  
> только из желания иметь в сизифе еще один неплохой фото-софт.
> 
> Ну и, наверное, по-правильному такие проблемы должны решаться не  
> патченьем или допиливанием каждого провинившегося приложения на mono,  
> а доработкой наших сборочных технологий...

хорошо, я посмотрю.
-- 
Ildar  Mulyukov,  free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
Jabber: ildar@jabber.ru
ICQ: 4334029
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

[devel] fedora-ds-1.1.0-alt0.20071030

[Alexey Tourbin]

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

>  fedora-ds-1.1.0-alt0.20071030	Provides	libslapd.so.0
> -fedora-ds-1.1.0-alt0.20071030	Requires	/etc/rc.d/init.d(failure)
> -fedora-ds-1.1.0-alt0.20071030	Requires	/etc/rc.d/init.d(success)
>  fedora-ds-1.1.0-alt0.20071030	Requires	/etc/sysconfig/network

/etc/rc.d/init.d/fedora-ds:
    35  # failure and success are not defined on some platforms
    36  type failure > /dev/null 2>&1 || {
    37  failure()
    38  {
    39      echo_n " FAILED"
    40  }
    41  }

То есть здесь аналогичная ситуация, когда функции определяются условно.
Вообще не слишком ясно, должна ли в этом случае быть зависимость на
/etc/rc.d/init.d(failure) или нет.

>  fedora-ds-adminserver-1.1.0-alt0.20071030	Provides	libds-admin-serv.so.0
> -fedora-ds-adminserver-1.1.0-alt0.20071030	Requires	/etc/rc.d/init.d(failure)
> -fedora-ds-adminserver-1.1.0-alt0.20071030	Requires	/etc/rc.d/init.d(success)
>  fedora-ds-adminserver-1.1.0-alt0.20071030	Requires	/etc/sysconfig/network

Аналогично для /etc/rc.d/init.d/fedora-ds-admin.

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

[devel] gstreamer-devel-0.10.14-alt1

[Alexey Tourbin]

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

>  gstreamer-devel-0.10.14-alt1	Requires	glib2-devel >= 2.8
> +gstreamer-devel-0.10.14-alt1	Requires	libcheck-devel
>  gstreamer-devel-0.10.14-alt1	Requires	libgstreamer = 0.10.14-alt1

$ rpmpeek gstreamer-devel-0.10.14-alt1.i586.rpm sh -c 'grep ^Libs:.\*-l ./usr/lib/pkgconfig/*.pc'
./usr/lib/pkgconfig/gstreamer-0.10.pc:Libs: -lgstreamer-0.10
./usr/lib/pkgconfig/gstreamer-base-0.10.pc:Libs: -lgstbase-0.10
./usr/lib/pkgconfig/gstreamer-check-0.10.pc:Libs: -lgstcheck-0.10 -lcheck -lm
./usr/lib/pkgconfig/gstreamer-controller-0.10.pc:Libs: -lgstcontroller-0.10
./usr/lib/pkgconfig/gstreamer-dataprotocol-0.10.pc:Libs: -lgstdataprotocol-0.10
./usr/lib/pkgconfig/gstreamer-net-0.10.pc:Libs: -lgstnet-0.10
$

Вообще-то gstreamer-check не является слишком основной функциональностью
для gstreamer-devel.  В принципе libgstcheck можно было бы отпилить в
отдельный пакет (и соответственно сделать libgstcheck-devel).  Но можно
и не отпиливать.

Вообще как правильно распилить пакеты здесь есть очень много тонких
и взаимно противоречивых соображений.  Кстати, таких случаев много.
Например, я вот думаю, не стоит ли отпилить от libcairo-devel пакет
libcairo-fb-devel (поддержка directfb).  Иначе libcairo-devel требует
libdirectfb-devel, что в некотором смысле не очень хорошо (нарушается
"ортогональность" зависимостей, если рассматривать "поддержку" разных
фич по сборке как некое подобие матроида; то есть поддержка разных фич
по сборке не должна "схлопываться" по зависимостям одна от другой).
Однако пока решил ничего не делать, что советую и в данном случае.

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

[devel] распил пакетов

[Alexey Tourbin]

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

On Sat, Nov 03, 2007 at 03:40:41AM +0300, Alexey Tourbin wrote:
> Вообще как правильно распилить пакеты здесь есть очень много тонких
> и взаимно противоречивых соображений.  Кстати, таких случаев много.
> Например, я вот думаю, не стоит ли отпилить от libcairo-devel пакет
> libcairo-fb-devel (поддержка directfb).  Иначе libcairo-devel требует
> libdirectfb-devel, что в некотором смысле не очень хорошо (нарушается
> "ортогональность" зависимостей, если рассматривать "поддержку" разных
> фич по сборке как некое подобие матроида; то есть поддержка разных фич
> по сборке не должна "схлопываться" по зависимостям одна от другой).
> Однако пока решил ничего не делать, что советую и в данном случае.

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

Я избрал курс на "принудительное замыкание" (к чему в принципе
и сводится любой "сильный" поиск зависимостей).  Замыкание дает
гарантии, которые столь желанны по разным причинам.  С другой стороны,
замыкание уводит из-под ног "разложение по базису", то есть некоторую
независимость одного *-devel пакета от другого при совместном их
использовании (что желательно учитывать напр. в BuildRequires).

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

Re: [devel] gstreamer-devel-0.10.14-alt1

[Dmitry V. Levin]

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

On Sat, Nov 03, 2007 at 03:40:41AM +0300, Alexey Tourbin wrote:
[...]
> Например, я вот думаю, не стоит ли отпилить от libcairo-devel пакет
> libcairo-fb-devel (поддержка directfb).  Иначе libcairo-devel требует
> libdirectfb-devel, что в некотором смысле не очень хорошо (нарушается
> "ортогональность" зависимостей, если рассматривать "поддержку" разных
> фич по сборке как некое подобие матроида;

Если клиентов libcairo-devel, которым для сборки не требуется
libcairo-fb-devel, наберётся достаточно, то от распила будет
практическая польза.  Если нет, то нет.


-- 
ldv

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

Re: [devel] gstreamer-devel-0.10.14-alt1

[Alexey Rusakov]

On Sat, 3 Nov 2007 17:39:11 +0300
Dmitry V. Levin wrote:

> On Sat, Nov 03, 2007 at 03:40:41AM +0300, Alexey Tourbin wrote:
> [...]
> > Например, я вот думаю, не стоит ли отпилить от libcairo-devel пакет
> > libcairo-fb-devel (поддержка directfb).  Иначе libcairo-devel требует
> > libdirectfb-devel, что в некотором смысле не очень хорошо (нарушается
> > "ортогональность" зависимостей, если рассматривать "поддержку" разных
> > фич по сборке как некое подобие матроида;
> 
> Если клиентов libcairo-devel, которым для сборки не требуется
> libcairo-fb-devel, наберётся достаточно, то от распила будет
> практическая польза.  Если нет, то нет.
Поддержка DirectFB в Cairo делалась для сборки GTK+ с поддержкой DirectFB.
В данный момент такую сборку как раз просят вернуть (и lav@ никогда не был
доволен тем, что пакет был выброшен из Сизифа). Мне кажется, если сделать
её совершенно отдельной сборкой без пакета -devel, libgtk2-directfb не
повредит ничему из имеющегося в Сизифе.

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] gstreamer-devel-0.10.14-alt1

[Alexey Tourbin]

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

On Sat, Nov 03, 2007 at 10:57:32PM +0300, Alexey Rusakov wrote:
> Dmitry V. Levin wrote:
> > On Sat, Nov 03, 2007 at 03:40:41AM +0300, Alexey Tourbin wrote:
> > > Например, я вот думаю, не стоит ли отпилить от libcairo-devel пакет
> > > libcairo-fb-devel (поддержка directfb).  Иначе libcairo-devel требует
> > > libdirectfb-devel, что в некотором смысле не очень хорошо (нарушается
> > > "ортогональность" зависимостей, если рассматривать "поддержку" разных
> > > фич по сборке как некое подобие матроида;
> > 
> > Если клиентов libcairo-devel, которым для сборки не требуется
> > libcairo-fb-devel, наберётся достаточно, то от распила будет
> > практическая польза.  Если нет, то нет.

> Поддержка DirectFB в Cairo делалась для сборки GTK+ с поддержкой DirectFB.
> В данный момент такую сборку как раз просят вернуть (и lav@ никогда не был
> доволен тем, что пакет был выброшен из Сизифа). Мне кажется, если сделать
> её совершенно отдельной сборкой без пакета -devel, libgtk2-directfb не
> повредит ничему из имеющегося в Сизифе.

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

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

[devel] gtkglarea2-devel-1.99.0-alt3

[Alexey Tourbin]

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

>  gtkglarea2-devel-1.99.0-alt3	Requires	gtkglarea2 = 1.99.0-alt3
> +gtkglarea2-devel-1.99.0-alt3	Requires	libmesa-devel
>  gtkglarea2-devel-1.99.0-alt3	Requires	pkgconfig(gtk+-2.0)

Новая зависимость проставилась правильно:

$ rpmpeek gtkglarea2-devel-1.99.0-alt3.i586.rpm sh -c 'grep ^Libs:.\*-l ./usr/lib/pkgconfig/*.pc'
Libs: -lgtkgl-2.0 -lGLU -lGL
$

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

$ rpmpeek gtkglarea2-devel-1.99.0-alt3.i586.rpm sh -c 'grep ^Requires: ./usr/lib/pkgconfig/*.pc'
Requires: gtk+-2.0
$

То есть это можно рассматривать как положительный пример того, для чего
всё это делалось, то есть для чего был реализован поиск зависимостей по
Libs.  А делалось это для замыкания зависимостей *-devel пакетов.
Замыкание означает, что если *-devel пакет поставился, то с
соответствующей библиотекой можно более ГАРАНТИРОВАННО слинковаться
стандартным способом (через *.pc файл).  А гарантии, или constraints,
это наверное как раз то, чего нужно добиваться в нашем скорбном деле
(разработки целостного репозитария пакетов).

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