[devel] I: repocop NMU

[devel] I: repocop NMU

[Igor Vlasenko]

Уважаемые коллеги,

На repocop.altlinux.org приехали свежие патчи от repocop,
включающие в себя добавки, которые чинят non-strict-dependency
warning.

Патчи постоянно доступны на
http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/<ваш acl>

сводную деятельность генератора патчей beehive-log-non-strict-dependency
можно просмотреть в файле 
http://repocop.altlinux.org/pub/repocop/reports/diff/by-test/beehive-log-non-strict-dependency-x86_64.diff 

Патчгенератор там достаточно консервативный,
написанный так, чтобы при сомнении ничего не торогать.
Поэтому есть пакеты, для которых rpm-build ругается,
а патча от repocop нет. 
просил бы обращать внимание на случаи,
когда патчгенератор пакет не чинил.
И, естественно, нет ли некорректных патчей.

Если все благо, то, если в rpm-build гайки не будут закручены,
то через 3 недели, а если в rpm-build гайки будут закручены,
то в аварийном режиме для спасения пакетов через неделю
будет проведено NMU от repocop, о чем будет повторное оповещение
в devel@. Тем временем буду тестировать NMU на своих
и @nobody пакетах. Как обычно, все патчи будут вручную
просмотрены перед прикладыванием.

По традиции, пакеты shrek@ и sbolshakov@ исключаются из NMU.
Остальных, кто не хотел бы быть затронутым NMU,
прошу самим прикладывать патчи или писать в devel@.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] I: repocop NMU

[Yuri N. Sedunov]

В Пт, 25/01/2013 в 11:28 +0200, Igor Vlasenko пишет:
> Уважаемые коллеги,

> 
> По традиции, пакеты shrek@ и sbolshakov@ исключаются из NMU.
По давней традиции это еще пакеты aris@ и @gnome.

-- 
Yuri N. Sedunov

Re: [devel] I: repocop NMU

[Igor Vlasenko]

On Sun, Jan 27, 2013 at 01:40:16PM +0400, Yuri N. Sedunov wrote:
> > Извиняюсь, сразу не ответил, был в дороге.
> > 
> > IMHO, сейчас рост пользователей за счет притока менее 
> > квалифицированных пользователей (бабушки, дедушки,
> > внучки, жучки) с Васей Пупкиным в админах,
> > которые в принципе далеки от сборки пакетов.
> > Пакеты нужны, а майнтайнеров взять неоткуда.
> > Выбрасывать пакеты в расчете на чудо?
> > 
> > IMHO, сопровождать хоть как то.
> 
> 
> Не возьметесь ли собрать свежую версию gnunet для #88500?
> http://lists.altlinux.org/pipermail/devel/2013-January/196475.html

ОК, хорошо. собрал в #88707.


У меня к вам большая просьба - 
выпилите, пожалуйста, подпакет rpm-macros-GConf из GConf-devel

это нужно и в соответствии с принятым
http://www.altlinux.org/RPM_Macros_Packaging_Policy

и есть уже готовая болванка для патча
http://repocop.altlinux.org/pub/repocop/reports/diff/by-srpm/GConf-3.2.6-alt1.diff

выпилите, пожалуйста, подпакет rpm-macros-GConf из GConf-devel
(проставив зависимость GConf-devel -> rpm-macros-GConf)

Мне отсутствие пакета  rpm-macros-GConf уже много лет как 
гвоздь в ботинке - очень неудобно при массовой работе с srpm :(

Вам все равно, а мне было бы очень удобно.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] I: repocop NMU

[Aleksey Avdeev]

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

25.01.2013 13:28, Igor Vlasenko пишет:
> Уважаемые коллеги,
> 
> На repocop.altlinux.org приехали свежие патчи от repocop,
> включающие в себя добавки, которые чинят non-strict-dependency
> warning.
> 
...
> 
> Если все благо, то, если в rpm-build гайки не будут закручены,
> то через 3 недели, а если в rpm-build гайки будут закручены,
> то в аварийном режиме для спасения пакетов через неделю
> будет проведено NMU от repocop, о чем будет повторное оповещение
> в devel@. Тем временем буду тестировать NMU на своих
> и @nobody пакетах. Как обычно, все патчи будут вручную
> просмотрены перед прикладыванием.
> 
> По традиции, пакеты shrek@ и sbolshakov@ исключаются из NMU.
> Остальных, кто не хотел бы быть затронутым NMU,
> прошу самим прикладывать патчи или писать в devel@.

  Прошу заранее исключить из NMU пакеты:

1. apache

2. apache2

3. moodle

4. moodle2.1

5. moddle2.2

6. php5-jpgraph

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

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] I: repocop NMU

[Igor Vlasenko]

On Fri, Jan 25, 2013 at 01:57:30PM +0400, Aleksey Avdeev wrote:
> 25.01.2013 13:28, Igor Vlasenko пишет:
>   Прошу заранее исключить из NMU пакеты:
> 1. apache
> 2. apache2
> 3. moodle
> 4. moodle2.1
> 5. moddle2.2
> 6. php5-jpgraph
>   В данных пакетах нестрогие зависимости поставлены руками и имеют
> специальный смысл (стоят там, где излишняя строгость вредна будет).

Понял, спасибо. Кстати, патчгенератор для этих пакетов
и отказался делать патчи по нестрогим зависимостям
(не было явного имени подпакета).

Зато на repocop.altlinux.org для вас есть 2 патча от робота.

В apache2 он правит интересную опечатку-ошибку.

--- a/apache2.spec      2013-01-25 12:03:02.000000000 +0400
+++ b/apache2.spec      2013-01-25 12:03:02.000000000 +0400
@@ -1296,7 +1296,6 @@
 fi
 exit 0
 
-%post httpd-worker
 %if "%alternatives_filetrigger" != "yes"
 %post httpd-worker
 %register_alternatives %name-httpd-worker

в apache1 там борьба с использованием внутренних макросов %__*,
можете прикладывать, можете нет, но
лучше приложить, так как этот патч вы еще в прошлом году 
во время прошлого NMU собирались приложить, но забыли.
Чтобы он не всплывал каждый раз.

--- a/apache.spec       2013-01-25 12:03:02.000000000 +0400
+++ b/apache.spec       2013-01-25 12:03:02.000000000 +0400
@@ -874,7 +874,7 @@
        --proxycachedir=%_cachedir/httpd \
        --disable-rule=WANTHSREGEX \
        --disable-rule=EXPAT \
-        --with-perl=%__perl \
+        --with-perl=/usr/bin/perl \
        --without-confadjust \
        --enable-module=all \
        --enable-module=auth_digest \




-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] I: repocop NMU

[Aleksey Avdeev]

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

25.01.2013 14:10, Igor Vlasenko пишет:
> On Fri, Jan 25, 2013 at 01:57:30PM +0400, Aleksey Avdeev wrote:
>> 25.01.2013 13:28, Igor Vlasenko пишет:
>>   Прошу заранее исключить из NMU пакеты:
>> 1. apache
>> 2. apache2
>> 3. moodle
>> 4. moodle2.1
>> 5. moddle2.2
>> 6. php5-jpgraph
>>   В данных пакетах нестрогие зависимости поставлены руками и имеют
>> специальный смысл (стоят там, где излишняя строгость вредна будет).
> 
> Понял, спасибо. Кстати, патчгенератор для этих пакетов
> и отказался делать патчи по нестрогим зависимостям
> (не было явного имени подпакета).
> 
> Зато на repocop.altlinux.org для вас есть 2 патча от робота.
> 
> В apache2 он правит интересную опечатку-ошибку.
> 
> --- a/apache2.spec      2013-01-25 12:03:02.000000000 +0400
> +++ b/apache2.spec      2013-01-25 12:03:02.000000000 +0400
> @@ -1296,7 +1296,6 @@
>  fi
>  exit 0
>  
> -%post httpd-worker
>  %if "%alternatives_filetrigger" != "yes"
>  %post httpd-worker
>  %register_alternatives %name-httpd-worker

  OK, проверю.

> 
> в apache1 там борьба с использованием внутренних макросов %__*,
> можете прикладывать, можете нет, но
> лучше приложить, так как этот патч вы еще в прошлом году 
> во время прошлого NMU собирались приложить, но забыли.
> Чтобы он не всплывал каждый раз.
> 
> --- a/apache.spec       2013-01-25 12:03:02.000000000 +0400
> +++ b/apache.spec       2013-01-25 12:03:02.000000000 +0400
> @@ -874,7 +874,7 @@
>         --proxycachedir=%_cachedir/httpd \
>         --disable-rule=WANTHSREGEX \
>         --disable-rule=EXPAT \
> -        --with-perl=%__perl \
> +        --with-perl=/usr/bin/perl \
>         --without-confadjust \
>         --enable-module=all \
>         --enable-module=auth_digest \

  Я apache планирую заняться как с apache2 закончу. (Там много всего
накопилось.)

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] I: repocop NMU

[Aleksey Avdeev]

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

25.01.2013 14:25, Aleksey Avdeev пишет:
> 25.01.2013 14:10, Igor Vlasenko пишет:
...
>> Зато на repocop.altlinux.org для вас есть 2 патча от робота.
>>
>> В apache2 он правит интересную опечатку-ошибку.
>>
>> --- a/apache2.spec      2013-01-25 12:03:02.000000000 +0400
>> +++ b/apache2.spec      2013-01-25 12:03:02.000000000 +0400
>> @@ -1296,7 +1296,6 @@
>>  fi
>>  exit 0
>>  
>> -%post httpd-worker
>>  %if "%alternatives_filetrigger" != "yes"
>>  %post httpd-worker
>>  %register_alternatives %name-httpd-worker
> 
>   OK, проверю.

  Приложено к apache2-2.2.22-alt15 (см.
<http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=commitdiff;h=e541a7639eff443c6ebfc9092c3d95c38afd849f>
и
<http://git.altlinux.org/tasks/archive/done/_85/88057/logs/events.7.1.log>).

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] I: repocop NMU

[Alexey Gladkov]

25.01.2013 13:28, Igor Vlasenko wrote:
> Уважаемые коллеги,
> 
> На repocop.altlinux.org приехали свежие патчи от repocop,
> включающие в себя добавки, которые чинят non-strict-dependency
> warning.
> 
> Патчи постоянно доступны на
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/<ваш acl>
> 
> сводную деятельность генератора патчей beehive-log-non-strict-dependency
> можно просмотреть в файле 
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-test/beehive-log-non-strict-dependency-x86_64.diff 
> 
> Патчгенератор там достаточно консервативный,
> написанный так, чтобы при сомнении ничего не торогать.
> Поэтому есть пакеты, для которых rpm-build ругается,
> а патча от repocop нет. 
> просил бы обращать внимание на случаи,
> когда патчгенератор пакет не чинил.
> И, естественно, нет ли некорректных патчей.
> 
> Если все благо, то, если в rpm-build гайки не будут закручены,
> то через 3 недели, а если в rpm-build гайки будут закручены,
> то в аварийном режиме для спасения пакетов через неделю
> будет проведено NMU от repocop, о чем будет повторное оповещение
> в devel@. Тем временем буду тестировать NMU на своих
> и @nobody пакетах. Как обычно, все патчи будут вручную
> просмотрены перед прикладыванием.
> 
> По традиции, пакеты shrek@ и sbolshakov@ исключаются из NMU.

Добавьте и мои пакеты к традиции.

-- 
-- 
Rgrds, legion

Re: [devel] I: repocop NMU

[Igor Vlasenko]

On Fri, Jan 25, 2013 at 01:59:12PM +0400, Alexey Gladkov wrote:
> > По традиции, пакеты shrek@ и sbolshakov@ исключаются из NMU.
> 
> Добавьте и мои пакеты к традиции.

