Re: [devel] Когда появится новая libquicktime?

Re: [devel] Когда появится новая libquicktime?

[Igor Vlasenko]

On Wed, Jun 11, 2008 at 08:21:47PM +0400, Yury Aliaev wrote:
> Собственно вопрос: когда моё обновление libquicktime таки появится в 
> Сизифе? Если есть ещё какие-то вопросы, то я готов на них ответить. А то и 
> обсуждение прекратилось, и библиотеки не видать...

Народ пошел требовательный, требует compat библиотеку...

Юрий, я сейчас попытаюсь сделать compat-пакет и залить в Сизиф.
Если она пройдет, то как я понимаю, после этого
Дима пропустит libquicktime в Сизиф.

<complaints>
Что-то слишком жизнь майнтайнерская сложна стала...
представляя, сколько работы по хорошему, чтобы обновить
библиотеку по всем правилам, я 2 года откладывал libquicktime
на "потом". Хорошо, что взялся Юрий. Только как бы его не сломили.
</complaints>

А робота для пересборки зависимых пакетов написать легко.
Вопрос не в роботе, а в получении nmu.
Я вот в апреле nmu получал.
Запомнилось...

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Когда появится новая libquicktime?

[Igor Vlasenko]

On Thu, Jun 12, 2008 at 02:28:07AM +0700, Mikhail Gusarov wrote:
> Twas brillig at 17:50:23 11.06.2008 UTC+03 when Igor Vlasenko did gyre and gimble:
> 
>  IV> Что-то слишком жизнь майнтайнерская сложна стала...  представляя, сколько
>  IV> работы по хорошему, чтобы обновить библиотеку по всем правилам,
> 
> Так, стоп. Надо выявить проблему. Неужели это действительно занимает так много
> сил?
Апстрим из той же песочницы, что и ffmpeg :(
Версионирования не ведет,
вести его вместо апстрима действительно занимает так много сил :(
А жульничество с soname на версию будет плодить по 
compat библиотеке раз в три месяца :(


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Когда появится новая libquicktime?

[Igor Vlasenko]

On Wed, Jun 11, 2008 at 11:40:44PM +0400, Alexey I. Froloff wrote:
> * Igor Vlasenko <vlasenko@> [080611 23:22]:
> > Я вот в апреле nmu получал.
> > Запомнилось...
> Ну согласись, что повод (%update_menus/%update_descktopdb) был
> так себе.  И решалась проблема другими способами.

(%update_menus/%update_descktopdb) был выбран, поскольку
на чем-то безвредном хотелось попробовать.
На собаках, так сказать...

Дальше веселее пошло бы. Машинизация по Винтику и Шпунтику.

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

Там можно весьма нетривиальные изменения в спеках программировать,
вот например правки к спекам tomcat5:
------------------
#!/usr/bin/perl -w

require 'set_fix_homedir_macro.pl';

push @SPECHOOKS, sub {
    my ($jpp, $alt) = @_;

    # BUG to report (5.5.25 1-fc9) too
    $jpp->get_section('build')->subst(qr'%{java.home}','%{java_home}');

    # fedora specific (5.5.25 1-fc9)
    $jpp->get_section('package','')->push_body('BuildRequires: zip'."\n");

    # break build with java 1.5.0
    #Patch19: %{name}-%{majversion}-connectors-util-build.patch
    $jpp->get_section('prep')->subst(qr'%patch19 -b .p19','#%patch19 -b .p19');
    #$jpp->get_section('prep')->subst(qr'%patch20 -b .p20','#%patch20 -b .p20');
    #Patch21: %{name}-%{majversion}-acceptlangheader.patch
    $jpp->get_section('prep')->subst(qr'%patch21 -b .p21','#%patch21 -b .p21');

    # to make them 1.4, not 1.5
    $jpp->get_section('build')->subst(qr'ant\s+-Dservletapi.build="build"','ant -Dant.build.javac.source=1.4 -Dant.build.javac.target=1.4 -Dservletapi.build="build"');
    # end fedora specific 

    $jpp->get_section('package','server-lib')->push_body('Requires: jaf javamail'."\n");

    $jpp->get_section('package','')->push_body('Provides: %{name}-server = %{version}-%{release}'."\n");
    $jpp->get_section('package','')->push_body('Obsoletes: %{name}-server <= 5.5.16-alt1.1'."\n");
    $jpp->get_section('package','admin-webapps')->push_body('Provides: %{name}-admin-webapps = %{version}-%{release}'."\n");
    $jpp->raw_rename_section('admin-webapps','webapps-admin');
    # #14415
    $jpp->get_section('description','')->subst(qr'We invite you to participate in this open development project. To','');
    $jpp->get_section('description','')->subst(qr'learn more about getting involved, click here.','');


    $jpp->get_section('pre')->subst(qr'-[gu] %\{tcuid\}','');

    # a part of #%post_service %name that is not implemented there:
    # condrestart on upgrade 
    $jpp->get_section('post')->push_body('/sbin/service %name condrestart'."\n");

    # merge from old alt tomcat5:
    # do we really need all of this?
    $jpp->get_section('post','webapps')->push_body(q'/sbin/service %name condrestart
');

    $jpp->get_section('post','webapps-admin')->push_body(q'/sbin/service %name condrestart
');

    $jpp->get_section('preun','webapps')->push_body(q'[ $1 != 0 ] || /sbin/service %name condrestart
');

    $jpp->get_section('preun','webapps-admin')->push_body(q'[ $1 != 0 ] || /sbin/service %name condrestart
');

    # todo: make an extension?
    $jpp->get_section('install')->push_body('mkdir -p $RPM_BUILD_ROOT/%_altdir/
cat >>$RPM_BUILD_ROOT/%_altdir/servletapi_%{name}<<EOF
%{_javadir}/servletapi.jar	%{_javadir}/%{name}-servlet-2.4-api-%{version}.jar	20400
EOF
');
    $jpp->get_section('files','servlet-2.4-api')->push_body('%_altdir/servletapi_*'."\n");
    $jpp->get_section('post','servlet-2.4-api')->push_body('%register_alternatives servletapi_%{name}'."\n");
    $jpp->get_section('postun','servlet-2.4-api')->push_body('%unregister_alternatives servletapi_%{name}'."\n");

    $jpp->get_section('install')->push_body(
q'
%triggerpostun -- tomcat5-server <= 5.5.16-alt1.1
for i in common/classes common/endorsed common/lib shared/classes shared/lib webapps; do
if [ -d /usr/lib/tomcat5/$i ]; then
    echo "upgrade: moving old /usr/lib/tomcat5/$i to /var/lib/tomcat5/$i"
    mv -f /usr/lib/tomcat5/$i/* /var/lib/tomcat5/$i/
fi
done || :
');

}
__DATA__
todo: verify logrotate


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

[devel] Когда появится новая libquicktime?

[Yury Aliaev]

Собственно вопрос: когда моё обновление libquicktime таки появится в 
Сизифе? Если есть ещё какие-то вопросы, то я готов на них ответить. А то 
и обсуждение прекратилось, и библиотеки не видать...

Re: [devel] Когда появится новая libquicktime?

[Dmitry V. Levin]

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

On Wed, Jun 11, 2008 at 08:21:47PM +0400, Yury Aliaev wrote:
> Собственно вопрос: когда моё обновление libquicktime таки появится в 
> Сизифе? Если есть ещё какие-то вопросы, то я готов на них ответить.

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

> и обсуждение прекратилось, и библиотеки не видать...


-- 
ldv

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

Re: [devel] Когда появится новая libquicktime?

[Igor Vlasenko]

On Thu, Jun 12, 2008 at 12:45:05AM +0300, Led wrote:
> > Апстрим из той же песочницы, что и ffmpeg :(
> > Версионирования не ведет,
> 
> Вы уверены (что в ffmpeg нет версионирования библиотек)??? У меня прямо 
> противоположная информация:)

Высказывание
'Апстрим из той же песочницы, что и ffmpeg :( '
будем понимать буквально - их проекты (были?) на одном сайте.
А несколько лет назад ffmpeg, помнится, версионирования не вел.
Это сейчас остепенился.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] Когда появится новая libquicktime?

[Alexey I. Froloff]

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

* Dmitry V. Levin <ldv@> [080611 21:02]:
> > Собственно вопрос: когда моё обновление libquicktime таки появится в 
> > Сизифе? Если есть ещё какие-то вопросы, то я готов на них ответить.
> Остался вопрос, что будет с пакетами, которые выйдут из строя, как только
> это обновление libquicktime появится в репозитории.
Новая установка не пройдёт, установленные снесены не будут, если
конечно у libquicktime имя поменялось.

Мне кажется, Shared Libs Policy можно слегка ослабить в плане
создания compat пакетов.  Главное чтобы либа со старым SONAME
принудительно не выносилась из системы и не было конфликтов.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 21:41:06 11.06.2008 UTC+04 when Alexey I. Froloff did gyre and gimble:

 AIF> Мне кажется, Shared Libs Policy можно слегка ослабить в плане создания
 AIF> compat пакетов.

В каком месте? Я его сейчас слегка подправил, по поводу апстримов,
"неканонически" использующих soversion.

 AIF> Главное чтобы либа со старым SONAME принудительно не выносилась из системы
 AIF> и не было конфликтов.

Один из следующих уровеней за функциональностью - документируемость.

Классная штука, которую я люблю в Debian - это то, что просто глядя на список
пакетов, я могу очень многое о них сказать, не заглядывая внутрь и не составляя
километровые трубопроводы из rpmq и awk. Соглашения важны.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Alexey Tourbin]

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

On Thu, Jun 12, 2008 at 01:15:16AM +0700, Mikhail Gusarov wrote:
> Классная штука, которую я люблю в Debian - это то, что просто глядя на список
> пакетов, я могу очень многое о них сказать, не заглядывая внутрь и не составляя
> километровые трубопроводы из rpmq и awk. Соглашения важны.

А уж сколько я могу сказать, глядя на rpm пакеты...

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 22:53:43 11.06.2008 UTC+04 when Alexey Tourbin did gyre and gimble:

 AT> А уж сколько я могу сказать, глядя на rpm пакеты...

Просто на названия?

Алексеев Турбиных, которые делают всякие хитрые вещи с пакетами - один штук в
ближайшей окрестности, и ему наплевать на то, лежат у него в директории файлы
1.rpm, 2.rpm, 3.rpm или libfoobar-devel-i586.rpm, а сисадминов, которым эти
хитрые вещи нафиг не сдались, пока их делает один Алексей Турбин, гораздо
больше.

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

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Alexey Tourbin]

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

On Thu, Jun 12, 2008 at 01:56:21AM +0700, Mikhail Gusarov wrote:
>  AT> А уж сколько я могу сказать, глядя на rpm пакеты...
> 
> Просто на названия?
> 
> Алексеев Турбиных, которые делают всякие хитрые вещи с пакетами - один штук в
> ближайшей окрестности, и ему наплевать на то, лежат у него в директории файлы
> 1.rpm, 2.rpm, 3.rpm или libfoobar-devel-i586.rpm, а сисадминов, которым эти
> хитрые вещи нафиг не сдались, пока их делает один Алексей Турбин, гораздо
> больше.
> 
> Можно, конечно, каждого вынуждать придумывать свой любимый шелл-алиас, но это же
> просто неудобно и после десятого алиаса сисадмин уйдёт туда, где поудобнее, и
> никаких выдающихся фич для сисадмина (! не для разработчика) в альтовых
> дистрибутивах не найдётся, чтобы его удержать. Не будет юзербазы (особенно
> продвинутых юзеров и сисадминов) - не будет и нормального тестирования.

Какие соглашения в Debian имелись в виду?  Мне известно только одно
соглашение: называть с префиксом lib все пакеты, которые не имеют
end-user interaction points (т.е. библиотеки в широком смысле слова).
У нас префикс lib используется для библиотек в узком смысле слова (ELF
shared libraries).  Но для других библиотек тоже используются префиксы --
например, то, что в Debian'е называется libfoo-perl, у нас называется
perl-Foo.  Правда, у нас это соглашение менее строгое, то есть в пакет
perl-Foo могут быть запакованы и какие-то скритпы в /usr/bin.

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 23:15:12 11.06.2008 UTC+04 when Alexey Tourbin did gyre and gimble:

 AT> Какие соглашения в Debian имелись в виду?

Разные. lib<name><abiversion> и -devel, соглашение на питоньи и перловые модули,
на модули к апачу, pear etc.

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

Недавний драфт про rpm-macros - в тему, и устаканивание соглашения на имена
библиотек для сосуществования в одной системе - тоже в тему.

 AT> Правда, у нас это соглашение менее строгое, то есть в пакет perl-Foo могут
 AT> быть запакованы и какие-то скритпы в /usr/bin.

Это частенько, кстати, путает - в Debian'овых пакетах lib*-perl тоже не
запрещено складывать скрипты в /usr/bin, и их там частенько бывает сложно найти,
просто потому что не ожидаешь - практически никогда там их и не встречается
(/usr/bin/{GET,POST} в libwww-perl, конечно, запоминаются, но далеко не сразу).

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 17:50:23 11.06.2008 UTC+03 when Igor Vlasenko did gyre and gimble:

 IV> Что-то слишком жизнь майнтайнерская сложна стала...  представляя, сколько
 IV> работы по хорошему, чтобы обновить библиотеку по всем правилам,

Так, стоп. Надо выявить проблему. Неужели это действительно занимает так много
сил?

Как это происходит в том же пресловутом Debian:

1) Майнтайнер обновляет пакет, меняя цифирку у названия библиотеки. На этом
работа майнтайнера заканчивается.

2) После заливки пакета с новой библиотекой в репозиторий старая остаётся
болтаться в нём, пока на неё есть ссылки

3) Когда все пакеты пересоберутся с новой библиотекой, старую скрипт по
обновлению пакетов в репозитории вычищает.

В альтовой реальности это происходит более сложным образом?

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [080611 22:19]:
>  AIF> Мне кажется, Shared Libs Policy можно слегка ослабить в плане создания
>  AIF> compat пакетов.
> В каком месте? Я его сейчас слегка подправил, по поводу апстримов,
> "неканонически" использующих soversion.
Хех.  А compat-то собирать и не надо.

При сборке новой версии пакета libfoo предлагается сделать следующее:
1. Переименовать пакет libfoo в libfooM
2. Добавить в пакет libfooM Provides: libfoo = %version-%release

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

> Классная штука, которую я люблю в Debian - это то, что просто глядя на список
> пакетов, я могу очень многое о них сказать, не заглядывая внутрь и не составляя
> километровые трубопроводы из rpmq и awk. Соглашения важны.
Это потому что в Debian зависимости убогие ;-)))

-- 
Regards,
Sir Raorn.

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

Re: [devel] Когда появится новая libquicktime?

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080611 23:22]:
> Я вот в апреле nmu получал.
> Запомнилось...
Ну согласись, что повод (%update_menus/%update_descktopdb) был
так себе.  И решалась проблема другими способами.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 23:38:36 11.06.2008 UTC+04 when Alexey I. Froloff did gyre and gimble:

 AIF> При сборке новой версии пакета libfoo предлагается сделать следующее:
 AIF> 1. Переименовать пакет libfoo в libfooM
 AIF> 2. Добавить в пакет libfooM Provides: libfoo = %version-%release

 AIF> Вот тут не совсем понятно кого куда переименовывать.  Только ли
 AIF> бинарный пакет, или исходный тоже.

Сейчас уточню. binary, конечно, ведь название проекта (отражённое в имени
source-пакета) от изменения ABI не изменилось.

 AIF> Это потому что в Debian зависимости убогие ;-)))

Нет, это не потому, а вопреки. Т.е. не workaround проблемы, а дополнительная
фича.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Alexey I. Froloff]

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

* Igor Vlasenko <vlasenko@> [080611 23:42]:
> А жульничество с soname на версию будет плодить по 
> compat библиотеке раз в три месяца :(
Не надо compat.  Надо бинарный пакет тоже переименовать и нехай
себе старый живёт для неувеличения анметов.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 18:11:23 11.06.2008 UTC+03 when Igor Vlasenko did gyre and gimble:

 IV> Версионирования не ведет, вести его вместо апстрима действительно занимает
 IV> так много сил :( А жульничество с soname на версию будет плодить по compat
 IV> библиотеке раз в три месяца :(

Стоп ещё раз :) Это уже не связано с compat, как я понимаю - особенно учитывая,
что они по предложенной в драфте схеме получаются "нахаляву".

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Alexey I. Froloff]

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

* Mikhail Gusarov <dottedmag@> [080611 23:51]:
>  AIF> Вот тут не совсем понятно кого куда переименовывать.  Только ли
>  AIF> бинарный пакет, или исходный тоже.
> Сейчас уточню. binary, конечно, ведь название проекта (отражённое в имени
> source-пакета) от изменения ABI не изменилось.
Ой ли?  При обновлении libfoo.src, libfoo.bin и libfoo-devel.bin
будут благополучно вынесены из репозитария при обновлении до
libfoo.src, libfooM.bin и libfoo-devel.bin.  Поэтому libfoo.src
надо тоже в libfooM.src переименовать.  Помойму так.  Или как ещё
оставить libfoo.bin (libfooN.bin) в репозитарии (для неувеличения
анметов) если исходного пакета для него не осталось?

-- 
Regards,
Sir Raorn.

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 23:56:52 11.06.2008 UTC+04 when Alexey I. Froloff did gyre and gimble:

 AIF> Ой ли?  При обновлении libfoo.src, libfoo.bin и libfoo-devel.bin будут
 AIF> благополучно вынесены из репозитария при обновлении до libfoo.src,
 AIF> libfooM.bin и libfoo-devel.bin.

Вот, в этом и проблема. Я про неё не знал.

 AIF> Или как ещё оставить libfoo.bin (libfooN.bin) в репозитарии (для
 AIF> неувеличения анметов) если исходного пакета для него не осталось?

Так и оставить - если появляются анметы от выкидывания - оставить в
репозитории. Такой reference counting устроить.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey I Froloff <raorn-u2l5PoMzF/Uox3rIn2DAYQ@public.gmane.org> writes:

 > * Igor Vlasenko <vlasenko@> [080611 23:42]:
 >> А жульничество с soname на версию будет плодить по 
 >> compat библиотеке раз в три месяца :(
 > Не надо compat.  Надо бинарный пакет тоже переименовать и нехай
 > себе старый живёт для неувеличения анметов.

Тут есть ещё то обстоятельство, что библиотеки-то shared.
Разбивая некогда одну библиотеку на n её версий, мы в n раз уменьшаем
shareability, с неплохими шансами добиться предельного случая -- на
каждый пакет-пользователь библиотеки по уникальной её версии.
Чего тогда огород городить ?

Мне кажется, что следует явно оговорить (и ужесточить)время жизни
compat-библиотеки. Нынешнее 'живёт до момента выпуска стабильной
ветки' похоже на 'от сессии до сессии живут студенты весело'.

Было бы также недурно легализовать в полиси такую штуку,
как _договорённость_ майнтайнеров всех затронутых сменой
версии библиотеки пакетов на синхронную [в пределах какого-то
небольшого окна] пересборку.

-- 

Re: [devel] Когда появится новая libquicktime?

[Led]

Wednesday, 11 June 2008 18:11:23 Igor Vlasenko написав:
> On Thu, Jun 12, 2008 at 02:28:07AM +0700, Mikhail Gusarov wrote:
> > Twas brillig at 17:50:23 11.06.2008 UTC+03 when Igor Vlasenko did gyre
> > and gimble:
> >
> >  IV> Что-то слишком жизнь майнтайнерская сложна стала...  представляя,
> > сколько IV> работы по хорошему, чтобы обновить библиотеку по всем
> > правилам,
> >
> > Так, стоп. Надо выявить проблему. Неужели это действительно занимает так
> > много сил?
>
> Апстрим из той же песочницы, что и ffmpeg :(
> Версионирования не ведет,

Вы уверены (что в ffmpeg нет версионирования библиотек)??? У меня прямо 
противоположная информация:)

> вести его вместо апстрима действительно занимает так много сил :(
> А жульничество с soname на версию будет плодить по
> compat библиотеке раз в три месяца :(

-- 
Led

Re: [devel] Когда появится новая libquicktime?

[Led]

Wednesday, 11 June 2008 20:36:59 Igor Vlasenko написав:
> On Thu, Jun 12, 2008 at 12:45:05AM +0300, Led wrote:
> > > Апстрим из той же песочницы, что и ffmpeg :(
> > > Версионирования не ведет,
> >
> > Вы уверены (что в ffmpeg нет версионирования библиотек)??? У меня прямо
> > противоположная информация:)
>
> Высказывание
> 'Апстрим из той же песочницы, что и ffmpeg :( '
> будем понимать буквально - их проекты (были?) на одном сайте.
> А несколько лет назад ffmpeg, помнится, версионирования не вел.
> Это сейчас остепенился.

Ну если
последние 3,5 года, которые я за ним пристально слежу == сейчас
тогда да:)

-- 
Led

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 01:26:18 12.06.2008 UTC+04 when Sergey Bolshakov did gyre and gimble:

 SB> Мне кажется, что следует явно оговорить (и ужесточить)время жизни
 SB> compat-библиотеки. Нынешнее 'живёт до момента выпуска стабильной ветки'
 SB> похоже на 'от сессии до сессии живут студенты весело'.

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

 SB> Было бы также недурно легализовать в полиси такую штуку, как
 SB> _договорённость_

Как в *правилах* легализовывать *договорённость*? Правила - это нечто
выполняемое, а не разводы руками "а неплохо бы делать так".

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Michael Shigorin]

On Thu, Jun 12, 2008 at 12:11:32PM +0700, Mikhail Gusarov wrote:
>  SB> Было бы также недурно легализовать в полиси такую штуку, как
>  SB> _договорённость_
> Как в *правилах* легализовывать *договорённость*? Правила - это
> нечто выполняемое, а не разводы руками "а неплохо бы делать
> так".

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

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

Re: [devel] Когда появится новая libquicktime?

[Mikhail Gusarov]

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

Twas brillig at 11:40:18 12.06.2008 UTC+03 when Michael Shigorin did gyre and gimble:

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

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

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

0) Пройдёт join. Не проблема.

1а) Человек упакует библиотеку, посмотрев на десяток таких же из Сизифа, зальёт
её, и получит волну презрения и ненависти, ибо окажется, что те библиотеки, на
которые он посмотрел - неправильные, и сейчас делают не так. Минус один человек
в community.

1б) Человек посмотрит на 10 библиотек, заметит, что они какие-то все разные,
спросит в списке рассылки и неделю будет ждать, пока утихнет флейм, после чего
плюнет. Минус один человек в community.

1в) Человек посмотрит на правила и запакует библиотеку.

2а) Если правила написаны просто так - получит волну презрения по сценарию
1а. Минус один человек.

2б) Если правила написаны для того, чтобы придерживаться их, то на этом всё
закончится.

-- 
JID: dottedmag@altlinux.org / dottedmag@jabber.dottedmag.net

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

Re: [devel] Когда появится новая libquicktime?

[Sergey Bolshakov]

>>>>> "Mikhail" == Mikhail Gusarov <dottedmag-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > Twas brillig at 01:26:18 12.06.2008 UTC+04 when Sergey Bolshakov did gyre and gimble:
 SB> Мне кажется, что следует явно оговорить (и ужесточить)время жизни
 SB> compat-библиотеки. Нынешнее 'живёт до момента выпуска стабильной ветки'
 SB> похоже на 'от сессии до сессии живут студенты весело'.

 > Можно какой-нибудь срок вписать. "Если библиотека болтается больше двух месяцев
 > - выкидывается, а все непересобравшиеся получают анметы".

 SB> Было бы также недурно легализовать в полиси такую штуку, как
 SB> _договорённость_

 > Как в *правилах* легализовывать *договорённость*? Правила - это нечто
 > выполняемое, а не разводы руками "а неплохо бы делать так".

Вот уж не думал, что поставлю в тупик. план таков:
1) нулевым пунктом в полиси вписать, что надцать версий
одной и той же библиотеки -- зло, и следует его избегать;

2) механизм может быть таким:
- майнтайнер libfoo [либо иное заинтересованное лицо] оповещает в
  свободной форме заинтересованных лиц о желательности изменения
  версии библиотеки, проводятся предварительные переговоры о
  возможности скоординированного вброса всего хозяйства, при неуспехе
  вступает в действие сценарий, нарисованный в нынешней policy;
- факт достижения соглашения о вбросе фиксируется формально
  в виде серии писем в devel@ или выделенной для этого рассыле
  с объявлением существа дела, сроков и т.п и подтверждается
  подписями майнтайнеров всех затронутых пакетов;
- производится вброс.

-- 

Re: [devel] Когда появится новая libquicktime?

[Хихин Руслан]

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

Здравствуйте Mikhail Gusarov
  В сообщении от 12 июня 2008 Mikhail Gusarov написал(a):
> Как в *правилах* легализовывать *договорённость*?

1 При общем согласии заинтересованных лиц - вариант 1
2 При отсутствии объявленных протесстов - вариант 2
3 При согласии большинства мантейнеров - вариант 3

Вопрос не в этом - вопрос в том, что-бы полиси 
отражало "правильную точку зрения". А вот в правильности его 
похоже надо кого-то убеждать.
 Обычно такое бывает, когда разные взгляды на решение проблемы, 
отражают разные ситуации, которые видятся разными людьми (не 
хотелось упоминать штамп "точки зрения" но его первоначальный 
стереометрический смысл "точки зрения из разных наблюдательных 
пунктов" наиболее ёмко демонстрирует ситуацию :) )


-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Когда появится новая libquicktime?

[Хихин Руслан]

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

Здравствуйте 
  В сообщении от 12 июня 2008 Хихин Руслан написал(a):
> Здравствуйте Mikhail Gusarov

А по существу почему-то изменения  с libquicktime задело даже 
xdtv :

$ sudo apt-get install xdtv
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие дополнительные пакеты будут установлены:
  libmjpegtools libquicktime libquicktime098-compat mjpegtools 
transcode
Следующие НОВЫЕ пакеты будут установлены:
  libmjpegtools libquicktime libquicktime098-compat mjpegtools 
transcode xdtv
0 будет обновлено, 6 новых установлено, 0 пакетов будет удалено и 
0 не будет обновлено.
Необходимо получить 0B/4590kB архивов.
После распаковки потребуется дополнительно 11,3MB дискового 
пространства.
Продолжить? [Y/n] y
Совершаем изменения...
Preparing...                 
########################################### [100%]
file /usr/lib64/libquicktime/lqt_audiocodec.so conflicts between 
attempted installs of libquicktime-1.0.2-alt1 and 
libquicktime098-compat-0.9.8-alt8
file /usr/lib64/libquicktime/lqt_mjpeg.so conflicts between 
attempted installs of libquicktime-1.0.2-alt1 and 
libquicktime098-compat-0.9.8-alt8
file /usr/lib64/libquicktime/lqt_png.so conflicts between 
attempted installs of libquicktime-1.0.2-alt1 and 
libquicktime098-compat-0.9.8-alt8
file /usr/lib64/libquicktime/lqt_rtjpeg.so conflicts between 
attempted installs of libquicktime-1.0.2-alt1 and 
libquicktime098-compat-0.9.8-alt8
file /usr/lib64/libquicktime/lqt_videocodec.so conflicts between 
attempted installs of libquicktime-1.0.2-alt1 and 
libquicktime098-compat-0.9.8-alt8
E: Ошибка во время исполнения транзакции

Так-что непонятно - что в результате лучше - явные unmets или 
скрытые conflicts.



-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Когда появится новая libquicktime?

[Andrey Rahmatullin]

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

On Thu, Jun 12, 2008 at 09:55:36PM +0400, Хихин Руслан wrote:
> А по существу почему-то изменения  с libquicktime задело даже 
> xdtv :
С чего бы.

> file /usr/lib64/libquicktime/lqt_audiocodec.so conflicts between 
> attempted installs of libquicktime-1.0.2-alt1 and 
> libquicktime098-compat-0.9.8-alt8
#15979

> Так-что непонятно - что в результате лучше - явные unmets или 
> скрытые conflicts.
Лучше использовать моск при сборке.

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

ЗЫ: Выкиньте из сизифа CrayFIX, please. Не дай бог ктонть поставит, это теперь
такие грабли.  Хоть Conflicts и прописан, а всегда найдутся умельцы.
		-- cray in devel@

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

Re: [devel] Когда появится новая libquicktime?

[Хихин Руслан]

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

Здравствуйте Andrey Rahmatullin
  В сообщении от 12 июня 2008 Andrey Rahmatullin написал(a):
> > xdtv :
>
> С чего бы.
Следующие НОВЫЕ пакеты будут установлены:
  libmjpegtools libquicktime libquicktime098-compat mjpegtools 
transcode xdtv

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

mjpegtools -> libquicktime
transcode ->  libquicktime098-compat 

-- 
С  уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] Когда появится новая libquicktime?

[Yury Aliaev]

Mikhail Gusarov scripsit:
> Twas brillig at 17:50:23 11.06.2008 UTC+03 when Igor Vlasenko did gyre and gimble:
> 
>  IV> Что-то слишком жизнь майнтайнерская сложна стала...  представляя, сколько
>  IV> работы по хорошему, чтобы обновить библиотеку по всем правилам,
> 
> Так, стоп. Надо выявить проблему. Неужели это действительно занимает так много
> сил?
> 
> Как это происходит в том же пресловутом Debian:
> 
> 1) Майнтайнер обновляет пакет, меняя цифирку у названия библиотеки. На этом
> работа майнтайнера заканчивается.
> 
> 2) После заливки пакета с новой библиотекой в репозиторий старая остаётся
> болтаться в нём, пока на неё есть ссылки
> 
> 3) Когда все пакеты пересоберутся с новой библиотекой, старую скрипт по
> обновлению пакетов в репозитории вычищает.

Увы, в Альте такого скрипта нет... Поэтому приходится двадцать раз 
подумать, прежде чем изменить цифирЬку в названии библиотеки.

> 
> В альтовой реальности это происходит более сложным образом?

Re: [devel] Когда появится новая libquicktime?

[Yury Aliaev]

Igor Vlasenko scripsit:
> 
> А робота для пересборки зависимых пакетов написать легко.
> Вопрос не в роботе, а в получении nmu.
> Я вот в апреле nmu получал.
> Запомнилось...
> 

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

1) Если обнаруживается, что новая версия библиотеки что-то ломает, то в 
Сизифе она не появляется, а переносится в некоторое место, своеобразный 
карантин. Мэйнтейнеру библотеки об этом посылается уведомление;
2) Создаётся список пакетов, которые требуется пересобрать с новой 
библиотекой. Проводится пробная пересборка, о результатах которой 
сообщается мэйнтейнерам пакетов (они могут взять библиотеку и свои 
паекты из карантина, куда пересобранные пакеты также помещаются);
3) Если все зависящие пакеты проходят пробную пересборку, и их 
мэйнтейнеры соглашаются с её результатами (или не проявляют никакой 
активности по этому вопросу в течение x дней), то обновлённая библиотека 
вместе с пересборанными пакетами переносится из карантина в Сизиф;
4) Главная сложность может возникнуть, если не все зависящие пакеты 
пересоберутся. В этом случае возможен вариант создания compat 
библиотеки, но этот случай скорее должен рассматриваться индивидуально, 
а не автоматически (практически полная автоматизация возможна для п. 1, 
2, 3).

Re: [devel] Когда появится новая libquicktime?

[Yury Aliaev]

Igor Vlasenko scripsit:

>>
>> IV> Что-то слишком жизнь майнтайнерская сложна стала...  представляя, сколько
>> IV> работы по хорошему, чтобы обновить библиотеку по всем правилам,
>>
>>Так, стоп. Надо выявить проблему. Неужели это действительно занимает так много
>>сил?
> 
> Апстрим из той же песочницы, что и ffmpeg :(
> Версионирования не ведет,
> вести его вместо апстрима действительно занимает так много сил :(
> А жульничество с soname на версию будет плодить по 
> compat библиотеке раз в три месяца :(

Я вроде придумал более удовлетворительное решение на базе жульничества. 
При выходе новых версий библиотеки можно отслеживать изменения в ABI и 
увеличивать soversion только при реальной необходимости (т.е. если 
что-то поменялось).

Re: [devel] Когда появится новая libquicktime?

[Yury Aliaev]

Mikhail Gusarov scripsit:
> 
>  IV> Версионирования не ведет, вести его вместо апстрима действительно занимает
>  IV> так много сил :( А жульничество с soname на версию будет плодить по compat
>  IV> библиотеке раз в три месяца :(
> 
> Стоп ещё раз :) Это уже не связано с compat, как я понимаю - особенно учитывая,
> что они по предложенной в драфте схеме получаются "нахаляву".

В том-то и дело, что пока черновик не стал правилом (и, соответственно, 
не создана нужная механизация), холявы не будет... :(