Re: [devel] debuginfo, or new branch

[Alexey Tourbin <at@altlinux.ru>]

On Wed, Mar 23, 2011 at 09:43:15PM +0300, Dmitry V. Levin wrote:
> On Wed, Mar 23, 2011 at 02:56:24PM +0300, Alexey Tourbin wrote:
> > > > ясно, что всё придётся пересобирать ещё раз.
> > > Это ещё зачем?
> > 
> > Если не конфликтующие .debug симлинки/логика создания *-debuginfo пакетов,
> > то i686.
> 
> Зачем пересобирать пакеты ради i686?  Объясни, пожалуйста.

Когда базовая архитектура будет изменена с i586 на i686, то начнётся
миграция: вновь созданные пакеты будут i686, а ранее собранные пакеты
останутся i586.  Миграция закончится, когда i586 пакетов не останется.
Пересобирать пакеты ради одной только миграции на i686 не стоит, но
некая цель будет достигнута только тогда, когда все пакеты таки будут
пересобраны под i686.  По ходу дела можно придумать другие причины для
пересборки пакетов.  Такие причины уже есть.

> > А если не i686, то скоро ещё что-нибудь придумается.
> 
> Невозможно все время жить на горячем вулкане.
> Давай планировать конкретнее.

Может быть.

> > > Зря ты это затеял в таком виде.  На практике происходит искривление
> > > пакетов, теряющих поддержку разного функционала.  Риск того, что пакет,
> > 
> > Нет, не зря, когда-то это всё равно нужно было делать,
> 
> Зачем?  Ты пробовал сравнить преимущества и недостатки этой затеи?
> Даже один сломанный пакет не стоит уменьшения сборочной среды, а тут их
> не один сломанный, а неизвестно сколько.

Дело не в уменьшении сборочной среды, а в том, что у пакетов дложны быть
правильные зависимости.  Если зависимость нельзя обосновать (обычно исходя
из содержимого пакета), то она неправильная.  В некоторых пакетах
зависимости были указаны практически от балды.  Например, вчера я
пересобрал cups.  До этого cups был собран без OpenSSL и без поддержки
шифрования вообще.  Но зато в пакете libcups-devel была вручную добавлены
зависимости на libssl-devel и libgnutls-devel.  Прямо две штуки!

$ compare_packages -a -R -- libcups_1.4.6-alt2_x86%5f64.rpm -- libcups_1.4.6-alt3_x86%5f64.rpm
--- /tmp/.private/at/compare_packages.mo0iXjex0p/1      2011-03-23 22:24:29.199028521 +0300
+++ /tmp/.private/at/compare_packages.mo0iXjex0p/2      2011-03-23 22:24:29.219027615 +0300
@@ -4,12 +4,16 @@
 libc.so.6(GLIBC_2.3.4)(64bit)
 libc.so.6(GLIBC_2.4)(64bit)
 libc.so.6(GLIBC_2.7)(64bit)
+libcrypto.so.10()(64bit) >= set:pmtZsjsOeVYmwFklbWuheLr
 libgcc_s.so.1(GCC_3.0)(64bit)
+libgssapi_krb5.so.2()(64bit) >= set:kherFpMJPan5MXTYLq
+libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)
 libjpeg.so.62()(64bit) >= set:jfvZgUYgm1zeIvxjVrKLMTqQdf
 libm.so.6(GLIBC_2.2.5)(64bit)
 libpng12.so.0()(64bit) >= set:lgOKYIuUs2ffErgkPDc7jYhS0yzIHizyaV69qr1yJM1Ft2
 libpng12.so.0(PNG_12)(64bit)
 libpthread.so.0(GLIBC_2.2.5)(64bit)
+libssl.so.10()(64bit) >= set:miIR7CWxJkqI4k7FzBbKZDKv9zXPZhXcvdvnx8Nu3FiX0
 libstdc++.so.6(CXXABI_1.3)(64bit)
 libstdc++.so.6(GLIBCXX_3.4)(64bit)
 libtiff.so.4()(64bit) >= set:lihRIYpFvuQKTeyZypFUm1
$ compare_packages -a -R -- libcups-devel_1.4.6-alt2_x86%5f64.rpm -- libcups-devel_1.4.6-alt3_x86%5f64.rpm
--- /tmp/.private/at/compare_packages.D60a5VwoX0/1      2011-03-23 22:24:56.348659439 +0300
+++ /tmp/.private/at/compare_packages.D60a5VwoX0/2      2011-03-23 22:24:56.380656648 +0300
@@ -2,7 +2,5 @@
 /lib64/ld-linux-x86-64.so.2
 coreutils
 libc.so.6()(64bit) >= set:poiedc
-libcups = 1.4.6-alt2
-libgnutls-devel
-libssl-devel
+libcups = 1.4.6-alt3
 rpmlib(PayloadIsLzma)
$

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

Давай в каждый *-devel пакет добавим случайную зависимость на какой-либо
другой *-devel пакет.  Какими тебе представляются преимущества и
недостатки этой затеи?

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

Что ж, наши мнения разошлись.  Я считаю принятное решение единственно
верным, хотя, может быть, его можно было бы и отсрочить (по соображениям
создания стабильного бранча и бизнеса одной фирмы).  Впрочем, решение
было принято после истории с Requires.private, то есть, можно сказать,
не своевольно, а по объективным причинам.