Ок.
По традиции, пакеты legion@, shrek@ и sbolshakov@ исключаются из NMU.

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 11:28:45AM +0200, Igor Vlasenko wrote:
> Уважаемые коллеги,
> 
> На repocop.altlinux.org приехали свежие патчи от repocop,
> включающие в себя добавки, которые чинят non-strict-dependency
> warning.
> 
> Патчи постоянно доступны на
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-leader/<ваш acl>
> 
> сводную деятельность генератора патчей beehive-log-non-strict-dependency
> можно просмотреть в файле 
> http://repocop.altlinux.org/pub/repocop/reports/diff/by-test/beehive-log-non-strict-dependency-x86_64.diff 
> 
> Патчгенератор там достаточно консервативный,
> написанный так, чтобы при сомнении ничего не торогать.
> Поэтому есть пакеты, для которых rpm-build ругается,
> а патча от repocop нет. 
> просил бы обращать внимание на случаи,
> когда патчгенератор пакет не чинил.
> И, естественно, нет ли некорректных патчей.
> 
> Если все благо, то, если в rpm-build гайки не будут закручены,
> то через 3 недели, а если в rpm-build гайки будут закручены,
> то в аварийном режиме для спасения пакетов через неделю
> будет проведено NMU от repocop, о чем будет повторное оповещение
> в devel@. Тем временем буду тестировать NMU на своих
> и @nobody пакетах. Как обычно, все патчи будут вручную
> просмотрены перед прикладыванием.

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

Я сейчас тестирую rpm-build, который автоматически добавляет строгие
внутрипакетные зависимости во всех случаях, в которых это необходимо.
Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
да и сам NMU будет технически проще.


-- 
ldv

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

Re: [devel] I: repocop NMU

[Aleksey Avdeev]

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

25.01.2013 14:53, Dmitry V. Levin пишет:
...
> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> только один класс зависимостей, которые нужно сохранить,
> а все остальные следует сделать строгими.
> 
> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
> внутрипакетные зависимости во всех случаях, в которых это необходимо.
> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
> да и сам NMU будет технически проще.

  _Отключить_ этот механизм можно?!!

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
> 25.01.2013 14:53, Dmitry V. Levin пишет:
> ...
> > Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> > диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> > только один класс зависимостей, которые нужно сохранить,
> > а все остальные следует сделать строгими.
> > 
> > Я сейчас тестирую rpm-build, который автоматически добавляет строгие
> > внутрипакетные зависимости во всех случаях, в которых это необходимо.
> > Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
> > да и сам NMU будет технически проще.
> 
>   _Отключить_ этот механизм можно?!!

Пока не вижу смысла отключать этот механизм.


-- 
ldv

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

Re: [devel] I: repocop NMU

[Aleksey Avdeev]

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

25.01.2013 15:34, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
>> 25.01.2013 14:53, Dmitry V. Levin пишет:
>> ...
>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>> только один класс зависимостей, которые нужно сохранить,
>>> а все остальные следует сделать строгими.
>>>
>>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
>>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
>>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
>>> да и сам NMU будет технически проще.
>>
>>   _Отключить_ этот механизм можно?!!
> 
> Пока не вижу смысла отключать этот механизм.

  Усложнение работы мантейнера: теперь для обеспечения возможности
точечного обновления модулей (или возможности поставить их на холд),
распространяемых апстримом комбайна (такого как apache* или moodle*)
придётся выносить модули в отдельный пакет (не подпакет) и собирать
отдельно.

PS: Грубо говоря, тупая замена нестрогих зависимостей на строгие
превращает модульные комбайны в монолиты, строго синхронизируя по
версиям их части, распространяемые апстримом в рамках одного
дистрибутива. При этом, например, апстримы moodle и eGroupWare обратную
совместимость хранилищ, используемых модулями, иногда ломают (натыкался
на такое). При этом стандартная рекомендация -- использовать модуь от
предыдущий версии, т. е. поставить его на холд, в нашем случаи. Теперь
такой вариант отпадает: при постановки модуля на холд будет блокировано
обновление всего остального монстра (т. к. строгая зависимость %VER)...

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] I: repocop NMU [JT]

[Sergei Epiphanov]

On 25 января 2013 15:58 Aleksey Avdeev wrote:
> >>   _Отключить_ этот механизм можно?!!
> >
> > 
> >
> > Пока не вижу смысла отключать этот механизм.
> 
>   Усложнение работы мантейнера: теперь для обеспечения возможности
> точечного обновления модулей (или возможности поставить их на холд),
> распространяемых апстримом комбайна (такого как apache* или moodle*)
> придётся выносить модули в отдельный пакет (не подпакет) и собирать
> отдельно.

Ворота закрыли, замок повесили, а забор не построили. :)

-- 
С уважением, Епифанов Сергей

Re: [devel] I: repocop NMU

[Aleksey Novodvorsky]

25 января 2013 г., 15:58 пользователь Aleksey Avdeev
<solo@solin.spb.ru> написал:
> 25.01.2013 15:34, Dmitry V. Levin пишет:
>> On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
>>> 25.01.2013 14:53, Dmitry V. Levin пишет:
>>> ...
>>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>>> только один класс зависимостей, которые нужно сохранить,
>>>> а все остальные следует сделать строгими.
>>>>
>>>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
>>>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
>>>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
>>>> да и сам NMU будет технически проще.
>>>
>>>   _Отключить_ этот механизм можно?!!
>>
>> Пока не вижу смысла отключать этот механизм.
>
>   Усложнение работы мантейнера: теперь для обеспечения возможности
> точечного обновления модулей (или возможности поставить их на холд),
> распространяемых апстримом комбайна (такого как apache* или moodle*)
> придётся выносить модули в отдельный пакет (не подпакет) и собирать
> отдельно.
>
> PS: Грубо говоря, тупая замена нестрогих зависимостей на строгие
> превращает модульные комбайны в монолиты, строго синхронизируя по
> версиям их части, распространяемые апстримом в рамках одного
> дистрибутива. При этом, например, апстримы moodle и eGroupWare обратную
> совместимость хранилищ, используемых модулями, иногда ломают (натыкался
> на такое). При этом стандартная рекомендация -- использовать модуь от
> предыдущий версии, т. е. поставить его на холд, в нашем случаи. Теперь
> такой вариант отпадает: при постановки модуля на холд будет блокировано
> обновление всего остального монстра (т. к. строгая зависимость %VER)...
>

По крайней мере, стоит подумать о возможности упрощения тестовых
сборок или даже сборок с небольшими фиксами.
Например, в случае такого монстра как kde4, при небольшой ошибке в
маленьком подпакете, придетеся все пересобирать вместе заново, что
вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
смысл.
Результатом жестких мер может быть торможение динамики развития Сизифа.

Rgrds, Алексей

> --
>
> С уважением. Алексей.
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 03:11:31PM +0300, Aleksey Novodvorsky wrote:
> 25 января 2013 г., 15:58 пользователь Aleksey Avdeev
> <solo@solin.spb.ru> написал:
> > 25.01.2013 15:34, Dmitry V. Levin пишет:
> >> On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
> >>> 25.01.2013 14:53, Dmitry V. Levin пишет:
> >>> ...
> >>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> >>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> >>>> только один класс зависимостей, которые нужно сохранить,
> >>>> а все остальные следует сделать строгими.
> >>>>
> >>>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
> >>>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
> >>>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
> >>>> да и сам NMU будет технически проще.
> >>>
> >>>   _Отключить_ этот механизм можно?!!
> >>
> >> Пока не вижу смысла отключать этот механизм.
> >
> >   Усложнение работы мантейнера: теперь для обеспечения возможности
> > точечного обновления модулей (или возможности поставить их на холд),
> > распространяемых апстримом комбайна (такого как apache* или moodle*)
> > придётся выносить модули в отдельный пакет (не подпакет) и собирать
> > отдельно.
> >
> > PS: Грубо говоря, тупая замена нестрогих зависимостей на строгие
> > превращает модульные комбайны в монолиты, строго синхронизируя по
> > версиям их части, распространяемые апстримом в рамках одного
> > дистрибутива. При этом, например, апстримы moodle и eGroupWare обратную
> > совместимость хранилищ, используемых модулями, иногда ломают (натыкался
> > на такое). При этом стандартная рекомендация -- использовать модуь от
> > предыдущий версии, т. е. поставить его на холд, в нашем случаи. Теперь
> > такой вариант отпадает: при постановки модуля на холд будет блокировано
> > обновление всего остального монстра (т. к. строгая зависимость %VER)...
> 
> По крайней мере, стоит подумать о возможности упрощения тестовых
> сборок или даже сборок с небольшими фиксами.
> Например, в случае такого монстра как kde4, при небольшой ошибке в
> маленьком подпакете, придетеся все пересобирать вместе заново, что
> вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> смысл.
> Результатом жестких мер может быть торможение динамики развития Сизифа.

Алексей, речь идет о внутрипакетных зависимостях, каким образом это может
повлиять на потребность "все пересобирать вместе заново"?


-- 
ldv

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

Re: [devel] I: repocop NMU

[Sergey V Turchin]

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

On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:

[...]
> По крайней мере, стоит подумать о возможности упрощения тестовых
> сборок или даже сборок с небольшими фиксами.
> Например, в случае такого монстра как kde4, при небольшой ошибке в
> маленьком подпакете, придетеся все пересобирать вместе заново, что
> вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> смысл.
> Результатом жестких мер может быть торможение динамики развития Сизифа.
У меня другая проблема.
Все автоматические зависимости сейчас идут лесом.
Мне во всех подпакетах каждого пакета необходимо вручную искать и проставлять 
зависимости на подпакеты. И постоянно отслеживать их изменения. В таких 
монстрах, как kde4base-workspace kde4pim и calligra это превращается в битье 
головой о стену.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop NMU

[Sergey V Turchin]

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

On Friday 25 January 2013 16:27:17 Sergey V wrote:
> On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> 
> [...]
> 
> > По крайней мере, стоит подумать о возможности упрощения тестовых
> > сборок или даже сборок с небольшими фиксами.
> > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> > смысл.
> > Результатом жестких мер может быть торможение динамики развития Сизифа.
> 
> У меня другая проблема.
> Все автоматические зависимости сейчас идут лесом.
> Мне во всех подпакетах каждого пакета необходимо вручную искать и
> проставлять зависимости на подпакеты. И постоянно отслеживать их изменения.
> В таких монстрах, как kde4base-workspace kde4pim и calligra это
> превращается в битье головой о стену.
И всё это при том, что у меня НЕТ ошибок, которые мне вменяют!

> 
> [...]
-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:35:49PM +0400, Sergey V Turchin wrote:
> On Friday 25 January 2013 16:27:17 Sergey V wrote:
> > On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> > 
> > [...]
> > 
> > > По крайней мере, стоит подумать о возможности упрощения тестовых
> > > сборок или даже сборок с небольшими фиксами.
> > > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > > вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> > > смысл.
> > > Результатом жестких мер может быть торможение динамики развития Сизифа.
> > 
> > У меня другая проблема.
> > Все автоматические зависимости сейчас идут лесом.
> > Мне во всех подпакетах каждого пакета необходимо вручную искать и
> > проставлять зависимости на подпакеты. И постоянно отслеживать их изменения.
> > В таких монстрах, как kde4base-workspace kde4pim и calligra это
> > превращается в битье головой о стену.
> И всё это при том, что у меня НЕТ ошибок, которые мне вменяют!

Если ошибки называть фичами, они от этого не перестают быть ошибками. :)


-- 
ldv

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

Re: [devel] I: repocop NMU

[Sergey V Turchin]

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

On Friday 25 January 2013 16:40:30 Dmitry V wrote:
> On Fri, Jan 25, 2013 at 04:35:49PM +0400, Sergey V Turchin wrote:
> > On Friday 25 January 2013 16:27:17 Sergey V wrote:
> > > On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> > > 
> > > [...]
> > > 
> > > > По крайней мере, стоит подумать о возможности упрощения тестовых
> > > > сборок или даже сборок с небольшими фиксами.
> > > > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > > > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > > > вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> > > > смысл.
> > > > Результатом жестких мер может быть торможение динамики развития
> > > > Сизифа.
> > > 
> > > У меня другая проблема.
> > > Все автоматические зависимости сейчас идут лесом.
> > > Мне во всех подпакетах каждого пакета необходимо вручную искать и
> > > проставлять зависимости на подпакеты. И постоянно отслеживать их
> > > изменения.
> > > В таких монстрах, как kde4base-workspace kde4pim и calligra это
> > > превращается в битье головой о стену.
> > 
> > И всё это при том, что у меня НЕТ ошибок, которые мне вменяют!
> 
> Если ошибки называть фичами, они от этого не перестают быть ошибками. :)
Согласен. Ошибку в сборочной среде, которая работает некорректно выдавать фичу 
не стОит.
У меня НЕТ ошибок в зависимостях. Все подпакеты зависят между собой _жестко_.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:42:16PM +0400, Sergey V Turchin wrote:
> On Friday 25 January 2013 16:40:30 Dmitry V wrote:
> > On Fri, Jan 25, 2013 at 04:35:49PM +0400, Sergey V Turchin wrote:
> > > On Friday 25 January 2013 16:27:17 Sergey V wrote:
> > > > On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > По крайней мере, стоит подумать о возможности упрощения тестовых
> > > > > сборок или даже сборок с небольшими фиксами.
> > > > > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > > > > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > > > > вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> > > > > смысл.
> > > > > Результатом жестких мер может быть торможение динамики развития
> > > > > Сизифа.
> > > > 
> > > > У меня другая проблема.
> > > > Все автоматические зависимости сейчас идут лесом.
> > > > Мне во всех подпакетах каждого пакета необходимо вручную искать и
> > > > проставлять зависимости на подпакеты. И постоянно отслеживать их
> > > > изменения.
> > > > В таких монстрах, как kde4base-workspace kde4pim и calligra это
> > > > превращается в битье головой о стену.
> > > 
> > > И всё это при том, что у меня НЕТ ошибок, которые мне вменяют!
> > 
> > Если ошибки называть фичами, они от этого не перестают быть ошибками. :)
> Согласен. Ошибку в сборочной среде, которая работает некорректно выдавать фичу 
> не стОит.
> У меня НЕТ ошибок в зависимостях. Все подпакеты зависят между собой _жестко_.

Я уже продемонстрировал тебе, что это не так, и на этом считаю тему
непогрешимости твоих пакетов закрытой.


-- 
ldv

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

Re: [devel] I: repocop NMU

[Sergey V Turchin]

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

On Friday 25 January 2013 17:00:40 Dmitry V wrote:
> On Fri, Jan 25, 2013 at 04:42:16PM +0400, Sergey V Turchin wrote:
> > On Friday 25 January 2013 16:40:30 Dmitry V wrote:
> > > On Fri, Jan 25, 2013 at 04:35:49PM +0400, Sergey V Turchin wrote:
> > > > On Friday 25 January 2013 16:27:17 Sergey V wrote:
> > > > > On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > > По крайней мере, стоит подумать о возможности упрощения тестовых
> > > > > > сборок или даже сборок с небольшими фиксами.
> > > > > > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > > > > > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > > > > > вряд ли разумно для нестабильного бранча. Для стабильного --да,
> > > > > > имеет
> > > > > > смысл.
> > > > > > Результатом жестких мер может быть торможение динамики развития
> > > > > > Сизифа.
> > > > > 
> > > > > У меня другая проблема.
> > > > > Все автоматические зависимости сейчас идут лесом.
> > > > > Мне во всех подпакетах каждого пакета необходимо вручную искать и
> > > > > проставлять зависимости на подпакеты. И постоянно отслеживать их
> > > > > изменения.
> > > > > В таких монстрах, как kde4base-workspace kde4pim и calligra это
> > > > > превращается в битье головой о стену.
> > > > 
> > > > И всё это при том, что у меня НЕТ ошибок, которые мне вменяют!
> > > 
> > > Если ошибки называть фичами, они от этого не перестают быть ошибками. :)
> > 
> > Согласен. Ошибку в сборочной среде, которая работает некорректно выдавать
> > фичу не стОит.
> > У меня НЕТ ошибок в зависимостях. Все подпакеты зависят между собой
> > _жестко_.
> Я уже продемонстрировал тебе, что это не так, и на этом считаю тему
> непогрешимости твоих пакетов закрытой.
Неправда! Ты не можешь продемонстрировать черное белым.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:27:17PM +0400, Sergey V Turchin wrote:
> On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> 
> [...]
> > По крайней мере, стоит подумать о возможности упрощения тестовых
> > сборок или даже сборок с небольшими фиксами.
> > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> > смысл.
> > Результатом жестких мер может быть торможение динамики развития Сизифа.
> У меня другая проблема.
> Все автоматические зависимости сейчас идут лесом.
> Мне во всех подпакетах каждого пакета необходимо вручную искать и проставлять 
> зависимости на подпакеты. И постоянно отслеживать их изменения. В таких 
> монстрах, как kde4base-workspace kde4pim и calligra это превращается в битье 
> головой о стену.

У тебя действительно другая проблема.  Перечитай все письма на эту тему,
может быть, и проблема перестанет казаться таковой. :)


-- 
ldv

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

Re: [devel] I: repocop NMU

[Sergey V Turchin]

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

On Friday 25 January 2013 16:39:08 Dmitry V wrote:
> On Fri, Jan 25, 2013 at 04:27:17PM +0400, Sergey V Turchin wrote:
> > On Friday 25 January 2013 15:11:31 Aleksey Novodvorsky wrote:
> > 
> > [...]
> > 
> > > По крайней мере, стоит подумать о возможности упрощения тестовых
> > > сборок или даже сборок с небольшими фиксами.
> > > Например, в случае такого монстра как kde4, при небольшой ошибке в
> > > маленьком подпакете, придетеся все пересобирать вместе заново, что
> > > вряд ли разумно для нестабильного бранча. Для стабильного --да, имеет
> > > смысл.
> > > Результатом жестких мер может быть торможение динамики развития Сизифа.
> > 
> > У меня другая проблема.
> > Все автоматические зависимости сейчас идут лесом.
> > Мне во всех подпакетах каждого пакета необходимо вручную искать и
> > проставлять зависимости на подпакеты. И постоянно отслеживать их
> > изменения. В таких монстрах, как kde4base-workspace kde4pim и calligra
> > это превращается в битье головой о стену.
> 
> У тебя действительно другая проблема.  Перечитай все письма на эту тему,
> может быть, и проблема перестанет казаться таковой. :)
Я представляю несколько вариантов того, как добавление мне _постоянной_ ручной 
работы может не казаться проблемой, но все они неприемлимы.

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 03:58:07PM +0400, Aleksey Avdeev wrote:
> 25.01.2013 15:34, Dmitry V. Levin пишет:
> > On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
> >> 25.01.2013 14:53, Dmitry V. Levin пишет:
> >> ...
> >>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> >>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> >>> только один класс зависимостей, которые нужно сохранить,
> >>> а все остальные следует сделать строгими.
> >>>
> >>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
> >>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
> >>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
> >>> да и сам NMU будет технически проще.
> >>
> >>   _Отключить_ этот механизм можно?!!
> > 
> > Пока не вижу смысла отключать этот механизм.
> 
>   Усложнение работы мантейнера: теперь для обеспечения возможности
> точечного обновления модулей (или возможности поставить их на холд),
> распространяемых апстримом комбайна (такого как apache* или moodle*)
> придётся выносить модули в отдельный пакет (не подпакет) и собирать
> отдельно.
> 
> PS: Грубо говоря, тупая замена нестрогих зависимостей на строгие
> превращает модульные комбайны в монолиты, строго синхронизируя по
> версиям их части, распространяемые апстримом в рамках одного
> дистрибутива. При этом, например, апстримы moodle и eGroupWare обратную
> совместимость хранилищ, используемых модулями, иногда ломают (натыкался
> на такое). При этом стандартная рекомендация -- использовать модуь от
> предыдущий версии, т. е. поставить его на холд, в нашем случаи. Теперь
> такой вариант отпадает: при постановки модуля на холд будет блокировано
> обновление всего остального монстра (т. к. строгая зависимость %VER)...

Чем меньше будет таких сферических коней, тем лучше.


-- 
ldv

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

Re: [devel] I: repocop NMU

[Aleksey Avdeev]

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

25.01.2013 16:13, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 03:58:07PM +0400, Aleksey Avdeev wrote:
>> 25.01.2013 15:34, Dmitry V. Levin пишет:
>>> On Fri, Jan 25, 2013 at 03:07:36PM +0400, Aleksey Avdeev wrote:
>>>> 25.01.2013 14:53, Dmitry V. Levin пишет:
>>>> ...
>>>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>>>> только один класс зависимостей, которые нужно сохранить,
>>>>> а все остальные следует сделать строгими.
>>>>>
>>>>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
>>>>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
>>>>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
>>>>> да и сам NMU будет технически проще.
>>>>
>>>>   _Отключить_ этот механизм можно?!!
>>>
>>> Пока не вижу смысла отключать этот механизм.
>>
>>   Усложнение работы мантейнера: теперь для обеспечения возможности
>> точечного обновления модулей (или возможности поставить их на холд),
>> распространяемых апстримом комбайна (такого как apache* или moodle*)
>> придётся выносить модули в отдельный пакет (не подпакет) и собирать
>> отдельно.
>>
>> PS: Грубо говоря, тупая замена нестрогих зависимостей на строгие
>> превращает модульные комбайны в монолиты, строго синхронизируя по
>> версиям их части, распространяемые апстримом в рамках одного
>> дистрибутива. При этом, например, апстримы moodle и eGroupWare обратную
>> совместимость хранилищ, используемых модулями, иногда ломают (натыкался
>> на такое). При этом стандартная рекомендация -- использовать модуь от
>> предыдущий версии, т. е. поставить его на холд, в нашем случаи. Теперь
>> такой вариант отпадает: при постановки модуля на холд будет блокировано
>> обновление всего остального монстра (т. к. строгая зависимость %VER)...
> 
> Чем меньше будет таких сферических коней, тем лучше.

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

PS: Не, я за то, чтобы он был закрыт по умолчанию -- это действительно
снизит число ошибок упаковки. Но _нужна_ ручка для его открытия
мантейнером, т. к. далеко не всегда этот путь ошибочен.

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] I: repocop NMU

[Viacheslav Dubrovskyi]

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

25.01.2013 13:34, Dmitry V. Levin пишет:
>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>> только один класс зависимостей, которые нужно сохранить,
>>> а все остальные следует сделать строгими.
>>>
>>> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
>>> внутрипакетные зависимости во всех случаях, в которых это необходимо.
>>> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
>>> да и сам NMU будет технически проще.
>>   _Отключить_ этот механизм можно?!!
> Пока не вижу смысла отключать этот механизм.
"Доктор сказал: -  в морг. Значит в морг." (с) 
:)


-- 
WBR,
Viacheslav Dubrovskyi


[-- Attachment #2: Криптографическая подпись S/MIME --]
[-- Type: application/pkcs7-signature, Size: 3746 bytes --]

Re: [devel] I: repocop NMU

[Alexey Gladkov]

25.01.2013 14:53, Dmitry V. Levin wrote:
> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> только один класс зависимостей, которые нужно сохранить,
> а все остальные следует сделать строгими.

Можно ли рассказать подробнее т.к. меня это касается?

-- 
Rgrds, legion

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> 25.01.2013 14:53, Dmitry V. Levin wrote:
> > Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> > диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> > только один класс зависимостей, которые нужно сохранить,
> > а все остальные следует сделать строгими.
> 
> Можно ли рассказать подробнее т.к. меня это касается?

Тестируется следующий алгоритм: подпакет A исходного пакета S
автоматически получает строгую зависимость на подпакет B исходного
пакета S, если у подпакета A есть такая зависимость X, что подпакет B
является единственным подпакетом исходного пакета S, удовлетворяющим
эту зависимость X.


-- 
ldv

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

Re: [devel] non-strict deps

[Aleksey Avdeev]

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

25.01.2013 16:32, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
>> 25.01.2013 14:53, Dmitry V. Levin wrote:
>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>> только один класс зависимостей, которые нужно сохранить,
>>> а все остальные следует сделать строгими.
>>
>> Можно ли рассказать подробнее т.к. меня это касается?
> 
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
под пакетом данного исходного S) который тоже предоставляет зависимость X?

2. Как обеспечить равноценность подпакета B и пакета C для подпакета A?
(Чтобы администратор мог свободно выбрать из комбинаций A+B и A+C нужную.)

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:39:39PM +0400, Aleksey Avdeev wrote:
> 25.01.2013 16:32, Dmitry V. Levin пишет:
> > On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> >> 25.01.2013 14:53, Dmitry V. Levin wrote:
> >>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> >>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> >>> только один класс зависимостей, которые нужно сохранить,
> >>> а все остальные следует сделать строгими.
> >>
> >> Можно ли рассказать подробнее т.к. меня это касается?
> > 
> > Тестируется следующий алгоритм: подпакет A исходного пакета S
> > автоматически получает строгую зависимость на подпакет B исходного
> > пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> > является единственным подпакетом исходного пакета S, удовлетворяющим
> > эту зависимость X.
> 
> 1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
> под пакетом данного исходного S) который тоже предоставляет зависимость X?

Такой пакет С не будет приниматься в рассмотрение этим алгоритмом.

> 2. Как обеспечить равноценность подпакета B и пакета C для подпакета A?
> (Чтобы администратор мог свободно выбрать из комбинаций A+B и A+C нужную.)

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


-- 
ldv

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

Re: [devel] non-strict deps

[Alexey Gladkov]

25.01.2013 16:51, Dmitry V. Levin wrote:
>> 1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
>> под пакетом данного исходного S) который тоже предоставляет зависимость X?
> 
> Такой пакет С не будет приниматься в рассмотрение этим алгоритмом.
> 
>> 2. Как обеспечить равноценность подпакета B и пакета C для подпакета A?
>> (Чтобы администратор мог свободно выбрать из комбинаций A+B и A+C нужную.)
> 
> Я бы не хотел реализовывать такую возможность без необходимости.
> Надеюсь, что такой необходимости не возникнет.
> Все примеры, которые я видел за последние два дня, были более чем
> искусственными.

Я не согласен. Мой случай с osec не искусственный и свести его к
общему случаю не получится.

Если я представлю ещё альтернативу osec-mailreport, то ты будешь её
рассматривать?

-- 
Rgrds, legion

Re: [devel] non-strict deps

[Alexey Gladkov]

25.01.2013 16:55, Alexey Gladkov wrote:
> Если я представлю ещё альтернативу osec-mailreport, то ты будешь её
> рассматривать?

Я сделаю osec-s3report, где репорты будут выкладываться в Amazon S3 и
этот пакет будет иметь соответствующие зависимости на
python-module-boto/perl-Amazon-S3.

Не думаю, что кто-то будет в восторге если osec-cronjob будет
вытягивать его зависимости "в нагрузку".

-- 
Rgrds, legion

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 05:00:00PM +0400, Alexey Gladkov wrote:
> 25.01.2013 16:55, Alexey Gladkov wrote:
> > Если я представлю ещё альтернативу osec-mailreport, то ты будешь её
> > рассматривать?
> 
> Я сделаю osec-s3report, где репорты будут выкладываться в Amazon S3 и
> этот пакет будет иметь соответствующие зависимости на
> python-module-boto/perl-Amazon-S3.
> 
> Не думаю, что кто-то будет в восторге если osec-cronjob будет
> вытягивать его зависимости "в нагрузку".

Если ты при этом не выкинешь osec-mailreport, то "нагрузки" не возникнет.
А если выкинешь, то такой osec никому, кроме тебя, не будет нужен. :)


-- 
ldv

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

Re: [devel] non-strict deps

[Alexey Gladkov]

25.01.2013 17:03, Dmitry V. Levin wrote:
> Если ты при этом не выкинешь osec-mailreport, то "нагрузки" не возникнет.
> А если выкинешь, то такой osec никому, кроме тебя, не будет нужен. :)

Вопрос о нужности каждый решает сам. Я никого не заставляю и
технически с точки зрения проекта всё так и останется хорошо. Вопрос в
запаковке под altlinux. Если в этом дистрибутиве вопрос строгости
зависимостей выше здравого смысла, то пусть так.

Я уже тебе писал. Для меня блокером явдяется зависимость на perl-RPM.
Я его к себе в систему не тащу и никого принуждать это делать не
собираюсь. После твоих изменений эта зависимость будет обязательной.

Я считаю это совершенно неправильным т.к. зависимости на perl-RPM и
perl-Amazon-S3 в моих глазах одинаково плохи.

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

-- 
Rgrds, legion

Re: [devel] osec_rpm_reporter

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 05:15:14PM +0400, Alexey Gladkov wrote:
> Я уже тебе писал. Для меня блокером явдяется зависимость на perl-RPM.

А почему, кстати, osec_rpm_reporter входит в состав osec-mailreport?  Это
же просто фильтр, он не шлет почту, и не используется напрямую ниоткуда.
Понятно, что при желании osec, наверное, можно настроить на использование
этого фильтра, но все же?


-- 
ldv

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

Re: [devel] osec_rpm_reporter

[Alexey Gladkov]

25.01.2013 18:48, Dmitry V. Levin wrote:
> А почему, кстати, osec_rpm_reporter входит в состав osec-mailreport?  Это
> же просто фильтр, он не шлет почту, и не используется напрямую ниоткуда.
> Понятно, что при желании osec, наверное, можно настроить на использование
> этого фильтра, но все же?

Это исторически сложившееся дополнение к osec_reporter. Утилита
osec_rpm_reporter принимает на вход отчёт утилиты osec_reporter. Они
имеют смысл только вместе.

Вообще, все фильтры и отчёты соединяется в osec в виде пайпов. Они
соединяются через конфиг файлы.

Именно поэтому в этом пакете не имеет смысла делать жёсткие
зависимости. Они не нужны by-degign.

-- 
Rgrds, legion

Re: [devel] osec_rpm_reporter

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 03:21:31PM +0400, Alexey Gladkov wrote:
> 25.01.2013 18:48, Dmitry V. Levin wrote:
> > А почему, кстати, osec_rpm_reporter входит в состав osec-mailreport?  Это
> > же просто фильтр, он не шлет почту, и не используется напрямую ниоткуда.
> > Понятно, что при желании osec, наверное, можно настроить на использование
> > этого фильтра, но все же?
> 
> Это исторически сложившееся дополнение к osec_reporter. Утилита
> osec_rpm_reporter принимает на вход отчёт утилиты osec_reporter. Они
> имеют смысл только вместе.

osec_rpm_reporter это чистый фильтр, stdin на входе, stdout на выходе,
и /var/lib/rpm/ сбоку для консультаций.  Он не использует osec, и osec
не использует его.  Его можно было бы установить и использовать отдельно
от osec, например:
$ echo ' - /bin/ls' | osec_rpm_reporter
	- [coreutils] /bin/ls

К чему это я говорю?  Если тебя смущает зависимость osec на perl-RPM,
адресуй свои претензии мейнтейнеру пакета osec, который (за компанию,
потому что так исторически сложилось) сделал так, что уже сейчас, вне
зависимости от strict/nonstrict deps, невозможно установить osec без
практически никем не используемого фильтра osec_rpm_reporter, который,
в свою очередь, использует perl-RPM.

Не говоря уже о том, что если бы osec_rpm_reporter действительно
использовался, то переписать его на C не составило бы труда.

> Вообще, все фильтры и отчёты соединяется в osec в виде пайпов. Они
> соединяются через конфиг файлы.

osec_rpm_reporter не использует /etc/osec/pipe.conf, это чистый фильтр.

> Именно поэтому в этом пакете не имеет смысла делать жёсткие
> зависимости. Они не нужны by-degign.

Поскольку альтернатив osec-mailreport'у нет, зависимость на реализуемый им
osec-reporter, не будучи формально строгой, является строгой фактически,
и rpmbuild просто формализует сложившееся положение вещей.


-- 
ldv

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

Re: [devel] osec_rpm_reporter

[Alexey Gladkov]

26.01.2013 16:25, Dmitry V. Levin wrote:
> osec_rpm_reporter это чистый фильтр, stdin на входе, stdout на выходе,
> и /var/lib/rpm/ сбоку для консультаций.  Он не использует osec, и osec
> не использует его.  Его можно было бы установить и использовать отдельно
> от osec, например:
> $ echo ' - /bin/ls' | osec_rpm_reporter
> 	- [coreutils] /bin/ls

osec_reporter тоже чистый фильтр.

> К чему это я говорю?  Если тебя смущает зависимость osec на perl-RPM,
> адресуй свои претензии мейнтейнеру пакета osec, который (за компанию,
> потому что так исторически сложилось) сделал так, что уже сейчас, вне
> зависимости от strict/nonstrict deps, невозможно установить osec без
> практически никем не используемого фильтра osec_rpm_reporter, который,
> в свою очередь, использует perl-RPM.

Ну что ты ... конечно можно. Я замечательно его использую без пакета
osec-mailreport. Я уверен, что и ты это знаешь.

> Не говоря уже о том, что если бы osec_rpm_reporter действительно
> использовался, то переписать его на C не составило бы труда.

Из noarch пакета сделать arch с зависимостью на librpm с устаревшим
API ? И кому этот "фильтр" будет нужен кроме, как в альте ?

> Поскольку альтернатив osec-mailreport'у нет, зависимость на реализуемый им
> osec-reporter, не будучи формально строгой, является строгой фактически,
> и rpmbuild просто формализует сложившееся положение вещей.

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

-- 
Rgrds, legion

Re: [devel] osec_rpm_reporter

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 04:46:09PM +0400, Alexey Gladkov wrote:
> 26.01.2013 16:25, Dmitry V. Levin wrote:
> > osec_rpm_reporter это чистый фильтр, stdin на входе, stdout на выходе,
> > и /var/lib/rpm/ сбоку для консультаций.  Он не использует osec, и osec
> > не использует его.  Его можно было бы установить и использовать отдельно
> > от osec, например:
> > $ echo ' - /bin/ls' | osec_rpm_reporter
> > 	- [coreutils] /bin/ls
> 
> osec_reporter тоже чистый фильтр.
> 
> > К чему это я говорю?  Если тебя смущает зависимость osec на perl-RPM,
> > адресуй свои претензии мейнтейнеру пакета osec, который (за компанию,
> > потому что так исторически сложилось) сделал так, что уже сейчас, вне
> > зависимости от strict/nonstrict deps, невозможно установить osec без
> > практически никем не используемого фильтра osec_rpm_reporter, который,
> > в свою очередь, использует perl-RPM.
> 
> Ну что ты ... конечно можно. Я замечательно его использую без пакета
> osec-mailreport. Я уверен, что и ты это знаешь.

В Сизифе это невозможно.  Каждый может собрать пакет из исходного кода,
и использовать его как угодно, но это не решение проблемы того, что osec
невозможно установить без perl-RPM, а уход от нее (если считать, что
зависимость от perl-RPM это проблема).

> > Не говоря уже о том, что если бы osec_rpm_reporter действительно
> > использовался, то переписать его на C не составило бы труда.
> 
> Из noarch пакета сделать arch

osec-mailreport-1.2.5-alt2.x86_64.rpm это noarch-пакет?
Если ты действительно так считаешь, то почему rpm не в курсе?

> с зависимостью на librpm с устаревшим
> API ? И кому этот "фильтр" будет нужен кроме, как в альте ?

Можно было бы поставить #ifdef.  Впрочем, где еще, кроме как в альте,
зависимость маргинального скрипта от perl-RPM могла бы обсуждаться как
потенциальная проблема?

> > Поскольку альтернатив osec-mailreport'у нет, зависимость на реализуемый им
> > osec-reporter, не будучи формально строгой, является строгой фактически,
> > и rpmbuild просто формализует сложившееся положение вещей.
> 
> Ну что мне сделать, запаковать тебе альтернативный фильтр, чтобы ты
> признал, что это возможно?

У тебя есть настоящий, полезный альтернативный фильтр, и ты его еще не
упаковал?  У меня нет слов.

> Тогда ты признаешь, что тут нужна не строгая зависимость?

Если это будет альтернатива (не фиктивная) osec-mailreport'у, то это будет
первый известный мне случай в Сизифе, и я верну
%_allowed_nonstrict_interdeps с условием не использовать этот макрос в
apache2. :)


-- 
ldv

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

Re: [devel] osec_rpm_reporter

[Alexey Gladkov]

26.01.2013 17:05, Dmitry V. Levin wrote:

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

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

В ближайшее время я пересоберу пакет с жёсткой зависимостью.

-- 
Rgrds, legion

Re: [devel] non-strict deps

[Aleksey Avdeev]

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

25.01.2013 16:51, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 04:39:39PM +0400, Aleksey Avdeev wrote:
>> 25.01.2013 16:32, Dmitry V. Levin пишет:
>>> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
>>>> 25.01.2013 14:53, Dmitry V. Levin wrote:
>>>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>>>> только один класс зависимостей, которые нужно сохранить,
>>>>> а все остальные следует сделать строгими.
>>>>
>>>> Можно ли рассказать подробнее т.к. меня это касается?
>>>
>>> Тестируется следующий алгоритм: подпакет A исходного пакета S
>>> автоматически получает строгую зависимость на подпакет B исходного
>>> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
>>> является единственным подпакетом исходного пакета S, удовлетворяющим
>>> эту зависимость X.
>>
>> 1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
>> под пакетом данного исходного S) который тоже предоставляет зависимость X?
> 
> Такой пакет С не будет приниматься в рассмотрение этим алгоритмом.

  И получается подмена зависимости на функционал -- жёсткой привязкой к
апстримнуму комплекту...

> 
>> 2. Как обеспечить равноценность подпакета B и пакета C для подпакета A?
>> (Чтобы администратор мог свободно выбрать из комбинаций A+B и A+C нужную.)
> 
> Я бы не хотел реализовывать такую возможность без необходимости.
> Надеюсь, что такой необходимости не возникнет.
> Все примеры, которые я видел за последние два дня, были более чем
> искусственными.

  Я так не считаю. Поставить строгую зависимость всегда проще. Если
руками поставлена нестрогая (и приняты меры защит от ошибок её
разрешения) -- значит скорее всего не на пустом месте все приведённые
примеры образовались.

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps

[Led]

On Friday 25 January 2013 15:01:14 Aleksey Avdeev wrote:
> 25.01.2013 16:51, Dmitry V. Levin пишет:
> > On Fri, Jan 25, 2013 at 04:39:39PM +0400, Aleksey Avdeev wrote:
> >> 25.01.2013 16:32, Dmitry V. Levin пишет:
> >>> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> >>>> 25.01.2013 14:53, Dmitry V. Levin wrote:
> >>>>> Проанализировав множество нестрогих внутрипакетных зависимостей,
> >>>>> которые диагностирует rpm-build, я пришел к выводу, что среди них
> >>>>> выделяется только один класс зависимостей, которые нужно сохранить,
> >>>>> а все остальные следует сделать строгими.
> >>>>
> >>>> Можно ли рассказать подробнее т.к. меня это касается?
> >>>
> >>> Тестируется следующий алгоритм: подпакет A исходного пакета S
> >>> автоматически получает строгую зависимость на подпакет B исходного
> >>> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> >>> является единственным подпакетом исходного пакета S, удовлетворяющим
> >>> эту зависимость X.
> >>
> >> 1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
> >> под пакетом данного исходного S) который тоже предоставляет зависимость
> >> X?
> >
> > Такой пакет С не будет приниматься в рассмотрение этим алгоритмом.
>
>   И получается подмена зависимости на функционал -- жёсткой привязкой к
> апстримнуму комплекту...

Вот именно. Нередкий случай, когда пакет предоставляет какой-то минимальный 
функционал, вынесенный в субпакет, а более "навороченныц" вариант 
предоставляется совершенно другим пакетом (собираемым отдельно). Или наборот.
Теперь про это можно забыть :(


-- 
Led

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:54:36PM +0200, Led wrote:
> On Friday 25 January 2013 15:01:14 Aleksey Avdeev wrote:
> > 25.01.2013 16:51, Dmitry V. Levin пишет:
> > > On Fri, Jan 25, 2013 at 04:39:39PM +0400, Aleksey Avdeev wrote:
> > >> 25.01.2013 16:32, Dmitry V. Levin пишет:
> > >>> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > >>>> 25.01.2013 14:53, Dmitry V. Levin wrote:
> > >>>>> Проанализировав множество нестрогих внутрипакетных зависимостей,
> > >>>>> которые диагностирует rpm-build, я пришел к выводу, что среди них
> > >>>>> выделяется только один класс зависимостей, которые нужно сохранить,
> > >>>>> а все остальные следует сделать строгими.
> > >>>>
> > >>>> Можно ли рассказать подробнее т.к. меня это касается?
> > >>>
> > >>> Тестируется следующий алгоритм: подпакет A исходного пакета S
> > >>> автоматически получает строгую зависимость на подпакет B исходного
> > >>> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> > >>> является единственным подпакетом исходного пакета S, удовлетворяющим
> > >>> эту зависимость X.
> > >>
> > >> 1. Что произойдёт, если в репозитории есть другой пакет С (не являющийся
> > >> под пакетом данного исходного S) который тоже предоставляет зависимость
> > >> X?
> > >
> > > Такой пакет С не будет приниматься в рассмотрение этим алгоритмом.
> >
> >   И получается подмена зависимости на функционал -- жёсткой привязкой к
> > апстримнуму комплекту...
> 
> Вот именно. Нередкий случай, когда пакет предоставляет какой-то минимальный 
> функционал, вынесенный в субпакет, а более "навороченныц" вариант 
> предоставляется совершенно другим пакетом (собираемым отдельно). Или наборот.

Нередкий?  Хотя бы один реальный пример можно привести?


-- 
ldv

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

Re: [devel] non-strict deps Зачем?

[Alexey Gladkov]

25.01.2013 19:11, Dmitry V. Levin wrote:
>> Вот именно. Нередкий случай, когда пакет предоставляет какой-то минимальный 
>> функционал, вынесенный в субпакет, а более "навороченныц" вариант 
>> предоставляется совершенно другим пакетом (собираемым отдельно). Или наборот.
> 
> Нередкий?  Хотя бы один реальный пример можно привести?

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

Лично я в тредах не вижу от тебя других аргументов, кроме "я так хочу".

Мы все доказываем и обосновываем тебе, что они нужны. Хотя мне
кажется, что должно быть наоборот и ты должен обосновать, что они не
нужны.

-- 
Rgrds, legion

Re: [devel] non-strict deps Зачем?

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 03:30:49PM +0400, Alexey Gladkov wrote:
> 25.01.2013 19:11, Dmitry V. Levin wrote:
> >> Вот именно. Нередкий случай, когда пакет предоставляет какой-то минимальный 
> >> функционал, вынесенный в субпакет, а более "навороченныц" вариант 
> >> предоставляется совершенно другим пакетом (собираемым отдельно). Или наборот.
> > 
> > Нередкий?  Хотя бы один реальный пример можно привести?
> 
> Дим, а можно услышать обоснование обратного т.е. почему нестрогие
> зависимости на подпакет в одном исходном вреден?

Разве это не очевидно?  Вы же не первый год в теме, и знаете, что
одновременная установка подпакета одной версии с подпакетом другой версии
чревата большими неприятностями, такие смешанные установки вряд ли кто-то
в состоянии полноценно протестировать, поэтому лучшее, что мы можем
сделать - это избегать их.  Помимо повышения качества, строгие межпакетные
зависимости открывают возможность оптимизации зависимостей.  Если подпакет
A использует что-то, предоставляемое подпакетом B, то строгая зависимость
A от B позволяет rpmbuild'у убрать из A все остальные зависимости,
удовлетворяемые подпакетом B.  Посмотрите на логи сборки, и почти в каждом
пакете, содержащем подпакеты, вы увидите сообщения вида
removing N extra deps from ...
Нередко из одного подпакета удается убрать двузначное число таких
избыточных зависимостей.  А чем меньше зависимостей, тем быстрее
происходит работа с пакетной базой.

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

> Мы все доказываем и обосновываем тебе, что они нужны.

Нет, вы не доказываете.  Вы говорите, что в принципе возможны ситуации,
когда описанный мной алгоритм определения того, нужно ли зависимость
автоматически делать строгой, неприменим.  Я знаю, что такие ситуации
теоретически возможны, и тоже могу сочинить демонстрационный пример.
Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько
мало, что я за два дня не нашел.  Помогите мне, найдите этот реальный
пример, тогда я верну механизм %_allowed_nonstrict_interdeps.


-- 
ldv

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

Re: [devel] non-strict deps Зачем?

[Alexey Gladkov]

26.01.2013 16:08, Dmitry V. Levin wrote:
> Разве это не очевидно?  Вы же не первый год в теме, и знаете, что
> одновременная установка подпакета одной версии с подпакетом другой версии
> чревата большими неприятностями, такие смешанные установки вряд ли кто-то
> в состоянии полноценно протестировать, поэтому лучшее, что мы можем
> сделать - это избегать их.

Это не очевидно.

Нестрогие зависимости это инструмент. Он не может быть хорош или плох.
Любой инструмент если его неправильно применять будет приносить вред.
Стоит ли бороться с неправильным применением того или иного
инструмента? Конечно да. Нужно ли из-за потенциального вреда запрещать
инструмент? Мне кажется, что нет.

Ты можешь привести конкретный пример из сизифа (как ты любишь), где
нестрогая зависимость вызывает проблемы ?

>> Мы все доказываем и обосновываем тебе, что они нужны.
> 
> Нет, вы не доказываете.

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

>  Я знаю, что такие ситуации
> теоретически возможны, и тоже могу сочинить демонстрационный пример.

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

> Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько
> мало, что я за два дня не нашел.  Помогите мне, найдите этот реальный
> пример, тогда я верну механизм %_allowed_nonstrict_interdeps.

И всё-таки давай вернёмся к osec. Пока есть хотя бы один пакет общее
правило не применимо. Пока ты упорно игнорируешь этот случай.

Обоснуй почему в этом пакете _должны_ быть жёсткие зависимости в
подпакетах и я их там проставлю.

Пока ты пытаешься убедить меня, что я "Мао Цзэдун" что я никуда
денусь, проставлю жёсткие никому не нужные зависимости и приведу
ситуацию к общему случаю потому что так удобнее (видимо тебе).

-- 
Rgrds, legion

Re: [devel] non-strict deps Зачем?

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 04:35:37PM +0400, Alexey Gladkov wrote:
> 26.01.2013 16:08, Dmitry V. Levin wrote:
> > Разве это не очевидно?  Вы же не первый год в теме, и знаете, что
> > одновременная установка подпакета одной версии с подпакетом другой версии
> > чревата большими неприятностями, такие смешанные установки вряд ли кто-то
> > в состоянии полноценно протестировать, поэтому лучшее, что мы можем
> > сделать - это избегать их.
> 
> Это не очевидно.

Это не вполне тривиально, но все равно очевидно.

> Нестрогие зависимости это инструмент. Он не может быть хорош или плох.

Нестрогие зависимости редко когда инструмент, чаще это свойство.

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

Ты думаешь, что это умозрительная проблема?  Я несколько дней назад
посмотрел, что это за нечеткие зависимости в 659 исходных пакетах.
Там около процента альтернативных провайдеров типа vim-X11-* и
apache2-httpd-*, и очень много типовых ошибок упаковки, например,
нестрогая зависимость на используемую библиотеку (в пакете нет зависимости
вообще, а нестрогую зависимость на библиотеку вычислил find-requires).
В этой ситуации сложнее привести пример, когда отсутствие строгой
зависимости не создает проблемы точечного обновления.  set-versions
отслеживает только имена функций, этого не всегда бывает достаточно,
на эту тему висят баги:
https://bugzilla.altlinux.org/show_bug.cgi?id=28383
Если обновить библиотеку, в которой не поменялся soname, но не обновить
devel-пакет (таких возможностей сейчас очень много), то можно получить
devel-пакет, в котором API не соответствует ABI в библиотеке.

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

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

Необходимость запрета очевидна, неочевидна необходимость тотального
запрета. :)

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

Я оставляю возможность такого механизма.

> > Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько
> > мало, что я за два дня не нашел.  Помогите мне, найдите этот реальный
> > пример, тогда я верну механизм %_allowed_nonstrict_interdeps.
> 
> И всё-таки давай вернёмся к osec. Пока есть хотя бы один пакет общее
> правило не применимо. Пока ты упорно игнорируешь этот случай.

osec мы с тобой обсуждаем в соседнем треде. :)


-- 
ldv

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

Re: [devel] non-strict deps Зачем?

[Aleksey Avdeev]

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

26.01.2013 17:32, Dmitry V. Levin пишет:
> On Sat, Jan 26, 2013 at 04:35:37PM +0400, Alexey Gladkov wrote:
>> 26.01.2013 16:08, Dmitry V. Levin wrote:
>>> Разве это не очевидно?  Вы же не первый год в теме, и знаете, что
>>> одновременная установка подпакета одной версии с подпакетом другой версии
>>> чревата большими неприятностями, такие смешанные установки вряд ли кто-то
>>> в состоянии полноценно протестировать, поэтому лучшее, что мы можем
>>> сделать - это избегать их.
>>
>> Это не очевидно.
> 
> Это не вполне тривиально, но все равно очевидно.

  Это далеко не очевидно. Для меня очевидно обратное, когда речь идёт о
внутрипакетных зависимостях подпакетов с конфигами (вариантами
конфигурации чего либо) и модулями -- и в том и в другом случаи для меня
очевидна ценность возможностей:

а) обновить только заданный подпакет, не трогая остальное;

б) поставить подпакет на hold и обновить остальное;

в) заменить подпакет его альтернативой, собранной из другого источника.

  Да, этими возможностями можно пользоваться не всегда: изменения
интерфейса работы с модулями (его ABI) и инфраструктурные изменения в
подсистемах могут приводить к нерабочим конфигурациям. Но такие
конфигурации можно отстрелить вдумчивой расстановкой
Provides/Conflicts/Requires и указанием зависимостей на файлы/каталоги.

> 
>> Нестрогие зависимости это инструмент. Он не может быть хорош или плох.
> 
> Нестрогие зависимости редко когда инструмент, чаще это свойство.

  В моих пакетах это именно инструмент. И ручная работа над
Provides/Conflicts/Requires и файловыми зависимостями (с соответсвующей
потерей времени) -- плата за его применение.

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

> 
>> Любой инструмент если его неправильно применять будет приносить вред.
>> Стоит ли бороться с неправильным применением того или иного
>> инструмента? Конечно да. Нужно ли из-за потенциального вреда запрещать
>> инструмент? Мне кажется, что нет.
>>
>> Ты можешь привести конкретный пример из сизифа (как ты любишь), где
>> нестрогая зависимость вызывает проблемы ?
> 
> Ты думаешь, что это умозрительная проблема?  Я несколько дней назад
> посмотрел, что это за нечеткие зависимости в 659 исходных пакетах.
> Там около процента альтернативных провайдеров типа vim-X11-* и
> apache2-httpd-*,

  Сделанных мантейнерами _руками_, под их ответственность. Именно для
них и нужна ручка, применение которой будет говорить о том, что
мантейнер _знает_ что именно он делает (или что он считает что это так).

> и очень много типовых ошибок упаковки, например,
> нестрогая зависимость на используемую библиотеку (в пакете нет зависимости
> вообще, а нестрогую зависимость на библиотеку вычислил find-requires).

  Здесь автозамена зависимостей на строгие нужна.

> В этой ситуации сложнее привести пример, когда отсутствие строгой
> зависимости не создает проблемы точечного обновления.  set-versions
> отслеживает только имена функций, этого не всегда бывает достаточно,
> на эту тему висят баги:
> https://bugzilla.altlinux.org/show_bug.cgi?id=28383
> Если обновить библиотеку, в которой не поменялся soname, но не обновить
> devel-пакет (таких возможностей сейчас очень много), то можно получить
> devel-пакет, в котором API не соответствует ABI в библиотеке.

  Между devel-пакетом и соответствующей ему библиотекой -- тоже.

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

  Согласен полностью! Но не стоит под эту гребёнку вести случаи, где
нестрогие зависимости мантейнер расставлял сам, руками!!!

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

1. Очевидна _безусловная_ необходимость запрета для связки библиотеки и
её devel пакет. Возможно даже не только для библиотек, а вообще для всех
подпакетов, требующихся для собираемого devel пакета.

2. Возможно полезен (но всё таки не очевиден) безусловный запрет
нестрогих зависимостей для подпакетов связвнных через set-versions.

3. Очевиден вред от безусловного запрета нестрогих зависимостей для того
что не попадает под пункты 1-2. Это конфиги, части не входящие в ядро
пакета, но собираемые из одного источника (такие как модули) и пр.
подобное. 3десь очевидна нужность нужен запрета по умолчанию, с
возможностью его _ручного_ отключения.

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

  Т. е. ручка всё таки будет? УРА!!! :-)

> 
>>> Но на практике в Сизифе таких примеров либо нет совсем, либо их настолько
>>> мало, что я за два дня не нашел.  Помогите мне, найдите этот реальный
>>> пример, тогда я верну механизм %_allowed_nonstrict_interdeps.
>>
>> И всё-таки давай вернёмся к osec. Пока есть хотя бы один пакет общее
>> правило не применимо. Пока ты упорно игнорируешь этот случай.
> 
> osec мы с тобой обсуждаем в соседнем треде. :)

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps Зачем?

[Sergey V Turchin]

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

On Saturday 26 January 2013 16:08:56 Dmitry V wrote:

[...]
> Но на практике в Сизифе таких примеров либо нет совсем
Предлагаю не идти на поводу у заблуждения, что мир состоит из одного Сизифа.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] non-strict deps

[Alexey Gladkov]

25.01.2013 16:32, Dmitry V. Levin wrote:
> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
>> 25.01.2013 14:53, Dmitry V. Levin wrote:
>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>> только один класс зависимостей, которые нужно сохранить,
>>> а все остальные следует сделать строгими.
>>
>> Можно ли рассказать подробнее т.к. меня это касается?
> 
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

Т.е. если подпакет A имеет зависимость на некий функционал, который
может быть предоставлен другим пакетом и который предоставляет
подпакет B (эталонная реализация), то A получит жёсткую зависимость на
B ???

Это сильно затрудняет работу с виртуальными зависимостями, когда один
кандидатов собирается из того же исходника.

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

-- 
Rgrds, legion

Re: [devel] non-strict deps

[Aleksey Avdeev]

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

25.01.2013 16:46, Alexey Gladkov пишет:
> 25.01.2013 16:32, Dmitry V. Levin wrote:
>> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
>>> 25.01.2013 14:53, Dmitry V. Levin wrote:
>>>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
>>>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
>>>> только один класс зависимостей, которые нужно сохранить,
>>>> а все остальные следует сделать строгими.
>>>
>>> Можно ли рассказать подробнее т.к. меня это касается?
>>
>> Тестируется следующий алгоритм: подпакет A исходного пакета S
>> автоматически получает строгую зависимость на подпакет B исходного
>> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
>> является единственным подпакетом исходного пакета S, удовлетворяющим
>> эту зависимость X.
> 
> Т.е. если подпакет A имеет зависимость на некий функционал, который
> может быть предоставлен другим пакетом и который предоставляет
> подпакет B (эталонная реализация), то A получит жёсткую зависимость на
> B ???
> 
> Это сильно затрудняет работу с виртуальными зависимостями, когда один
> кандидатов собирается из того же исходника.
> 
> В таком случае решением своей проблемы я вижу вынос пакета B в
> отдельный исходный пакет. Это сложнее для сопровождения, но логичнее в
> плане зависимостей.

  +1

  Потому и бодаюсь на эту тему.

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:46:52PM +0400, Alexey Gladkov wrote:
> 25.01.2013 16:32, Dmitry V. Levin wrote:
> > On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> >> 25.01.2013 14:53, Dmitry V. Levin wrote:
> >>> Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> >>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> >>> только один класс зависимостей, которые нужно сохранить,
> >>> а все остальные следует сделать строгими.
> >>
> >> Можно ли рассказать подробнее т.к. меня это касается?
> > 
> > Тестируется следующий алгоритм: подпакет A исходного пакета S
> > автоматически получает строгую зависимость на подпакет B исходного
> > пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> > является единственным подпакетом исходного пакета S, удовлетворяющим
> > эту зависимость X.
> 
> Т.е. если подпакет A имеет зависимость на некий функционал, который
> может быть предоставлен другим пакетом и который предоставляет
> подпакет B (эталонная реализация), то A получит жёсткую зависимость на
> B ???
> 
> Это сильно затрудняет работу с виртуальными зависимостями, когда один
> кандидатов собирается из того же исходника.

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

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

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


-- 
ldv

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

Re: [devel] non-strict deps

[Sergey V Turchin]

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

On Friday 25 January 2013 16:58:12 Dmitry V wrote:
> On Fri, Jan 25, 2013 at 04:46:52PM +0400, Alexey Gladkov wrote:
> > 25.01.2013 16:32, Dmitry V. Levin wrote:
> > > On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > >> 25.01.2013 14:53, Dmitry V. Levin wrote:
> > >>> Проанализировав множество нестрогих внутрипакетных зависимостей,
> > >>> которые
> > >>> диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> > >>> только один класс зависимостей, которые нужно сохранить,
> > >>> а все остальные следует сделать строгими.
> > >> 
> > >> Можно ли рассказать подробнее т.к. меня это касается?
> > > 
> > > Тестируется следующий алгоритм: подпакет A исходного пакета S
> > > автоматически получает строгую зависимость на подпакет B исходного
> > > пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> > > является единственным подпакетом исходного пакета S, удовлетворяющим
> > > эту зависимость X.
> > 
> > Т.е. если подпакет A имеет зависимость на некий функционал, который
> > может быть предоставлен другим пакетом и который предоставляет
> > подпакет B (эталонная реализация), то A получит жёсткую зависимость на
> > B ???
> > 
> > Это сильно затрудняет работу с виртуальными зависимостями, когда один
> > кандидатов собирается из того же исходника.
> 
> Есть ли в Сизифе реальный пример подобного безобразия, который хотелось бы
> поддержать?  Я не вижу такого.
Теперь, когда я придложил отключить из-за этого проверку на не-жесткие 
зависимости, ты стал называть это безобразием :-)
Но, у меня еще есть в запасе нечто более серьезное, к чему докопаться ;-)

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] non-strict deps

[Sergei Epiphanov]

On 25 января 2013 16:32 Dmitry V. Levin wrote:
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

Тогда вопрос: была собрана пачка пакетов со строгой зависимостью. Позже 
появился другой пакет, который может предоставить решение зависимости X. 
Пересобирать S, чтобы убрать строгую зависимость A на B? Зачем?

-- 
С уважением, Епифанов Сергей

Re: [devel] non-strict deps

[Led]

On Friday 25 January 2013 14:32:49 Dmitry V. Levin wrote:
> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > 25.01.2013 14:53, Dmitry V. Levin wrote:
> > > Проанализировав множество нестрогих внутрипакетных зависимостей,
> > > которые диагностирует rpm-build, я пришел к выводу, что среди них
> > > выделяется только один класс зависимостей, которые нужно сохранить,
> > > а все остальные следует сделать строгими.
> >
> > Можно ли рассказать подробнее т.к. меня это касается?
>
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

Субпакеты нужны для того, чтобы а) уменьшить место, занимаемое на диске путём 
установки только действительно необходимых субпакетов; б) для предоставления 
альтернатив предоставления зависимостей (в т.ч. и через виртуальные 
зависимости).
Учитывая то, что первое сейчас на порядок менее актуально, чем 10 лет назад и 
становится всё менее актуальным, а второе вы, похоже, намерены выпилить 
совсем, возникает вопрос: а зачем тогда вообще субпакеты?

-- 
Led

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:49:17PM +0200, Led wrote:
> On Friday 25 January 2013 14:32:49 Dmitry V. Levin wrote:
> > On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > > 25.01.2013 14:53, Dmitry V. Levin wrote:
> > > > Проанализировав множество нестрогих внутрипакетных зависимостей,
> > > > которые диагностирует rpm-build, я пришел к выводу, что среди них
> > > > выделяется только один класс зависимостей, которые нужно сохранить,
> > > > а все остальные следует сделать строгими.
> > >
> > > Можно ли рассказать подробнее т.к. меня это касается?
> >
> > Тестируется следующий алгоритм: подпакет A исходного пакета S
> > автоматически получает строгую зависимость на подпакет B исходного
> > пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> > является единственным подпакетом исходного пакета S, удовлетворяющим
> > эту зависимость X.
> 
> Субпакеты нужны для того, чтобы а) уменьшить место, занимаемое на диске путём 
> установки только действительно необходимых субпакетов; б) для предоставления 
> альтернатив предоставления зависимостей (в т.ч. и через виртуальные 
> зависимости).
> Учитывая то, что первое сейчас на порядок менее актуально, чем 10 лет назад и 
> становится всё менее актуальным,

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

> а второе вы, похоже, намерены выпилить совсем,

Кого выпилить? "альтернативные" подпакеты сохраняются, уходят только
слабые (они же зачастую битые) зависимости.  В результате зависимостей
станет меньше (за счет оптимизации; например, в случае с kde4 избыточных
зависимостей должно стать существенно меньше), и они будут работать
точнее.

И, надеюсь, удастся победить злоупотребление зависимостями, такое как
apache2 + apache-html и apache + apache2-html.


-- 
ldv

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

Re: [devel] non-strict deps

[Aleksey Avdeev]

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

25.01.2013 19:09, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 04:49:17PM +0200, Led wrote:
>> On Friday 25 January 2013 14:32:49 Dmitry V. Levin wrote:
>>> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
>>>> 25.01.2013 14:53, Dmitry V. Levin wrote:
>>>>> Проанализировав множество нестрогих внутрипакетных зависимостей,
>>>>> которые диагностирует rpm-build, я пришел к выводу, что среди них
>>>>> выделяется только один класс зависимостей, которые нужно сохранить,
>>>>> а все остальные следует сделать строгими.
>>>>
>>>> Можно ли рассказать подробнее т.к. меня это касается?
>>>
>>> Тестируется следующий алгоритм: подпакет A исходного пакета S
>>> автоматически получает строгую зависимость на подпакет B исходного
>>> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
>>> является единственным подпакетом исходного пакета S, удовлетворяющим
>>> эту зависимость X.
>>
>> Субпакеты нужны для того, чтобы а) уменьшить место, занимаемое на диске путём 
>> установки только действительно необходимых субпакетов; б) для предоставления 
>> альтернатив предоставления зависимостей (в т.ч. и через виртуальные 
>> зависимости).
>> Учитывая то, что первое сейчас на порядок менее актуально, чем 10 лет назад и 
>> становится всё менее актуальным,
> 
> Почему это?  Сборочные среды работают эффективнее, и бутстрапы даются
> проще, когда при установке необходимого не вытягивается весь репозиторий.
> Так что не соглашусь.
> 
>> а второе вы, похоже, намерены выпилить совсем,
> 
> Кого выпилить? "альтернативные" подпакеты сохраняются, уходят только
> слабые (они же зачастую битые) зависимости.  В результате зависимостей
> станет меньше (за счет оптимизации; например, в случае с kde4 избыточных
> зависимостей должно стать существенно меньше), и они будут работать
> точнее.
> 
> И, надеюсь, удастся победить злоупотребление зависимостями, такое как
> apache2 + apache-html и apache + apache2-html.

  Проблема в том, что я _не_считаю_ это злоупотреблением. На мой взгляд
это корректная конструкция позволяющая:

а) Подсунуть вместо apache{,2}-html любой другой пакет (предоставляющий
webserver-html). Например, разработчик дистрибутива может использовать
my_distr-html.

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

1. Берётся подходящий (наиболее похожий на то что нужно в конечном
итоге) apache{,2}-html в качестве основы.

2. Взятый apache{,2}-html ставиться на HOLD.

3. Содержимое /var/www/html хачится под конкретную задачу...

  И в текущей ситуации можно спокойно обновлять apache* (в том числе и
свободно менять apache <-> apache2), не беспокоясь о сохранности
содержимого /var/www/html.

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps

[Sergey V Turchin]

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

On Friday 25 January 2013 19:09:40 Dmitry V wrote:

[...]
> в случае с kde4 избыточных
> зависимостей должно стать существенно меньше)
И подпакетов тоже.

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 07:32:16PM +0400, Sergey V Turchin wrote:
> On Friday 25 January 2013 19:09:40 Dmitry V wrote:
> 
> [...]
> > в случае с kde4 избыточных
> > зависимостей должно стать существенно меньше)
> И подпакетов тоже.

Это будет решать мейнтейнер kde4, на данной стадии развития
rpmbuild число подпакетов не регулирует. :)


-- 
ldv

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

Re: [devel] non-strict deps

[Sergey V Turchin]

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

On Friday 25 January 2013 19:38:17 Dmitry V wrote:
> On Fri, Jan 25, 2013 at 07:32:16PM +0400, Sergey V Turchin wrote:
> > On Friday 25 January 2013 19:09:40 Dmitry V wrote:
> > 
> > [...]
> > 
> > > в случае с kde4 избыточных
> > > зависимостей должно стать существенно меньше)
> > 
> > И подпакетов тоже.
> 
> Это будет решать мейнтейнер kde4, на данной стадии развития
> rpmbuild число подпакетов не регулирует. :)
Мантейнер rpmbuild это регулирует ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

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

Re: [devel] non-strict deps

[Sergey Vlasov]

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

On Fri, Jan 25, 2013 at 04:32:49PM +0400, Dmitry V. Levin wrote:
> On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > 25.01.2013 14:53, Dmitry V. Levin wrote:
> > > Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> > > диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> > > только один класс зависимостей, которые нужно сохранить,
> > > а все остальные следует сделать строгими.
> > 
> > Можно ли рассказать подробнее т.к. меня это касается?
> 
> Тестируется следующий алгоритм: подпакет A исходного пакета S
> автоматически получает строгую зависимость на подпакет B исходного
> пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> является единственным подпакетом исходного пакета S, удовлетворяющим
> эту зависимость X.

Насколько я понимаю, описанный выше алгоритм преобразования
зависимостей сработает в следующей ситуации:

%package -n A
Requires: X

%package -n B
Provides: X

(и нет других подпакетов с Provides: X)

В результате подпакет A вместо зависимости на виртуальный пакет X
должен получить зависимость вида B = %EVR ?

На мой взгляд, это неправильно - если в зависимости явно указано имя
виртуального пакета, скорее всего, это сделано намеренно, и такую
зависимость необходимо оставлять в том виде, как она есть.  А вот
зависимость вида Requires: B, где B - имя реального подпакета,
действительно стоит автоматически дополнять "= %EVR" (естественно,
учитывая, что у подпакета может присутствовать собственный тег
Version: или Release:).

Пример реально существующего в Сизифе пакета, который сломается при
введении предлагаемого алгоритма - xboard, где в основном пакете
указано Requires: xboard-theme, а также собирается единственный
подпакет xboard-theme-default, имеющий Provides: xboard-theme, но при
этом в репозитории присутствуют и несколько отдельных пакетов
xboard-theme-*, также предоставляющих xboard-theme.

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

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 05:30:40PM +0400, Sergey Vlasov wrote:
> On Fri, Jan 25, 2013 at 04:32:49PM +0400, Dmitry V. Levin wrote:
> > On Fri, Jan 25, 2013 at 04:13:23PM +0400, Alexey Gladkov wrote:
> > > 25.01.2013 14:53, Dmitry V. Levin wrote:
> > > > Проанализировав множество нестрогих внутрипакетных зависимостей, которые
> > > > диагностирует rpm-build, я пришел к выводу, что среди них выделяется
> > > > только один класс зависимостей, которые нужно сохранить,
> > > > а все остальные следует сделать строгими.
> > > 
> > > Можно ли рассказать подробнее т.к. меня это касается?
> > 
> > Тестируется следующий алгоритм: подпакет A исходного пакета S
> > автоматически получает строгую зависимость на подпакет B исходного
> > пакета S, если у подпакета A есть такая зависимость X, что подпакет B
> > является единственным подпакетом исходного пакета S, удовлетворяющим
> > эту зависимость X.
> 
> Насколько я понимаю, описанный выше алгоритм преобразования
> зависимостей сработает в следующей ситуации:
> 
> %package -n A
> Requires: X
> 
> %package -n B
> Provides: X
> 
> (и нет других подпакетов с Provides: X)
> 
> В результате подпакет A вместо зависимости на виртуальный пакет X
> должен получить зависимость вида B = %EVR ?

Да.

> На мой взгляд, это неправильно - если в зависимости явно указано имя
> виртуального пакета, скорее всего, это сделано намеренно, и такую
> зависимость необходимо оставлять в том виде, как она есть.

А если неявно?  Если это find-requires нашел зависимость на soname,
ее ведь надо превращать в строгую зависимость на пакет.

Другими словами, предлагается модифицировать алгоритм, чтобы он работал
следующим образом: подпакет A исходного пакета S автоматически получает
строгую зависимость от подпакета B исходного пакета S, если выполнено любое
из следующих условий:
- у A есть зависимость от B;
- у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
  является единственным подпакетом S, удовлетворяющим эту зависимость X.

> А вот
> зависимость вида Requires: B, где B - имя реального подпакета,
> действительно стоит автоматически дополнять "= %EVR" (естественно,
> учитывая, что у подпакета может присутствовать собственный тег
> Version: или Release:).

Разумеется, в каждом случае используется EVR того подпакета,
на который выставляется строгая зависимость.

> Пример реально существующего в Сизифе пакета, который сломается при
> введении предлагаемого алгоритма - xboard, где в основном пакете
> указано Requires: xboard-theme, а также собирается единственный
> подпакет xboard-theme-default, имеющий Provides: xboard-theme, но при
> этом в репозитории присутствуют и несколько отдельных пакетов
> xboard-theme-*, также предоставляющих xboard-theme.

Принято.


-- 
ldv

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

Re: [devel] non-strict deps

[Sergey Vlasov]

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

On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
> On Sat, Jan 26, 2013 at 05:30:40PM +0400, Sergey Vlasov wrote:
[...]
> > На мой взгляд, это неправильно - если в зависимости явно указано имя
> > виртуального пакета, скорее всего, это сделано намеренно, и такую
> > зависимость необходимо оставлять в том виде, как она есть.
> 
> А если неявно?  Если это find-requires нашел зависимость на soname,
> ее ведь надо превращать в строгую зависимость на пакет.

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

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

> Другими словами, предлагается модифицировать алгоритм, чтобы он работал
> следующим образом: подпакет A исходного пакета S автоматически получает
> строгую зависимость от подпакета B исходного пакета S, если выполнено любое
> из следующих условий:
> - у A есть зависимость от B;
> - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
>   является единственным подпакетом S, удовлетворяющим эту зависимость X.

Это уже похоже на правильный вариант (в случае, если мантейнер по
каким-то причинам хочет разрешить смешивать подпакеты разных версий,
ему достаточно сделать для этих подпакетов виртуальные пакеты с
зависимостями нужной строгости - например, с чем-то типа %abi_version
в версии таких виртуальных пакетов).

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

Re: [devel] non-strict deps

[Aleksey Avdeev]

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

26.01.2013 20:19, Sergey Vlasov пишет:
> On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
...
>> Другими словами, предлагается модифицировать алгоритм, чтобы он работал
>> следующим образом: подпакет A исходного пакета S автоматически получает
>> строгую зависимость от подпакета B исходного пакета S, если выполнено любое
>> из следующих условий:
>> - у A есть зависимость от B;
>> - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
>>   является единственным подпакетом S, удовлетворяющим эту зависимость X.
> 
> Это уже похоже на правильный вариант (в случае, если мантейнер по
> каким-то причинам хочет разрешить смешивать подпакеты разных версий,
> ему достаточно сделать для этих подпакетов виртуальные пакеты с
> зависимостями нужной строгости - например, с чем-то типа %abi_version
> в версии таких виртуальных пакетов).

  Т. е. требуемой мной ручкой будут зависимости на виртуальные пакеты?
Если её расширить и на файловые зависимости -- может быть вполне
приемлемо для меня.

PS: Если ручкой являются только виртуальные пакеты, то мне придётся
плодить некое их число для замены файловых зависимостей.

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 11:05:54PM +0400, Aleksey Avdeev wrote:
> 26.01.2013 20:19, Sergey Vlasov пишет:
> > On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
> ...
> >> Другими словами, предлагается модифицировать алгоритм, чтобы он работал
> >> следующим образом: подпакет A исходного пакета S автоматически получает
> >> строгую зависимость от подпакета B исходного пакета S, если выполнено любое
> >> из следующих условий:
> >> - у A есть зависимость от B;
> >> - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
> >>   является единственным подпакетом S, удовлетворяющим эту зависимость X.
> > 
> > Это уже похоже на правильный вариант (в случае, если мантейнер по
> > каким-то причинам хочет разрешить смешивать подпакеты разных версий,
> > ему достаточно сделать для этих подпакетов виртуальные пакеты с
> > зависимостями нужной строгости - например, с чем-то типа %abi_version
> > в версии таких виртуальных пакетов).
> 
>   Т. е. требуемой мной ручкой будут зависимости на виртуальные пакеты?
> Если её расширить и на файловые зависимости -- может быть вполне
> приемлемо для меня.

файловые зависимости - это разновидность зависимостей на виртуальные пакеты.


-- 
ldv

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

Re: [devel] non-strict deps

[Sergey Vlasov]

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

On Sat, Jan 26, 2013 at 11:05:54PM +0400, Aleksey Avdeev wrote:
> 26.01.2013 20:19, Sergey Vlasov пишет:
> > On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
> ...
> >> Другими словами, предлагается модифицировать алгоритм, чтобы он работал
> >> следующим образом: подпакет A исходного пакета S автоматически получает
> >> строгую зависимость от подпакета B исходного пакета S, если выполнено любое
> >> из следующих условий:
> >> - у A есть зависимость от B;
> >> - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
> >>   является единственным подпакетом S, удовлетворяющим эту зависимость X.
> > 
> > Это уже похоже на правильный вариант (в случае, если мантейнер по
> > каким-то причинам хочет разрешить смешивать подпакеты разных версий,
> > ему достаточно сделать для этих подпакетов виртуальные пакеты с
> > зависимостями нужной строгости - например, с чем-то типа %abi_version
> > в версии таких виртуальных пакетов).
> 
>   Т. е. требуемой мной ручкой будут зависимости на виртуальные пакеты?
> Если её расширить и на файловые зависимости -- может быть вполне
> приемлемо для меня.

На мой взгляд, файловая зависимость в этом смысле ничем не отличается
от Provides с именем - она не указывает на конкретный пакет и
теоретически может предоставляться любым другим пакетом, поэтому такая
зависимость, найденная в spec-файле, не должна заменяться на строгую
зависимость на конкретный подпакет.

А вот аналогичная зависимость, возвращённая find-requires, будет
заменяться, если предоставляется одним подпакетом, и такую замену не
сделал сам find-requires.  Хотя тут возникает вопрос, правильно ли
это, поскольку find-requires в подобных ситуациях обычно возвращает
имя файла только в случае, если этот файл предоставляется более чем
одним пакетом в репозитории, и жёсткая привязка к конкретному
подпакету будет противоречить этой логике.

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

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 08:19:45PM +0400, Sergey Vlasov wrote:
> On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
> > On Sat, Jan 26, 2013 at 05:30:40PM +0400, Sergey Vlasov wrote:
[...]
> Правда, можно представить такую ситуацию, когда мантейнер переименовал
> один из подпакетов, добавив туда соответствующие Provides и Obsoletes,
> но забыл обновить зависимость на этот подпакет - в этом случае такая
> зависимость превратится в явную зависимость на виртуальный пакет и не
> будет усилена автоматически.  Можно попробовать отлавливать подобные
> ошибки по наличию Obsoletes для указанного в зависимостях имени
> пакета.

Можно предположить и другую ситуацию, когда мантейнер переименовал один из
подпакетов с целью создания альтернатив, и не забыл поменять зависимость.
На примере того же xboard это легко моделируется, достаточно добавить в
xboard-theme-default Obsoletes на xboard-theme.

Есть ли какой-нибудь способ различать эти две разные ситуации?

> > Другими словами, предлагается модифицировать алгоритм, чтобы он работал
> > следующим образом: подпакет A исходного пакета S автоматически получает
> > строгую зависимость от подпакета B исходного пакета S, если выполнено любое
> > из следующих условий:
> > - у A есть зависимость от B;
> > - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
> >   является единственным подпакетом S, удовлетворяющим эту зависимость X.
> 
> Это уже похоже на правильный вариант (в случае, если мантейнер по
> каким-то причинам хочет разрешить смешивать подпакеты разных версий,
> ему достаточно сделать для этих подпакетов виртуальные пакеты с
> зависимостями нужной строгости - например, с чем-то типа %abi_version
> в версии таких виртуальных пакетов).

Этот вариант (librpmbuild-4.0.4-alt100.63) ушел в Сизиф.


-- 
ldv

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

Re: [devel] non-strict deps

[Aleksey Avdeev]

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

26.01.2013 23:14, Dmitry V. Levin пишет:
> On Sat, Jan 26, 2013 at 08:19:45PM +0400, Sergey Vlasov wrote:
>> On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
...
>>> Другими словами, предлагается модифицировать алгоритм, чтобы он работал
>>> следующим образом: подпакет A исходного пакета S автоматически получает
>>> строгую зависимость от подпакета B исходного пакета S, если выполнено любое
>>> из следующих условий:
>>> - у A есть зависимость от B;
>>> - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
>>>   является единственным подпакетом S, удовлетворяющим эту зависимость X.
>>
>> Это уже похоже на правильный вариант (в случае, если мантейнер по
>> каким-то причинам хочет разрешить смешивать подпакеты разных версий,
>> ему достаточно сделать для этих подпакетов виртуальные пакеты с
>> зависимостями нужной строгости - например, с чем-то типа %abi_version
>> в версии таких виртуальных пакетов).
> 
> Этот вариант (librpmbuild-4.0.4-alt100.63) ушел в Сизиф.

  Спасибо. Пересборка apache2-2.2.22-alt15 на people показала вполне
приемлемый результат (на первый взгляд). Более детально разбтраться в
понедельник буду.

PS: Заодно начну причёсывать apache2 в плане зависимостей: похоже
заметное число мусора (в виде устаревших конструкций) там скопилось.

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [devel] non-strict deps

[Sergey Vlasov]

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

On Sat, Jan 26, 2013 at 11:14:50PM +0400, Dmitry V. Levin wrote:
> On Sat, Jan 26, 2013 at 08:19:45PM +0400, Sergey Vlasov wrote:
> > On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
> > > On Sat, Jan 26, 2013 at 05:30:40PM +0400, Sergey Vlasov wrote:
> [...]
> > Правда, можно представить такую ситуацию, когда мантейнер переименовал
> > один из подпакетов, добавив туда соответствующие Provides и Obsoletes,
> > но забыл обновить зависимость на этот подпакет - в этом случае такая
> > зависимость превратится в явную зависимость на виртуальный пакет и не
> > будет усилена автоматически.  Можно попробовать отлавливать подобные
> > ошибки по наличию Obsoletes для указанного в зависимостях имени
> > пакета.
> 
> Можно предположить и другую ситуацию, когда мантейнер переименовал один из
> подпакетов с целью создания альтернатив, и не забыл поменять зависимость.
> На примере того же xboard это легко моделируется, достаточно добавить в
> xboard-theme-default Obsoletes на xboard-theme.

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

> Есть ли какой-нибудь способ различать эти две разные ситуации?

Я пока не вижу.

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

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 08:19:45PM +0400, Sergey Vlasov wrote:
> On Sat, Jan 26, 2013 at 06:17:00PM +0400, Dmitry V. Levin wrote:
> > On Sat, Jan 26, 2013 at 05:30:40PM +0400, Sergey Vlasov wrote:
> [...]
> > > На мой взгляд, это неправильно - если в зависимости явно указано имя
> > > виртуального пакета, скорее всего, это сделано намеренно, и такую
> > > зависимость необходимо оставлять в том виде, как она есть.
> > 
> > А если неявно?  Если это find-requires нашел зависимость на soname,
> > ее ведь надо превращать в строгую зависимость на пакет.
> 
> Да, действительно (причём это как раз наиболее опасные нестрогие
> зависимости, поскольку компоненты, собираемые из одного пакета, с
> наибольшей вероятностью могут использовать недокументированные ABI и
> особенности реализации компонентов, вынесенных в соседние подпакеты).
> Но для явно указанных в spec-файле зависимостей, выраженных через
> виртуальные пакеты, не нужно усиливать их автоматически.

В Сизифе есть примеры таких ошибок:

libcal3d-0.11.0-alt1_13:warning: libcal3d-doc: non-strict dependency on libcal3d
В спеке написано "Requires: cal3d = %{version}-%{release}", в то время как
пакет называется libcal3d; Provides есть, Obsoletes нет.

libecap0-0.0.3-alt1:warning: libecap0-devel-static: non-strict dependency on libecap0-devel
В спеке написано "Requires: %lname-devel = %version-%release", в то время
как пакет называется %{lname}0; Provides есть, Obsoletes нет.

libsigsegv0-2.6-alt6:warning: libsigsegv0-devel: non-strict dependency on libsigsegv0
В спеке написано "Requires: %oname = %version-%release", в то время как
пакет называется %name; версионированные Provides и Obsoletes есть.

net-snmp30-5.7.1-alt9:warning: net-snmp-config: non-strict dependency on libnet-snmp30
В спеке написано "Requires: lib%_name = %version-%release", в то время как
пакет называется lib%name; Provides есть, Obsoletes нет.

newt52-0.52.14-alt1:warning: libnewt-devel-static: non-strict dependency on libnewt-devel
В спеке написано "Requires: lib%name-devel = %version-%release", в то
время как пакет называется lib%_name-devel; Provides есть, Obsoletes нет.

rrd-1.4.7-alt3.1:warning: rrd: non-strict dependency on librrd4
В спеке написано "Requires: lib%name = %version-%release", в то время как
пакет называется lib%name%abiversion; Provides есть, Obsoletes нет.

wxGTK-2:2.8.11.0-alt1.svn20100628.5.qa2:warning: wxGTK-examples: non-strict dependency on libwxGTK-devel
В спеке написано "Requires: %name-devel = %version", в то время как пакет
называется lib%name-devel; версионированные Provides и Obsoletes есть.

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

К сожалению, практика показывает, что в большинстве случаев Obsoletes
оказывается забыт.


-- 
ldv

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

Re: [devel] I: repocop NMU

[Igor Vlasenko]

On Fri, Jan 25, 2013 at 02:53:56PM +0400, Dmitry V. Levin wrote:
> Я сейчас тестирую rpm-build, который автоматически добавляет строгие
> внутрипакетные зависимости во всех случаях, в которых это необходимо.
> Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
> да и сам NMU будет технически проще.

Да, получается, с таким rpm-build не нужен специальный
патчгенератор для beehive-log-non-strict-dependency, 
ведь старые пакеты спасать не нужно, а в новых пакетах
автоматом произойдет усиление зависимостей.

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

-- 

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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [devel] I: repocop NMU

[Dmitry V. Levin]

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

On Mon, Jan 28, 2013 at 03:04:36PM +0200, Igor Vlasenko wrote:
> On Fri, Jan 25, 2013 at 02:53:56PM +0400, Dmitry V. Levin wrote:
> > Я сейчас тестирую rpm-build, который автоматически добавляет строгие
> > внутрипакетные зависимости во всех случаях, в которых это необходимо.
> > Так что я надеюсь, что NMU от repocop в аварийном режиме не потребуется,
> > да и сам NMU будет технически проще.
> 
> Да, получается, с таким rpm-build не нужен специальный
> патчгенератор для beehive-log-non-strict-dependency, 
> ведь старые пакеты спасать не нужно, а в новых пакетах
> автоматом произойдет усиление зависимостей.
> 
> Тогда будет обычное NMU, не аварийное,
> через 3 недели, так как набралось уже много патчей.

OK


-- 
ldv

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