[devel] samba

[devel] samba

[Led]

Помещение в Sisyphus пакета samba4 сломало собираемость samba:
http://git.altlinux.org/tasks/87349/logs/events.1.1.log

Это так и задумано?

-- 
Led

Re: [devel] samba

[Alexey Shabalin]

3 января 2013 г., 20:40 пользователь Led  написал:
> Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> http://git.altlinux.org/tasks/87349/logs/events.1.1.log
>
> Это так и задумано?
нет.

--
Alexey Shabalin

Re: [devel] samba

[Led]

On Friday 04 January 2013 00:36:36 Alexey Shabalin wrote:
> 3 января 2013 г., 20:40 пользователь Led  написал:
> > Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> > http://git.altlinux.org/tasks/87349/logs/events.1.1.log
> >
> > Это так и задумано?
>
> нет.

Ну, тогда "нужно что-то решать".

-- 
Led

Re: [devel] samba

[REAL]

03.01.2013 22:40, Led пишет:
> Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> http://git.altlinux.org/tasks/87349/logs/events.1.1.log
>
> Это так и задумано?

это традиция :)

например, полностью аналогична ситуация с llvm3.1 & llvm.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] samba

[Alexey Shabalin]

4 января 2013 г., 2:45 пользователь Led <led@altlinux.ru> написал:
> On Friday 04 January 2013 00:36:36 Alexey Shabalin wrote:
>> 3 января 2013 г., 20:40 пользователь Led  написал:
>> > Помещение в Sisyphus пакета samba4 сломало собираемость samba:
>> > http://git.altlinux.org/tasks/87349/logs/events.1.1.log
>> >
>> > Это так и задумано?
>>
>> нет.
>
> Ну, тогда "нужно что-то решать".

мне кажется, если починить следующие "warning", то всё будет нормально.

warning: samba: non-strict dependency on samba-winbind-clients
warning: samba-client: non-strict dependency on samba-winbind-clients
warning: samba-common: non-strict dependency on samba-winbind-clients
warning: libnetapi-devel: non-strict dependency on libnetapi
warning: libnetapi: non-strict dependency on samba-winbind-clients
warning: samba-domainjoin-gui: non-strict dependency on libnetapi
warning: samba-swat: non-strict dependency on samba-winbind-clients
warning: libsmbclient: non-strict dependency on samba-winbind-clients


--
Alexey Shabalin

Re: [devel] llvm

[Dmitry V. Levin]

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

On Fri, Jan 04, 2013 at 07:58:36AM +0600, REAL wrote:
> 03.01.2013 22:40, Led пишет:
> >Помещение в Sisyphus пакета samba4 сломало 
> >собираемость samba:
> >http://git.altlinux.org/tasks/87349/logs/events.1.1.log
> >
> >Это так и задумано?
> 
> это традиция :)
> 
> например, полностью аналогична ситуация 
> с llvm3.1 & llvm.

Зачем вам столько разных llvm?
Может быть, лучше из двух не вполне рабочих вариантов сделать один рабочий?


-- 
ldv

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

Re: [devel] llvm

[Valery V. Inozemtsev]

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

В Птн, 04/01/2013 в 21:32 +0600, REAL пишет:
> 04.01.2013 17:06, Dmitry V. Levin пишет:
> >> например, полностью аналогична ситуация
> >> с llvm3.1&  llvm.
> >
> > Зачем вам столько разных llvm?
> 
> не ко мне вопрос
> 
> > Может быть, лучше из двух не вполне рабочих вариантов сделать один рабочий?
> 
> а к мейнтейнеру llvm3.1. который и в самом деле "не вполне рабочий" 
> (мягко говоря).

еще раз для тех у кого плохая память...
llvm3.1 собирался исключительно для Mesa-9.0, т.к. там требуется именно
3.1, не 2.X, не 3.0, не 3.2, а именно 3.1
не для чего более llvm3.1 не предназначался!

-- 
Valery V. Inozemtsev

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

Re: [devel] llvm

[REAL]

04.01.2013 17:06, Dmitry V. Levin пишет:
>> например, полностью аналогична ситуация
>> с llvm3.1&  llvm.
>
> Зачем вам столько разных llvm?

не ко мне вопрос

> Может быть, лучше из двух не вполне рабочих вариантов сделать один рабочий?

а к мейнтейнеру llvm3.1. который и в самом деле "не вполне рабочий" 
(мягко говоря).

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] llvm

[REAL]

04.01.2013 21:24, Valery V. Inozemtsev пишет:
> не для чего более llvm3.1 не предназначался!

а где ответ на вопрос, кто будет чинить сломавшуюся из-за появления 
llvm3,1 сборку llvm?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] llvm

[Dmitry V. Levin]

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

On Sat, Jan 05, 2013 at 11:13:34AM +0600, REAL wrote:
> 04.01.2013 21:24, Valery V. Inozemtsev пишет:
> >не для чего более llvm3.1 не предназначался!
> 
> а где ответ на вопрос, кто будет чинить 
> сломавшуюся из-за появления llvm3,1 сборку 
> llvm?

Тот, кто соберет llvm версии 3.1 и выкинет llvm3.1.


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Fri, Jan 04, 2013 at 01:55:20PM +0400, Alexey Shabalin wrote:
> 4 января 2013 г., 2:45 пользователь Led <led@altlinux.ru> написал:
> > On Friday 04 January 2013 00:36:36 Alexey Shabalin wrote:
> >> 3 января 2013 г., 20:40 пользователь Led  написал:
> >> > Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> >> > http://git.altlinux.org/tasks/87349/logs/events.1.1.log
> >> >
> >> > Это так и задумано?
> >>
> >> нет.
> >
> > Ну, тогда "нужно что-то решать".
> 
> мне кажется, если починить следующие "warning", то всё будет нормально.
> 
> warning: samba: non-strict dependency on samba-winbind-clients
> warning: samba-client: non-strict dependency on samba-winbind-clients
> warning: samba-common: non-strict dependency on samba-winbind-clients
> warning: libnetapi-devel: non-strict dependency on libnetapi
> warning: libnetapi: non-strict dependency on samba-winbind-clients
> warning: samba-domainjoin-gui: non-strict dependency on libnetapi
> warning: samba-swat: non-strict dependency on samba-winbind-clients
> warning: libsmbclient: non-strict dependency on samba-winbind-clients

У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
все они на самом деле свидетельствуют об ошибках упаковки.

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


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Igor Vlasenko]

On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
> все они на самом деле свидетельствуют об ошибках упаковки.
> 
> Напрашивается вывод о том, что для более эффективного исправления таких
> ошибок имеет смысл поднять уровень диагностики с warning до error, и
> реализовать ручку управления уровнем этой диагностики для нескольких
> пакетов-исключений.

Опс, это и моя недоработка, я не создал тест repocop 
для этого сообщения.

Может, лучше не спешить, для начала пройтись NMU от repocop?
завтра-послезавтра напишу тест, будут доступны патчи от repocop,
можно будет опросить майнтайнеров и с учетом их замечаний
провести NMU от repocop.

Так было с beehive-log-dependency-needs-epoch,
и получилось довольно хорошо:
Сейчас в Сизифе только 7 пакетов с этим warning,
и только потому, что соответствующий майнтайнер явно
запретил проводить на свои пакеты это NMU.

jack-audio-connection-kit       shrek
libao   shrek
libcelt shrek
libglitz        shrek
libgtk-engines-default  @gnome
libpciaccess    shrek

kernel-image-ovz-smp    sin @kernel @everybody
(особняком, робот в эти пакеты не лазит,так как 
там своя сборочная система).

В sisyphus_check сейчас лучше не гайки закручивать, 
а шестерни смазать, чтобы резьбу не рвало.
Хотел бы напомнить про
https://bugzilla.altlinux.org/show_bug.cgi?id=15376
https://bugzilla.altlinux.org/show_bug.cgi?id=28284
и в особенности,
https://bugzilla.altlinux.org/show_bug.cgi?id=28286
хочу собрать cross-tools для msp430, 
LanchPad 430 очень интересная железяка,
стоит в 3 раза дешевлее arduino и нацелена на малое
энергопотребление, но, sisyphus_check...

-- 

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] non-strict dependency warnings

[Led]

On Wednesday 23 January 2013 22:14:08 Dmitry V. Levin wrote:
> On Fri, Jan 04, 2013 at 01:55:20PM +0400, Alexey Shabalin wrote:
> > 4 января 2013 г., 2:45 пользователь Led <led@altlinux.ru> написал:
> > > On Friday 04 January 2013 00:36:36 Alexey Shabalin wrote:
> > >> 3 января 2013 г., 20:40 пользователь Led  написал:
> > >> > Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> > >> > http://git.altlinux.org/tasks/87349/logs/events.1.1.log
> > >> >
> > >> > Это так и задумано?
> > >>
> > >> нет.
> > >
> > > Ну, тогда "нужно что-то решать".
> >
> > мне кажется, если починить следующие "warning", то всё будет нормально.
> >
> > warning: samba: non-strict dependency on samba-winbind-clients
> > warning: samba-client: non-strict dependency on samba-winbind-clients
> > warning: samba-common: non-strict dependency on samba-winbind-clients
> > warning: libnetapi-devel: non-strict dependency on libnetapi
> > warning: libnetapi: non-strict dependency on samba-winbind-clients
> > warning: samba-domainjoin-gui: non-strict dependency on libnetapi
> > warning: samba-swat: non-strict dependency on samba-winbind-clients
> > warning: libsmbclient: non-strict dependency on samba-winbind-clients
>
> У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
> все они на самом деле свидетельствуют об ошибках упаковки.

Несколько устаревший пример. Сейчас там остался только 4-ый из этих warning'ов.

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

-- 
Led

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 12:29:12AM +0200, Led wrote:
> On Wednesday 23 January 2013 22:14:08 Dmitry V. Levin wrote:
> > On Fri, Jan 04, 2013 at 01:55:20PM +0400, Alexey Shabalin wrote:
> > > 4 января 2013 г., 2:45 пользователь Led <led@altlinux.ru> написал:
> > > > On Friday 04 January 2013 00:36:36 Alexey Shabalin wrote:
> > > >> 3 января 2013 г., 20:40 пользователь Led  написал:
> > > >> > Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> > > >> > http://git.altlinux.org/tasks/87349/logs/events.1.1.log
> > > >> >
> > > >> > Это так и задумано?
> > > >>
> > > >> нет.
> > > >
> > > > Ну, тогда "нужно что-то решать".
> > >
> > > мне кажется, если починить следующие "warning", то всё будет нормально.
> > >
> > > warning: samba: non-strict dependency on samba-winbind-clients
> > > warning: samba-client: non-strict dependency on samba-winbind-clients
> > > warning: samba-common: non-strict dependency on samba-winbind-clients
> > > warning: libnetapi-devel: non-strict dependency on libnetapi
> > > warning: libnetapi: non-strict dependency on samba-winbind-clients
> > > warning: samba-domainjoin-gui: non-strict dependency on libnetapi
> > > warning: samba-swat: non-strict dependency on samba-winbind-clients
> > > warning: libsmbclient: non-strict dependency on samba-winbind-clients
> >
> > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
> > все они на самом деле свидетельствуют об ошибках упаковки.
> 
> Несколько устаревший пример. Сейчас там остался только 4-ый из этих warning'ов.

4-ый это какой?  Может быть, там их вообще не должно было быть?


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Led]

On Thursday 24 January 2013 00:37:07 Dmitry V. Levin wrote:
> On Thu, Jan 24, 2013 at 12:29:12AM +0200, Led wrote:
> > On Wednesday 23 January 2013 22:14:08 Dmitry V. Levin wrote:
> > > On Fri, Jan 04, 2013 at 01:55:20PM +0400, Alexey Shabalin wrote:
> > > > 4 января 2013 г., 2:45 пользователь Led <led@altlinux.ru> написал:
> > > > > On Friday 04 January 2013 00:36:36 Alexey Shabalin wrote:
> > > > >> 3 января 2013 г., 20:40 пользователь Led  написал:
> > > > >> > Помещение в Sisyphus пакета samba4 сломало собираемость samba:
> > > > >> > http://git.altlinux.org/tasks/87349/logs/events.1.1.log
> > > > >> >
> > > > >> > Это так и задумано?
> > > > >>
> > > > >> нет.
> > > > >
> > > > > Ну, тогда "нужно что-то решать".
> > > >
> > > > мне кажется, если починить следующие "warning", то всё будет
> > > > нормально.
> > > >
> > > > warning: samba: non-strict dependency on samba-winbind-clients
> > > > warning: samba-client: non-strict dependency on samba-winbind-clients
> > > > warning: samba-common: non-strict dependency on samba-winbind-clients
> > > > warning: libnetapi-devel: non-strict dependency on libnetapi
> > > > warning: libnetapi: non-strict dependency on samba-winbind-clients
> > > > warning: samba-domainjoin-gui: non-strict dependency on libnetapi
> > > > warning: samba-swat: non-strict dependency on samba-winbind-clients
> > > > warning: libsmbclient: non-strict dependency on samba-winbind-clients
> > >
> > > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и
> > > почти все они на самом деле свидетельствуют об ошибках упаковки.
> >
> > Несколько устаревший пример. Сейчас там остался только 4-ый из этих
> > warning'ов.
>
> 4-ый это какой?

warning: libnetapi-devel: non-strict dependency on libnetapi

> Может быть, там их вообще не должно было быть? 

Не должно было. Но спек - судя по всему, калька из федоры.

-- 
Led

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
> On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
> > все они на самом деле свидетельствуют об ошибках упаковки.
> > 
> > Напрашивается вывод о том, что для более эффективного исправления таких
> > ошибок имеет смысл поднять уровень диагностики с warning до error, и
> > реализовать ручку управления уровнем этой диагностики для нескольких
> > пакетов-исключений.
> 
> Опс, это и моя недоработка, я не создал тест repocop 
> для этого сообщения.

Между прочим, этому типу предупреждений уже почти 2 года.

> Может, лучше не спешить, для начала пройтись NMU от repocop?

Как фиксить, вручную или NMU от repocop - это другой вопрос.

В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
списка разрешенных пар нестрогих зависимостей:
%define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2

> завтра-послезавтра напишу тест, будут доступны патчи от repocop,
> можно будет опросить майнтайнеров и с учетом их замечаний
> провести NMU от repocop.
> 
> Так было с beehive-log-dependency-needs-epoch,
> и получилось довольно хорошо:
> Сейчас в Сизифе только 7 пакетов с этим warning,
> и только потому, что соответствующий майнтайнер явно
> запретил проводить на свои пакеты это NMU.
> 
> jack-audio-connection-kit       shrek
> libao   shrek
> libcelt shrek
> libglitz        shrek
> libgtk-engines-default  @gnome
> libpciaccess    shrek

Я полагал, что их уже исправили полностью.  Раз нет, значит,
и этот warning надо было сразу превратить в error.


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> Igor Vlasenko:
> 
> > Может, лучше не спешить, для начала пройтись NMU от repocop?
> > завтра-послезавтра напишу тест, будут доступны патчи от repocop,
> > можно будет опросить майнтайнеров и с учетом их замечаний
> > провести NMU от repocop.
> >
> > я не откажусь от NMU, заодно поглядим, как repocop справится с specsubst ;)

И не надейтесь, не справится, лучше умелыми ручками.


-- 
ldv

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

Re: [devel] dependency needs Epoch warnings

[Dmitry V. Levin]

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

On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
> On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> Так было с beehive-log-dependency-needs-epoch,
> и получилось довольно хорошо:
> Сейчас в Сизифе только 7 пакетов с этим warning,
> и только потому, что соответствующий майнтайнер явно
> запретил проводить на свои пакеты это NMU.
> 
> jack-audio-connection-kit       shrek
> libao   shrek
> libcelt shrek
> libglitz        shrek
> libgtk-engines-default  @gnome
> libpciaccess    shrek

По моим данным, в Сизифе 44 пакета, которые собираются с этим
предупреждением, например:
$ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
warning: xorg-server: dependency on xorg-server-common needs Epoch
warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
warning: xorg-xephyr: dependency on xorg-server needs Epoch
warning: xorg-xdmx: dependency on xorg-server needs Epoch
warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
warning: xorg-xnest: dependency on xorg-server-common needs Epoch

То, что этот warning пора поднять до error, кажется очевидным.
Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
обратно до уровня warning?


-- 
ldv

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

Re: [devel] dependency needs Epoch warnings

[Yuri N. Sedunov]

В Чт, 24/01/2013 в 10:53 +0400, Dmitry V. Levin пишет:
> On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
> > On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> > Так было с beehive-log-dependency-needs-epoch,
> > и получилось довольно хорошо:
> > Сейчас в Сизифе только 7 пакетов с этим warning,
> > и только потому, что соответствующий майнтайнер явно
> > запретил проводить на свои пакеты это NMU.
> > 
> > jack-audio-connection-kit       shrek
> > libao   shrek
> > libcelt shrek
> > libglitz        shrek
> > libgtk-engines-default  @gnome
> > libpciaccess    shrek
> 
> По моим данным, в Сизифе 44 пакета, которые собираются с этим
> предупреждением, например:
> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> warning: xorg-server: dependency on xorg-server-common needs Epoch
> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> warning: xorg-xephyr: dependency on xorg-server needs Epoch
> warning: xorg-xdmx: dependency on xorg-server needs Epoch
> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> 
> То, что этот warning пора поднять до error, кажется очевидным.
> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> обратно до уровня warning?
> 

Речь о межподпакетных зависимостях, в которых epoch подразумевается.
Если сизифов труд добавления в них эпохи возьмет на себя rpm-build, вряд
ли что-то плохое случится.


-- 
Yuri N. Sedunov

Re: [devel] dependency needs Epoch warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 11:09:38AM +0400, Yuri N. Sedunov wrote:
> В Чт, 24/01/2013 в 10:53 +0400, Dmitry V. Levin пишет:
> > On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
> > > On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> > > Так было с beehive-log-dependency-needs-epoch,
> > > и получилось довольно хорошо:
> > > Сейчас в Сизифе только 7 пакетов с этим warning,
> > > и только потому, что соответствующий майнтайнер явно
> > > запретил проводить на свои пакеты это NMU.
> > > 
> > > jack-audio-connection-kit       shrek
> > > libao   shrek
> > > libcelt shrek
> > > libglitz        shrek
> > > libgtk-engines-default  @gnome
> > > libpciaccess    shrek
> > 
> > По моим данным, в Сизифе 44 пакета, которые собираются с этим
> > предупреждением, например:
> > $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> > warning: xorg-server: dependency on xorg-server-common needs Epoch
> > warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> > warning: xorg-xephyr: dependency on xorg-server needs Epoch
> > warning: xorg-xdmx: dependency on xorg-server needs Epoch
> > warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> > warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> > 
> > То, что этот warning пора поднять до error, кажется очевидным.
> > Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> > обратно до уровня warning?
> 
> Речь о межподпакетных зависимостях, в которых epoch подразумевается.

Подразумевается, но в пакет не попадает.

> Если сизифов труд добавления в них эпохи возьмет на себя rpm-build, вряд
> ли что-то плохое случится.

А если не возьмет?  Неужели в 44 пакетах по мере их сборки сложнее
проставить %epoch, чем допиливать rpm-build?


-- 
ldv

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

Re: [devel] dependency needs Epoch warnings

[Yuri N. Sedunov]

В Чт, 24/01/2013 в 11:16 +0400, Dmitry V. Levin пишет:
> On Thu, Jan 24, 2013 at 11:09:38AM +0400, Yuri N. Sedunov wrote:
> > В Чт, 24/01/2013 в 10:53 +0400, Dmitry V. Levin пишет:
> > > On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
> > > > On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> > > > Так было с beehive-log-dependency-needs-epoch,
> > > > и получилось довольно хорошо:
> > > > Сейчас в Сизифе только 7 пакетов с этим warning,
> > > > и только потому, что соответствующий майнтайнер явно
> > > > запретил проводить на свои пакеты это NMU.
> > > > 
> > > > jack-audio-connection-kit       shrek
> > > > libao   shrek
> > > > libcelt shrek
> > > > libglitz        shrek
> > > > libgtk-engines-default  @gnome
> > > > libpciaccess    shrek
> > > 
> > > По моим данным, в Сизифе 44 пакета, которые собираются с этим
> > > предупреждением, например:
> > > $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> > > warning: xorg-server: dependency on xorg-server-common needs Epoch
> > > warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> > > warning: xorg-xephyr: dependency on xorg-server needs Epoch
> > > warning: xorg-xdmx: dependency on xorg-server needs Epoch
> > > warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> > > warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> > > 
> > > То, что этот warning пора поднять до error, кажется очевидным.
> > > Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> > > обратно до уровня warning?
> > 
> > Речь о межподпакетных зависимостях, в которых epoch подразумевается.
> 
> Подразумевается, но в пакет не попадает.
> 
> > Если сизифов труд добавления в них эпохи возьмет на себя rpm-build, вряд
> > ли что-то плохое случится.
> 
> А если не возьмет?  Неужели в 44 пакетах по мере их сборки сложнее
> проставить %epoch, чем допиливать rpm-build?
 
Межподпакетные зависимости имеют смысл только в рамках текущей эпохи.
Стоит однажды допилить rpm-build, чтобы забыть о необходимости
проставлять epoch ручками.

-- 
Yuri N. Sedunov

Re: [devel] dependency needs Epoch warnings

[Aleksey Avdeev]

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

24.01.2013 10:53, Dmitry V. Levin пишет:
> On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
>> On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
>> Так было с beehive-log-dependency-needs-epoch,
>> и получилось довольно хорошо:
>> Сейчас в Сизифе только 7 пакетов с этим warning,
>> и только потому, что соответствующий майнтайнер явно
>> запретил проводить на свои пакеты это NMU.
>>
>> jack-audio-connection-kit       shrek
>> libao   shrek
>> libcelt shrek
>> libglitz        shrek
>> libgtk-engines-default  @gnome
>> libpciaccess    shrek

  Ещё apache2.

> 
> По моим данным, в Сизифе 44 пакета, которые собираются с этим
> предупреждением, например:
> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> warning: xorg-server: dependency on xorg-server-common needs Epoch
> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> warning: xorg-xephyr: dependency on xorg-server needs Epoch
> warning: xorg-xdmx: dependency on xorg-server needs Epoch
> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> 
> То, что этот warning пора поднять до error, кажется очевидным.
> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> обратно до уровня warning?

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

PS: Сейчас я на эту мину (смена warning`а на error) нарвался при
очередной сборке apache2 на people: Вчера оно собиралось, а сегодня --
уже нет.

-- 

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



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

Re: [devel] non-strict dependency warnings

[Aleksey Avdeev]

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

24.01.2013 10:44, Dmitry V. Levin пишет:
...
> В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
> списка разрешенных пар нестрогих зависимостей:
> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2

  Прошу уточнения:

1. Имеется в виду, что пакет из данного списка может иметь нестрогие
зависимости на любой другой пакет из него же?

2. В каком виде должны присутствовать имена пакетов в списке:
%name-<subname> или достаточно <subname>?

-- 

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



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

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 11:07:29AM +0300, Eugene Prokopiev wrote:
> Dmitry V. Levin:
> > On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> > > Igor Vlasenko:
> > >
> > > > Может, лучше не спешить, для начала пройтись NMU от repocop?
> > > > завтра-послезавтра напишу тест, будут доступны патчи от repocop,
> > > > можно будет опросить майнтайнеров и с учетом их замечаний
> > > > провести NMU от repocop.
> > > >
> > > > я не откажусь от NMU, заодно поглядим, как repocop справится с
> > specsubst ;)
> >
> > И не надейтесь, не справится, лучше умелыми ручками.
> 
> Тогда можно краткое объяснение или урл - что это за проблема и как ее
> лечить. Неужели просто прописать недостающие зависимости вручную (иначе
> текст предупреждения у меня интерпретировать не получается)?

Да, более-менее в ручную, с использованием макросов %version и %release. :)


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 02:47:26PM +0400, Aleksey Avdeev wrote:
> 24.01.2013 10:44, Dmitry V. Levin пишет:
> ...
> > В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
> > и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
> > списка разрешенных пар нестрогих зависимостей:
> > %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2
> 
>   Прошу уточнения:
> 
> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие
> зависимости на любой другой пакет из него же?
> 
> 2. В каком виде должны присутствовать имена пакетов в списке:
> %name-<subname> или достаточно <subname>?

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


-- 
ldv

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

Re: [devel] dependency needs Epoch warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
> 24.01.2013 10:53, Dmitry V. Levin пишет:
> > По моим данным, в Сизифе 44 пакета, которые собираются с этим
> > предупреждением, например:
> > $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> > warning: xorg-server: dependency on xorg-server-common needs Epoch
> > warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> > warning: xorg-xephyr: dependency on xorg-server needs Epoch
> > warning: xorg-xdmx: dependency on xorg-server needs Epoch
> > warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> > warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> > 
> > То, что этот warning пора поднять до error, кажется очевидным.
> > Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> > обратно до уровня warning?
> 
>   Нужно как миниум для apache2.

Словам не верю, докажите.

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

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

> PS: Сейчас я на эту мину (смена warning`а на error) нарвался при
> очередной сборке apache2 на people: Вчера оно собиралось, а сегодня --
> уже нет.

Речь идет про
warning: apache2-base: non-strict dependency on apache2-common
warning: apache2-base: non-strict dependency on apache2-httpd-event
warning: apache2-base: non-strict dependency on apache2-httpd-itk
warning: apache2-base: non-strict dependency on apache2-httpd-peruser
warning: apache2-base: non-strict dependency on apache2-httpd-prefork
warning: apache2-base: non-strict dependency on apache2-httpd-worker
warning: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs
warning: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs
warning: apache2-compat: non-strict dependency on apache2-base
warning: apache2-compat: non-strict dependency on apache2-common
warning: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
warning: apache2-configs-A1PROXIED: non-strict dependency on apache2-common
warning: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache
warning: apache2-httpd-event: non-strict dependency on apache2-common
warning: apache2-httpd-itk: non-strict dependency on apache2-common
warning: apache2-httpd-peruser: non-strict dependency on apache2-common
warning: apache2-httpd-prefork: non-strict dependency on apache2-common
warning: apache2-httpd-worker: non-strict dependency on apache2-common
warning: apache2-manual: non-strict dependency on apache2-base
warning: apache2-manual: non-strict dependency on apache2-common
warning: apache2-mod_disk_cache: non-strict dependency on apache2-common
warning: apache2-mod_ldap: non-strict dependency on apache2-common
warning: apache2-mod_ssl-compat: non-strict dependency on apache2-common
warning: apache2-mod_ssl: non-strict dependency on apache2-common
warning: apache2-suexec: non-strict dependency on apache2-common
warning: apache2: non-strict dependency on apache2-cgi-bin
warning: apache2: non-strict dependency on apache2-html
warning: apache2: non-strict dependency on apache2-icons

Это очень хорошо, что теперь вместо warning пишут error - лишний повод
задуматься о странностях упаковки apache2.


-- 
ldv

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

[devel] Рано поднимать до error (was: non-strict dependency warnings)

[Sergey V Turchin]

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

On Thursday 24 January 2013 00:14:08 Dmitry V wrote:

[...]
> У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
> все они на самом деле свидетельствуют об ошибках упаковки.
> 
> Напрашивается вывод о том, что для более эффективного исправления таких
> ошибок имеет смысл поднять уровень диагностики с warning до error, и
> реализовать ручку управления уровнем этой диагностики для нескольких
> пакетов-исключений.
Диагностика не учитывает жесткие зависимости через другие _подпакеты_, как у 
меня во многих сделано.

-- 
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 dependency warnings

[Igor Vlasenko]

On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> Igor Vlasenko:
> > завтра-послезавтра напишу тест, будут доступны патчи от repocop,
> > можно будет опросить майнтайнеров и с учетом их замечаний
> > провести NMU от repocop.
> >
> > я не откажусь от NMU, заодно поглядим, как repocop справится с specsubst ;)

пожалуйста, пример пакета с specsubst, не kernel-*,
дайте, чтобы локально у себя потренироваться.

-- 

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] dependency needs Epoch warnings

[Igor Vlasenko]

On Thu, Jan 24, 2013 at 10:53:55AM +0400, Dmitry V. Levin wrote:
> On Wed, Jan 23, 2013 at 11:05:31PM +0200, Igor Vlasenko wrote:
> > On Thu, Jan 24, 2013 at 12:14:08AM +0400, Dmitry V. Levin wrote:
> > Так было с beehive-log-dependency-needs-epoch,
> > и получилось довольно хорошо:
> > Сейчас в Сизифе только 7 пакетов с этим warning,
> По моим данным, в Сизифе 44 пакета, которые собираются с этим
> предупреждением, например:
> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 

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

-- 

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] dependency needs Epoch warnings

[Aleksey Avdeev]

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

24.01.2013 15:31, Dmitry V. Levin пишет:
> On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 10:53, Dmitry V. Levin пишет:
>>> По моим данным, в Сизифе 44 пакета, которые собираются с этим
>>> предупреждением, например:
>>> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
>>> warning: xorg-server: dependency on xorg-server-common needs Epoch
>>> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
>>> warning: xorg-xephyr: dependency on xorg-server needs Epoch
>>> warning: xorg-xdmx: dependency on xorg-server needs Epoch
>>> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
>>> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
>>>
>>> То, что этот warning пора поднять до error, кажется очевидным.
>>> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
>>> обратно до уровня warning?
>>
>>   Нужно как миниум для apache2.
> 
> Словам не верю, докажите.

  OK, развёрнтый ответ пишу.

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

  Для apache это скорее правило чем исключение:

1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic
Number, см. <http://httpd.apache.org/docs/2.2/glossary.html>), за
которым следит арстрим. У нас это реализовано через предоставление
зависимости Provides: %name-mmn = %mmn (где %mmn константа,
соответствующая собираемому apache2) пакетом apache2-commom (все модули
должны требовать зависимость с нужным им MMN).

2. Изменения сонеймов библиотек, с которыми собирается apache2, тоже
кодируются в виде зависемостей предоставляемых пакетом apache2-commom.
Список, правда, контролируется руками, и сейчас там только openssl:

Provides: %name-%apache2_libssl_name = %apache2_libssl_soname

где (см. пакет rpm-macros-apache2):

%apache2_libssl_name libssl

%apache2_libssl_soname %(rpm -qR %apache2_libssl_name-devel | sed -rn
'/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')

Если список надо расширить -- предложения принимаются. (Ранее, подобным
механизмом контролировался и сонейм lindb4, но теперь apache2 напрямую с
lindb4 не линкуется.)

3. Многие библиотеки apache2 использует через libapr/libaprutil, которые
и скрывают изменения их ABI.

4. Наши set-version для библиотек снимают заметную часть проблем.

  Это касательно ABI. Требования по каталогам/файлам и содержимым
конфигов я контролирую руками.

> 
>> PS: Сейчас я на эту мину (смена warning`а на error) нарвался при
>> очередной сборке apache2 на people: Вчера оно собиралось, а сегодня --
>> уже нет.
> 
> Речь идет про
> warning: apache2-base: non-strict dependency on apache2-common
> warning: apache2-base: non-strict dependency on apache2-httpd-event
> warning: apache2-base: non-strict dependency on apache2-httpd-itk
> warning: apache2-base: non-strict dependency on apache2-httpd-peruser
> warning: apache2-base: non-strict dependency on apache2-httpd-prefork
> warning: apache2-base: non-strict dependency on apache2-httpd-worker
> warning: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs
> warning: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs
> warning: apache2-compat: non-strict dependency on apache2-base
> warning: apache2-compat: non-strict dependency on apache2-common
> warning: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
> warning: apache2-configs-A1PROXIED: non-strict dependency on apache2-common
> warning: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache
> warning: apache2-httpd-event: non-strict dependency on apache2-common
> warning: apache2-httpd-itk: non-strict dependency on apache2-common
> warning: apache2-httpd-peruser: non-strict dependency on apache2-common
> warning: apache2-httpd-prefork: non-strict dependency on apache2-common
> warning: apache2-httpd-worker: non-strict dependency on apache2-common
> warning: apache2-manual: non-strict dependency on apache2-base
> warning: apache2-manual: non-strict dependency on apache2-common
> warning: apache2-mod_disk_cache: non-strict dependency on apache2-common
> warning: apache2-mod_ldap: non-strict dependency on apache2-common
> warning: apache2-mod_ssl-compat: non-strict dependency on apache2-common
> warning: apache2-mod_ssl: non-strict dependency on apache2-common
> warning: apache2-suexec: non-strict dependency on apache2-common
> warning: apache2: non-strict dependency on apache2-cgi-bin
> warning: apache2: non-strict dependency on apache2-html
> warning: apache2: non-strict dependency on apache2-icons
> 
> Это очень хорошо, что теперь вместо warning пишут error - лишний повод
> задуматься о странностях упаковки apache2.

  Письмо с развёрнутым, по пакетным, описанием готовлю.

PS: Для меня проще всего забить на проблему, поставив строгие
зависимости. Но это ударит по пользователям. Особенно по тем, у кого
слабый канал (такой как аналоговый модем или GPRS) или вообще отсутствие
оного (выкачка пакетов сторонними средствами и последующая установка с
носителя).

-- 

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



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

Re: [devel] Рано поднимать до error

[Aleksey Avdeev]

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

24.01.2013 15:57, Sergey V Turchin пишет:
> On Thursday 24 January 2013 00:14:08 Dmitry V wrote:
> 
> [...]
>> У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
>> все они на самом деле свидетельствуют об ошибках упаковки.
>>
>> Напрашивается вывод о том, что для более эффективного исправления таких
>> ошибок имеет смысл поднять уровень диагностики с warning до error, и
>> реализовать ручку управления уровнем этой диагностики для нескольких
>> пакетов-исключений.
> Диагностика не учитывает жесткие зависимости через другие _подпакеты_, как у 
> меня во многих сделано.

  +1: У apache2 за многими нестрогими зависимостями тоже скрывается
подобный механизм.

-- 

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



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

Re: [devel] non-strict dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 03:57:31PM +0400, Sergey V Turchin wrote:
> On Thursday 24 January 2013 00:14:08 Dmitry V wrote:
> 
> [...]
> > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и почти
> > все они на самом деле свидетельствуют об ошибках упаковки.
> > 
> > Напрашивается вывод о том, что для более эффективного исправления таких
> > ошибок имеет смысл поднять уровень диагностики с warning до error, и
> > реализовать ручку управления уровнем этой диагностики для нескольких
> > пакетов-исключений.
> Диагностика не учитывает жесткие зависимости через другие _подпакеты_, как у 
> меня во многих сделано.

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


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Sergey V Turchin]

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

On Thursday 24 January 2013 16:31:10 Dmitry V wrote:
> On Thu, Jan 24, 2013 at 03:57:31PM +0400, Sergey V Turchin wrote:
> > On Thursday 24 January 2013 00:14:08 Dmitry V wrote:
> > 
> > [...]
> > 
> > > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и
> > > почти
> > > все они на самом деле свидетельствуют об ошибках упаковки.
> > > 
> > > Напрашивается вывод о том, что для более эффективного исправления таких
> > > ошибок имеет смысл поднять уровень диагностики с warning до error, и
> > > реализовать ручку управления уровнем этой диагностики для нескольких
> > > пакетов-исключений.
> > 
> > Диагностика не учитывает жесткие зависимости через другие _подпакеты_, как
> > у меня во многих сделано.
> 
> Учитывает, поскольку выполняет замыкание зависимостей.
Не учитывает, поскольку выполняет что-то неправильно.
Например, http://bugs.altlinux.org/28439

> Вопросы возникают в случае легальных альтернативных провайдеров, их я
> и предлагаю обсуждать отдельно.  А все остальное - это просто ошибки.
-- 
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 dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 04:55:52PM +0400, Sergey V Turchin wrote:
> On Thursday 24 January 2013 16:31:10 Dmitry V wrote:
> > On Thu, Jan 24, 2013 at 03:57:31PM +0400, Sergey V Turchin wrote:
> > > On Thursday 24 January 2013 00:14:08 Dmitry V wrote:
> > > 
> > > [...]
> > > 
> > > > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и
> > > > почти
> > > > все они на самом деле свидетельствуют об ошибках упаковки.
> > > > 
> > > > Напрашивается вывод о том, что для более эффективного исправления таких
> > > > ошибок имеет смысл поднять уровень диагностики с warning до error, и
> > > > реализовать ручку управления уровнем этой диагностики для нескольких
> > > > пакетов-исключений.
> > > 
> > > Диагностика не учитывает жесткие зависимости через другие _подпакеты_, как
> > > у меня во многих сделано.
> > 
> > Учитывает, поскольку выполняет замыкание зависимостей.
> Не учитывает, поскольку выполняет что-то неправильно.
> Например, http://bugs.altlinux.org/28439

Докажи. :)


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Sergey V Turchin]

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

On Thursday 24 January 2013 18:49:23 Dmitry V wrote:
> On Thu, Jan 24, 2013 at 04:55:52PM +0400, Sergey V Turchin wrote:
> > On Thursday 24 January 2013 16:31:10 Dmitry V wrote:
> > > On Thu, Jan 24, 2013 at 03:57:31PM +0400, Sergey V Turchin wrote:
> > > > On Thursday 24 January 2013 00:14:08 Dmitry V wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > У нас в Сизифе сейчас около 660 пакетов с такими предупреждениями, и
> > > > > почти
> > > > > все они на самом деле свидетельствуют об ошибках упаковки.
> > > > > 
> > > > > Напрашивается вывод о том, что для более эффективного исправления
> > > > > таких
> > > > > ошибок имеет смысл поднять уровень диагностики с warning до error, и
> > > > > реализовать ручку управления уровнем этой диагностики для нескольких
> > > > > пакетов-исключений.
> > > > 
> > > > Диагностика не учитывает жесткие зависимости через другие _подпакеты_,
> > > > как
> > > > у меня во многих сделано.
> > > 
> > > Учитывает, поскольку выполняет замыкание зависимостей.
> > 
> > Не учитывает, поскольку выполняет что-то неправильно.
> > Например, http://bugs.altlinux.org/28439
> Докажи. :)
Теперь ты ;-)

-- 
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 dependency warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 05:54:09PM +0200, Led wrote:
> 2013/1/24 Dmitry V. Levin <ldv@altlinux.org>
> > On Thu, Jan 24, 2013 at 11:07:29AM +0300, Eugene Prokopiev wrote:
> > > Dmitry V. Levin:
> > > > On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> > > > > Igor Vlasenko:
> > > > >
> > > > > > Может, лучше не спешить, для начала пройтись NMU от repocop?
> > > > > > завтра-послезавтра напишу тест, будут доступны патчи от repocop,
> > > > > > можно будет опросить майнтайнеров и с учетом их замечаний
> > > > > > провести NMU от repocop.
> > > > > >
> > > > > > я не откажусь от NMU, заодно поглядим, как repocop справится с
> > > > specsubst ;)
> > > >
> > > > И не надейтесь, не справится, лучше умелыми ручками.
> > >
> > > Тогда можно краткое объяснение или урл - что это за проблема и как ее
> > > лечить. Неужели просто прописать недостающие зависимости вручную (иначе
> > > текст предупреждения у меня интерпретировать не получается)?
> >
> > Да, более-менее вручную, с использованием макросов %version и %release. :)
> 
> Может тогда лучше добавить в /usr/lib/rpm/macros
> 
> %EVR %{expand:%%{?epoch:%%epoch:}%%version-%%release}
> 
> ?
> 
> Тогда можно везде вместо %version-%release писать %EVR и не задумываться:
> есть Epoch или нет.

Кажется, repocop, когда делал NMU, использовал что-то похожее.
Только зачем здесь нужен expand?


-- 
ldv

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

Re: [devel] non-strict dependency warnings

[Led]

On Thursday 24 January 2013 18:00:54 Dmitry V. Levin wrote:
> On Thu, Jan 24, 2013 at 05:54:09PM +0200, Led wrote:
> > 2013/1/24 Dmitry V. Levin <ldv@altlinux.org>
> >
> > > On Thu, Jan 24, 2013 at 11:07:29AM +0300, Eugene Prokopiev wrote:
> > > > Dmitry V. Levin:
> > > > > On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> > > > > > Igor Vlasenko:
> > > > > > > Может, лучше не спешить, для начала пройтись NMU от repocop?
> > > > > > > завтра-послезавтра напишу тест, будут доступны патчи от
> > > > > > > repocop, можно будет опросить майнтайнеров и с учетом их
> > > > > > > замечаний провести NMU от repocop.
> > > > > > >
> > > > > > > я не откажусь от NMU, заодно поглядим, как repocop справится с
> > > > >
> > > > > specsubst ;)
> > > > >
> > > > > И не надейтесь, не справится, лучше умелыми ручками.
> > > >
> > > > Тогда можно краткое объяснение или урл - что это за проблема и как ее
> > > > лечить. Неужели просто прописать недостающие зависимости вручную
> > > > (иначе текст предупреждения у меня интерпретировать не получается)?
> > >
> > > Да, более-менее вручную, с использованием макросов %version и %release.
> > > :)
> >
> > Может тогда лучше добавить в /usr/lib/rpm/macros
> >
> > %EVR %{expand:%%{?epoch:%%epoch:}%%version-%%release}
> >
> > ?
> >
> > Тогда можно везде вместо %version-%release писать %EVR и не задумываться:
> > есть Epoch или нет.
>
> Кажется, repocop, когда делал NMU, использовал что-то похожее.
> Только зачем здесь нужен expand?

Не знаю. Похоже, что не нужен:)

-- 
Led

Re: [devel] dependency needs Epoch warnings

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 04:21:11PM +0400, Aleksey Avdeev wrote:
> 24.01.2013 15:31, Dmitry V. Levin пишет:
> > On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
> >> 24.01.2013 10:53, Dmitry V. Levin пишет:
> >>> По моим данным, в Сизифе 44 пакета, которые собираются с этим
> >>> предупреждением, например:
> >>> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> >>> warning: xorg-server: dependency on xorg-server-common needs Epoch
> >>> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> >>> warning: xorg-xephyr: dependency on xorg-server needs Epoch
> >>> warning: xorg-xdmx: dependency on xorg-server needs Epoch
> >>> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> >>> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> >>>
> >>> То, что этот warning пора поднять до error, кажется очевидным.
> >>> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> >>> обратно до уровня warning?
> >>
> >>   Нужно как миниум для apache2.
> > 
> > Словам не верю, докажите.
> 
>   OK, развёрнтый ответ пишу.
> 
> > 
> >> В противном случаи будет сломана
> >> возможность делать точечные обновления компонентов apache2 и возможность
> >> установки новых модулей (или их версий) на старый apache2 (если нет
> >> противопоказаний по библиотекам, разумеется).
> > 
> > Такая возможность не просто не нужна, она вредна и с ней надо бороться.
> > При сборке apache2 тестируется в лучшем случае модули и сервер, собранные
> > из одного исходного пакета, и не надо делать вид, что модули и сервер,
> > собранные из разных исходного пакета, могут случайно заработать.
> 
>   Для apache это скорее правило чем исключение:
> 
> 1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic
> Number, см. <http://httpd.apache.org/docs/2.2/glossary.html>), за
> которым следит арстрим. У нас это реализовано через предоставление
> зависимости Provides: %name-mmn = %mmn (где %mmn константа,
> соответствующая собираемому apache2) пакетом apache2-commom (все модули
> должны требовать зависимость с нужным им MMN).
> 
> 2. Изменения сонеймов библиотек, с которыми собирается apache2, тоже
> кодируются в виде зависемостей предоставляемых пакетом apache2-commom.
> Список, правда, контролируется руками, и сейчас там только openssl:
> 
> Provides: %name-%apache2_libssl_name = %apache2_libssl_soname
> 
> где (см. пакет rpm-macros-apache2):
> 
> %apache2_libssl_name libssl
> 
> %apache2_libssl_soname %(rpm -qR %apache2_libssl_name-devel | sed -rn
> '/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')
> 
> Если список надо расширить -- предложения принимаются. (Ранее, подобным
> механизмом контролировался и сонейм lindb4, но теперь apache2 напрямую с
> lindb4 не линкуется.)
> 
> 3. Многие библиотеки apache2 использует через libapr/libaprutil, которые
> и скрывают изменения их ABI.
> 
> 4. Наши set-version для библиотек снимают заметную часть проблем.
> 
>   Это касательно ABI. Требования по каталогам/файлам и содержимым
> конфигов я контролирую руками.

Это все сложно и не дает гарантии, в отличие от простой конструкции вида
Requires: %name = %{?epoch:%epoch:}%version-%release
которая такую гарантию дает.

> PS: Для меня проще всего забить на проблему, поставив строгие
> зависимости. Но это ударит по пользователям. Особенно по тем, у кого
> слабый канал (такой как аналоговый модем или GPRS) или вообще отсутствие
> оного (выкачка пакетов сторонними средствами и последующая установка с
> носителя).

Мы говорим о потенциальных пользователях, которые не смогут обновить
apache2-base, или такие пользователи действительно существуют?


-- 
ldv

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

Re: [devel] non-strict dependency in apache2 (was: non-strict dependency warnings)

[Aleksey Avdeev]

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

24.01.2013 15:25, Dmitry V. Levin пишет:
> On Thu, Jan 24, 2013 at 02:47:26PM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 10:44, Dmitry V. Levin пишет:
>> ...
>>> В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
>>> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
>>> списка разрешенных пар нестрогих зависимостей:
>>> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2
>>
>>   Прошу уточнения:
>>
>> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие
>> зависимости на любой другой пакет из него же?
>>
>> 2. В каком виде должны присутствовать имена пакетов в списке:
>> %name-<subname> или достаточно <subname>?
> 
> Имеется в виду, что каждый случай применения этого макроса стоит проводить
> через обсуждение в этом списке, хотя бы только для того, чтобы убедиться,
> что нестрогие зависимости в данном конкретном пакете действительно имеют
> смысл, а не являются следствием приземления благих намерений.

  Тогда давайте обсуждать apache2, то что сейчас собираю (см.
<http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=blob;f=apache2.spec;h=c9e9fad9fb4dc01789edc90d6757de8c77b734dd;hb=ALT/apache2/spec>):

error: apache2: non-strict dependency on apache2-cgi-bin
error: apache2: non-strict dependency on apache2-html
error: apache2: non-strict dependency on apache2-icons

  Вызвано зависимостями:

Requires: webserver-cgi-bin
Requires: webserver-html
Requires: webserver-icons

  Данные зависимости предоставляют не только пакеты
apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
apache2 _действительно_ всё равно, какие именно пакеты данные
зависимости реализуют.

error: apache2-base: non-strict dependency on apache2-common

  apache2-base это в основном сборище конфигов, каталогов и пр. не
исполняемых файлов. Бинарные вспомогательные утилиты там тоже есть, но
от бинарного содержимого apache2-common (и его ABI) они не зависят.
Несовместимости учтены зависимостями вида
Requires: %name-common > 2.2.22-alt11 в самом пакете и конфликтами вида
Conflicts: apache2-base <= 2.2.22-alt11 в apache2-common.

error: apache2-base: non-strict dependency on apache2-httpd-worker
error: apache2-base: non-strict dependency on apache2-httpd-prefork
error: apache2-base: non-strict dependency on apache2-httpd-event
error: apache2-base: non-strict dependency on apache2-httpd-itk
error: apache2-base: non-strict dependency on apache2-httpd-peruser

  Вызвано требованием:

Requires: %apache2_sbindir/%apache2_dname

т. к. файл %apache2_sbindir/%apache2_dname альтернатива, предоставляемая
всеми перечисленными подпакетами
(apache2-httpd-{worker,prefork,event,itk,peruser}).

error: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
error: apache2-configs-A1PROXIED: non-strict dependency on apache2-common

  Комплект конфигов. Совместимость учтена через зависимости.

error: apache2-httpd-worker: non-strict dependency on apache2-common
error: apache2-httpd-prefork: non-strict dependency on apache2-common
error: apache2-httpd-event: non-strict dependency on apache2-common
error: apache2-httpd-itk: non-strict dependency on apache2-common
error: apache2-httpd-peruser: non-strict dependency on apache2-common

  Фактически, здесь недолинкованные библиотеки (модули
в apache2-common) зависят от бинарников, подставляемых пакетми
apache2-httpd-{worker,prefork,event,itk,peruser} через альтернативу
%apache2_sbindir/%apache2_dname (/usr/sbin/httpd2), но направление
зависимостей выставлено обратным. Т. е. для rpm не модули
(apache2-common) зависят от исполняемых бинарников (/usr/sbin/httpd2),
что имеет место быть по факту, а бинарники (пакеты apache2-httpd-*) от
модулей (apache2-common). (Пакет apache2-common выбран центральной
сущностью.)

  От проблем защищают:

1. Привязка к конкретному MMU (Module Magic Number, см.
<http://httpd.apache.org/docs/2.2/glossary.html>) (apache2-common
предоставляет %name-mmn = %mmn, а apache2-httpd-* его _строго_ требуют).

2. Есть защита от использования не той libaprutil1, через:

а) Requires: libaprutil1 >= %n_aprutil_devel_ver в apache2-common
(%n_aprutil_devel_ver соответствует версии-релизу пакета
libaprutil1-devel использованного при сборке).

б) Автозависимость вида libaprutil-1.so.0()(64bit) >= set:... (наши
set-version, или как их назвать правильно) в пакетах
apache2-httpd-{worker,prefork,event,itk,peruser}.

Т. е. сейчас я считаю что пакет libaprutil1 такой-же или более новый чем
libaprutil1-devel использованный при сборке, скорее всего подойдёт для
модулей (в apache2-common). (С пакетами apache2-httpd-* проще -- там
set-version работает.)

  Понятно что это тонкое место, и что для модулей нужно делать
автогенирацию нечто подобного /usr/sbin/httpd2 >= set:... (по аналогии
set-version сделанного для библиотек), но я не знаю как подступиться к
данной задачи.

  Что здесь стоит сделать (могу, достаточно быстро):

1. Удалить устаревшие, не актуальные, условия (например, сейчас по
факту, от libssl зависит только apache2-mod_ssl).

2. Сделать защиту от использования не той libapr1 (по аналогии
сделанного для libaprutil1).

3. Сделать привязку к версии libpcre (требуется apache2-httpd-*, для
apache2-common похоже не нужно, но может потребоваться другим модулям).

error: apache2-manual: non-strict dependency on apache2-base
error: apache2-manual: non-strict dependency on apache2-common

  Это контент. Заведомо будет работать с любыми совместимыми версиями
(задано нестрогими зависимостями и конфликтами).

error: apache2-mod_ldap: non-strict dependency on apache2-common

  Фактические требования модуля совпадают с требованием модулей
находящихся в apache2-common. Но т. к. apache2-common выбран центральной
сущностью -- все завязано на него. Модуль не зависит от
%apache2_sbindir/%apache2_dname, но требуют:

PreReq: %name-common
Requires: %name-mmn = %mmn
Requires: libaprutil1-ldap >= %n_aprutil_devel_ver

error: apache2-mod_disk_cache: non-strict dependency on apache2-common
error: apache2-mod_ssl: non-strict dependency on apache2-common
error: apache2-suexec: non-strict dependency on apache2-common

  Практически аналогично apache2-mod_ldap. (Но похоже нужно использовать
Requires: libaprutil1 >= %n_aprutil_devel_ver -- сейчас зависимости на
libaprutil1 сдесь нет.)

error: apache2-compat: non-strict dependency on apache2-base
error: apache2-compat: non-strict dependency on apache2-common
error: apache2-mod_ssl-compat: non-strict dependency on apache2-common

  Конфиги. С бинарниками напрямую не связанны. Oт apache2-{base,common}
нужна инфроструктура и работающие с ней утилиты.

error: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs
error: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs

  CGI скрипты. С бинарниками напрямую не связанны.

error: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache

  Обусловлено требованием каталога, содержащегося
в apache2-mod_disk_cache:

Requires: %apache2_htcacheclean_cachepath

-- 

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



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

Re: [devel] non-strict dependency in apache2 (was: non-strict dependency warnings)

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 09:58:12PM +0400, Aleksey Avdeev wrote:
> 24.01.2013 15:25, Dmitry V. Levin пишет:
> > On Thu, Jan 24, 2013 at 02:47:26PM +0400, Aleksey Avdeev wrote:
> >> 24.01.2013 10:44, Dmitry V. Levin пишет:
> >> ...
> >>> В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
> >>> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
> >>> списка разрешенных пар нестрогих зависимостей:
> >>> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2
> >>
> >>   Прошу уточнения:
> >>
> >> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие
> >> зависимости на любой другой пакет из него же?
> >>
> >> 2. В каком виде должны присутствовать имена пакетов в списке:
> >> %name-<subname> или достаточно <subname>?
> > 
> > Имеется в виду, что каждый случай применения этого макроса стоит проводить
> > через обсуждение в этом списке, хотя бы только для того, чтобы убедиться,
> > что нестрогие зависимости в данном конкретном пакете действительно имеют
> > смысл, а не являются следствием приземления благих намерений.
> 
>   Тогда давайте обсуждать apache2, то что сейчас собираю (см.
> <http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=blob;f=apache2.spec;h=c9e9fad9fb4dc01789edc90d6757de8c77b734dd;hb=ALT/apache2/spec>):
> 
> error: apache2: non-strict dependency on apache2-cgi-bin
> error: apache2: non-strict dependency on apache2-html
> error: apache2: non-strict dependency on apache2-icons
> 
>   Вызвано зависимостями:
> 
> Requires: webserver-cgi-bin
> Requires: webserver-html
> Requires: webserver-icons
> 
>   Данные зависимости предоставляют не только пакеты
> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
> apache2 _действительно_ всё равно, какие именно пакеты данные
> зависимости реализуют.

Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
От этого действительно может быть какая-то польза?  Или все это
разнообразие упаковывается просто потому, что это возможно?

> error: apache2-base: non-strict dependency on apache2-common
> 
>   apache2-base это в основном сборище конфигов, каталогов и пр. не
> исполняемых файлов. Бинарные вспомогательные утилиты там тоже есть, но
> от бинарного содержимого apache2-common (и его ABI) они не зависят.
> Несовместимости учтены зависимостями вида
> Requires: %name-common > 2.2.22-alt11 в самом пакете и конфликтами вида
> Conflicts: apache2-base <= 2.2.22-alt11 в apache2-common.

Есть ли смысл использовать apache2-base и apache2-common от разных сборок
одновременно?  Мне кажется, что здесь чем проще, тем лучше.

> error: apache2-base: non-strict dependency on apache2-httpd-worker
> error: apache2-base: non-strict dependency on apache2-httpd-prefork
> error: apache2-base: non-strict dependency on apache2-httpd-event
> error: apache2-base: non-strict dependency on apache2-httpd-itk
> error: apache2-base: non-strict dependency on apache2-httpd-peruser
> 
>   Вызвано требованием:
> 
> Requires: %apache2_sbindir/%apache2_dname
> 
> т. к. файл %apache2_sbindir/%apache2_dname альтернатива, предоставляемая
> всеми перечисленными подпакетами
> (apache2-httpd-{worker,prefork,event,itk,peruser}).

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

> error: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
> error: apache2-configs-A1PROXIED: non-strict dependency on apache2-common
> 
>   Комплект конфигов. Совместимость учтена через зависимости.

Не понимаю.

> error: apache2-httpd-worker: non-strict dependency on apache2-common
> error: apache2-httpd-prefork: non-strict dependency on apache2-common
> error: apache2-httpd-event: non-strict dependency on apache2-common
> error: apache2-httpd-itk: non-strict dependency on apache2-common
> error: apache2-httpd-peruser: non-strict dependency on apache2-common
> 
>   Фактически, здесь недолинкованные библиотеки (модули
> в apache2-common) зависят от бинарников, подставляемых пакетми
> apache2-httpd-{worker,prefork,event,itk,peruser} через альтернативу
> %apache2_sbindir/%apache2_dname (/usr/sbin/httpd2), но направление
> зависимостей выставлено обратным. Т. е. для rpm не модули
> (apache2-common) зависят от исполняемых бинарников (/usr/sbin/httpd2),
> что имеет место быть по факту, а бинарники (пакеты apache2-httpd-*) от
> модулей (apache2-common). (Пакет apache2-common выбран центральной
> сущностью.)
> 
>   От проблем защищают:
> 
> 1. Привязка к конкретному MMU (Module Magic Number, см.
> <http://httpd.apache.org/docs/2.2/glossary.html>) (apache2-common
> предоставляет %name-mmn = %mmn, а apache2-httpd-* его _строго_ требуют).
> 
> 2. Есть защита от использования не той libaprutil1, через:
> 
> а) Requires: libaprutil1 >= %n_aprutil_devel_ver в apache2-common
> (%n_aprutil_devel_ver соответствует версии-релизу пакета
> libaprutil1-devel использованного при сборке).
> 
> б) Автозависимость вида libaprutil-1.so.0()(64bit) >= set:... (наши
> set-version, или как их назвать правильно) в пакетах
> apache2-httpd-{worker,prefork,event,itk,peruser}.
> 
> Т. е. сейчас я считаю что пакет libaprutil1 такой-же или более новый чем
> libaprutil1-devel использованный при сборке, скорее всего подойдёт для
> модулей (в apache2-common). (С пакетами apache2-httpd-* проще -- там
> set-version работает.)
> 
>   Понятно что это тонкое место, и что для модулей нужно делать
> автогенирацию нечто подобного /usr/sbin/httpd2 >= set:... (по аналогии
> set-version сделанного для библиотек), но я не знаю как подступиться к
> данной задачи.
> 
>   Что здесь стоит сделать (могу, достаточно быстро):
> 
> 1. Удалить устаревшие, не актуальные, условия (например, сейчас по
> факту, от libssl зависит только apache2-mod_ssl).
> 
> 2. Сделать защиту от использования не той libapr1 (по аналогии
> сделанного для libaprutil1).
> 
> 3. Сделать привязку к версии libpcre (требуется apache2-httpd-*, для
> apache2-common похоже не нужно, но может потребоваться другим модулям).

Мне кажется, что здесь было бы вполне естественно просто поставить строгую
зависимость apache2-httpd-* на apache2-common; мы ведь практически ничего
не выигрываем от того, что существует возможность одновременно установить 
apache2-httpd-worker и apache2-common от разных сборок.

> 
> error: apache2-manual: non-strict dependency on apache2-base
> error: apache2-manual: non-strict dependency on apache2-common
> 
>   Это контент. Заведомо будет работать с любыми совместимыми версиями
> (задано нестрогими зависимостями и конфликтами).

И в каких случаях такая свобода выбора могла бы быть полезна?

> error: apache2-mod_ldap: non-strict dependency on apache2-common
> 
>   Фактические требования модуля совпадают с требованием модулей
> находящихся в apache2-common. Но т. к. apache2-common выбран центральной
> сущностью -- все завязано на него. Модуль не зависит от
> %apache2_sbindir/%apache2_dname, но требуют:
> 
> PreReq: %name-common
> Requires: %name-mmn = %mmn
> Requires: libaprutil1-ldap >= %n_aprutil_devel_ver
> 
> error: apache2-mod_disk_cache: non-strict dependency on apache2-common
> error: apache2-mod_ssl: non-strict dependency on apache2-common
> error: apache2-suexec: non-strict dependency on apache2-common
> 
>   Практически аналогично apache2-mod_ldap. (Но похоже нужно использовать
> Requires: libaprutil1 >= %n_aprutil_devel_ver -- сейчас зависимости на
> libaprutil1 сдесь нет.)

Опять же, не вижу, какая могла бы быть польза в возможность одновременно
установить эти пакеты и apache2-common от разных сборок.

> error: apache2-compat: non-strict dependency on apache2-base
> error: apache2-compat: non-strict dependency on apache2-common
> error: apache2-mod_ssl-compat: non-strict dependency on apache2-common
> 
>   Конфиги. С бинарниками напрямую не связанны. Oт apache2-{base,common}
> нужна инфроструктура и работающие с ней утилиты.
> 
> error: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs
> error: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs
> 
>   CGI скрипты. С бинарниками напрямую не связанны.
> 
> error: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache
> 
>   Обусловлено требованием каталога, содержащегося
> в apache2-mod_disk_cache:
> 
> Requires: %apache2_htcacheclean_cachepath

За исключением альтернативных провайдеров %apache2_sbindir/%apache2_dname,
все это выборное разнообразие выглядит самым что ни на есть сферическим
индейцем в вакууме.


-- 
ldv

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

Re: [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} (was: dependency needs Epoch warnings)

[Aleksey Avdeev]

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

24.01.2013 20:52, Dmitry V. Levin пишет:
> On Thu, Jan 24, 2013 at 04:21:11PM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 15:31, Dmitry V. Levin пишет:
>>> On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
>>>> 24.01.2013 10:53, Dmitry V. Levin пишет:
>>>>> По моим данным, в Сизифе 44 пакета, которые собираются с этим
>>>>> предупреждением, например:
>>>>> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
>>>>> warning: xorg-server: dependency on xorg-server-common needs Epoch
>>>>> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
>>>>> warning: xorg-xephyr: dependency on xorg-server needs Epoch
>>>>> warning: xorg-xdmx: dependency on xorg-server needs Epoch
>>>>> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
>>>>> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
>>>>>
>>>>> То, что этот warning пора поднять до error, кажется очевидным.
>>>>> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
>>>>> обратно до уровня warning?
>>>>
>>>>   Нужно как миниум для apache2.
>>>
>>> Словам не верю, докажите.
>>
>>   OK, развёрнтый ответ пишу.

  См. соседнее письмо
(<http://lists.altlinux.org/pipermail/devel/2013-January/196451.html>).

>>
>>>
>>>> В противном случаи будет сломана
>>>> возможность делать точечные обновления компонентов apache2 и возможность
>>>> установки новых модулей (или их версий) на старый apache2 (если нет
>>>> противопоказаний по библиотекам, разумеется).
>>>
>>> Такая возможность не просто не нужна, она вредна и с ней надо бороться.
>>> При сборке apache2 тестируется в лучшем случае модули и сервер, собранные
>>> из одного исходного пакета, и не надо делать вид, что модули и сервер,
>>> собранные из разных исходного пакета, могут случайно заработать.
>>
>>   Для apache это скорее правило чем исключение:
>>
>> 1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic
>> Number, см. <http://httpd.apache.org/docs/2.2/glossary.html>), за
>> которым следит арстрим. У нас это реализовано через предоставление
>> зависимости Provides: %name-mmn = %mmn (где %mmn константа,
>> соответствующая собираемому apache2) пакетом apache2-commom (все модули
>> должны требовать зависимость с нужным им MMN).
>>
>> 2. Изменения сонеймов библиотек, с которыми собирается apache2, тоже
>> кодируются в виде зависемостей предоставляемых пакетом apache2-commom.
>> Список, правда, контролируется руками, и сейчас там только openssl:
>>
>> Provides: %name-%apache2_libssl_name = %apache2_libssl_soname
>>
>> где (см. пакет rpm-macros-apache2):
>>
>> %apache2_libssl_name libssl
>>
>> %apache2_libssl_soname %(rpm -qR %apache2_libssl_name-devel | sed -rn
>> '/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')
>>
>> Если список надо расширить -- предложения принимаются. (Ранее, подобным
>> механизмом контролировался и сонейм lindb4, но теперь apache2 напрямую с
>> lindb4 не линкуется.)
>>
>> 3. Многие библиотеки apache2 использует через libapr/libaprutil, которые
>> и скрывают изменения их ABI.
>>
>> 4. Наши set-version для библиотек снимают заметную часть проблем.
>>
>>   Это касательно ABI. Требования по каталогам/файлам и содержимым
>> конфигов я контролирую руками.
> 
> Это все сложно и не дает гарантии, в отличие от простой конструкции вида
> Requires: %name = %{?epoch:%epoch:}%version-%release
> которая такую гарантию дает.

  Даст. Но она приведёт к строгой привязки модулей к тому бинарнику
/usr/sbin/httpd2, для которого они собирались => вызовет строгую
необходимость пересборки всех пакетов предоставляющих подпакеты
apache2-mod_* (т. к. их требования к /usr/sbin/httpd2 ничем не
отличаются от требований модулей находящихся в apache2-common) в рамках
одной транзакции, при сборке каждого из _релизов_ apache2. А это (судя
по <http://sisyphus.ru/ru/find.shtml?request=apache2-mod_>) 32 пакета,
из которых мой только 1 (сам apache2).

  Считаем такой подход (модули строго зависят от /usr/sbin/httpd2 с
заданными %{?epoch:%epoch:}%version-%release) вариантом 0.

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

$ rpm -qR apache2-httpd-prefork
...
/lib64/ld-linux-x86-64.so.2
libapr-1.so.0()(64bit) >=
set:mdScRzxUDK08PLNebAfs84ljmWQtoHRtFuNahVkzKhJ77vOoVPtNr9RLoLhKk2sSXCq4H4eVnVZw1I85fDiBiZshOi3Pan6ezU26kEnODWphetGh2qO9QAlvlOij3ZlJErbZwaLBhccEcR1TK0n2ZxDxi4UDau01gEU91gDZ2wpIHIgAEGpQdYZtRIpu8ZoiRNFGRE0EZBzU3cJcgbHHzg81FFxmpyZkRgKDmQ2ua7ii5eITpuR4XFBR6xqwx7etV9ggp1EwsxtZ0rJD1lz6B5RLU0Zm41aOE64t2Z0hob5PXO5sLoG4AqyXiF8LDQZsxhQit1kTfHoZ8rr88haHXOB0PGZb7abFhZ12BePFn92NY0uhFYtxSM5rosXE1lxn9P1mHuIILqgUzs8RgvbmKPx4PwNB2PNJTLGyYoA2etXD9xIKhTA0ry6rNXDYO3GI0wfkhaI0k8zI67pG5cxApZGd7c1673bgFG9pL5Q8Kui5Z4Btmee4TPPQAi6hotCJoqAWFmNpbTYDisGfwY3j7nwx7cDqObUdHnHqqlUYgqejQK323k1aCfKfldECre5vnb4kuqQhdA2lKGxDlZu1a5AvRfZrg34Z9icOsScUBJ56JWXBMxE9wZwDF6083hCIykyCH5tfz8SI76cU6ixPRMB8rGEREZkAUNtsZ4ihY8pkVthZALvHPKn35ZsW8ZCGNWP1goVgGIzb4R63iVYxMXO7sNozU3ZrZewBZz4GiP9qYeVz3aQ9c7QVp8KUovwc7bDygRrIweB1noWF7dabLRRFqgaGGpaES4AZjIPCh6RnmPZaXzzlmysmsJYfAXoaIE7ejkwymXgqW18wq8QkSxD0L4hyv05nc0SR
rpmlib(SetVersions)
libaprutil-1.so.0()(64bit) >=
set:mdUR3aDfv8HX6HeiQIZfdNeVW0V0QCackx0AiRnCw0xLAl6KIlSq1IkpGRJ6B0EeRcgsethSxoyZ1Z83VATVj0Fpa3rG8Pn3lSEe41mf8oYIwXx2zjobEA3QsKd11g82cIZayfl0yH4rZ9siejISsnYbOw5fUbhs7D38T9Mq15kesYEFWMJ70TmCbgg9i4ykogWIDkKyiFoCfCAy7ZwKyH9GRuZdeylMVi4O5SIWpzv8AkjHbSOl1xyDsyAZevCUUPg7g2BG3fdNGLaEp1d04Ac3ckBWBPH5EayRVEm0VQbo9mzG2R61j9gkEJ9Rw8dVnZdt8pifxASid0b1FccqxGC920nbTpJ7m3uNEUZv4zUZzmu0a6Q2djK19jrQVIl01Pn7E4q928Zt2VoZhIZ2E469Sfz6NjTb0gXk7vC0sJQZmz0EutERAYyZp1kA5hpd8g1QfEY1T1Jq421xhCAEet961j12yxczG82FtlWKZtDMS1WKXoaks1ZsN18vJ7aoCXUg3COhvL2z8p3qfJ3udwijz8zyVO1PkPpvS1
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libpcre.so.3()(64bit) >= set:jgnWvEIM1hju
libpthread.so.0(GLIBC_2.2.5)(64bit)

  Видно, что если не учитывать lib64/ld-linux-x86-64.so.*, libc.so.* и
libpthread.so.*, то по библиотекам пакет зависит то libapr-1.so.*
(libapr1), libaprutil-1.so.* (libaprutil1) и libpcre.so.* (libpcre3) =>
(при неизменном MMN) ABI можно считать зависимым только от данных
библиотек =>:

1. Для поддержки "строгих" (частично ослабленных) зависимостей нам
достаточно чтобы модули собирались с теми
%{?epoch:%epoch:}%version-%release libapr{,util}1-devel
и libpcre-devel, что и apache2-httpd-*. Это позволит отказаться от
переборки сторонних пакетов apache2-mod_* при _каждом_ обновлении
apache2. Достаточно будет переборки при изменении libapr{,util}1-devel
или libpcre-devel. Но комплект из apache2 и _всех_ сторонних
apache2-mod_* придётся пересобирать при _каждых_ обновлениях
libapr{,util}1 и libpcre3 (и не исключено что одной транзакцией).

2. Если считать, что без изменения сонейма апстримы libapr{,util} и
libpcre обратную совместимость ABI не ломают, то можно считать
достаточным чтобы пакеты apache2-mod_* и apache2-httpd-* требовали
пакеты libapr{,util}1 и libpcre3 с %{?epoch:%epoch:}%version-%release >=
чем было предоставлено пакетами libapr{,util}1-devel и libpcre-devel с
которыми они (модули и бинарник) собирались. Этот вариант самый лёгкий в
поддержке.

  Свожу варианты:

0:

  +:

    а) надёжность максимальна;

    б) проще всего реализуется в спеке;

    в) нет нестрогих зависимостей;

  -:

    а) наибольшая трудоёмкость в поддержке: при _любом_ обновлении
apache2 -- пересборка _всех_ пакетов предоставляющих apache2-mod_*);

    6) мне нужны будут права на NMU всех пакетов предоставляющих
apache2-mod_* (или придётся каждый раз ждать, пока владельцы затронутых
пакетов дадут разрешение на их пересборку);

1:

  +:

    а) если libapr{,util}1 и libpcre3 не менялись -- при сборках apache2
можно не трогать пакеты предоставляющие apache2-mod_* => меньше дёргать
сторонние пакеты => поддерживать проще чем вариант 0;

  -:

    а) меньшая надёжность чем в варианте 0;

    б) конструкции в спеке сложнее чем в варианте 0;

    в) мне нужны будут права на NMU всех пакетов предоставляющих
apache2-mod_* (или придётся каждый раз ждать, пока владельцы затронутых
пакетов дадут разрешение на их пересборку, как и в варианте 0);

2:

  +:

    а) если сонейм libapr{,util} и libpcre не менялся (и они по прежнему
libapr{,util}1 и libpcre3) -- пересборка apache2 сторонние apache2-mod_*
не затрагивает => жёсткой синхронизации сборок apache2 и сторонних
apache2-mod_* не требуется => поддержка проще чем вариант 1 (и
значительно проще чем вариант 0);

    б) NMU на сторонние пакеты не требуется и никого ожидать не нужно;

  -:

    а) надёжность меньше чем у варианта 1;

    б) конструкции в спеке сравнима с вариантом 1 => сложнее чем в
варианте 0;

  Используемый сейчас вариант, по факту, менее надёжен чем вариант 2.

> 
>> PS: Для меня проще всего забить на проблему, поставив строгие
>> зависимости. Но это ударит по пользователям. Особенно по тем, у кого
>> слабый канал (такой как аналоговый модем или GPRS) или вообще отсутствие
>> оного (выкачка пакетов сторонними средствами и последующая установка с
>> носителя).
> 
> Мы говорим о потенциальных пользователях, которые не смогут обновить
> apache2-base, или такие пользователи действительно существуют?

 То что пользователи сидящие на слабом и/или ограниченном (медленном,
дорогом не безлимитном и пр.) канале (или вообще без оного) существуют
-- для меня очевидно: голоса таких пользователей до сих пор встречаются
на LOR, opennet и иногда в наших рассылках. Как правило это люди из
глубинки (мест в десятки-сотни километров в стороне от региональных
центров) или администраторы обособленных систем, не подключённых к
интернет (например технологическое оборудование). Насколько это
множество пересекается с множеством наших пользователей (в смысле: тех
чьё мнение для нас, как Team, важно) -- я не знаю.

  Иногда таким пользователем являюсь я сам, когда тестирую
обновления/работу компонентов apache2 физически находясь на даче (Лен.
обл.) или в деревне (Новгородская обл.): Пакетирование и тестирование
тогда идет локально, на ноуте, а сборка -- удалённо (git.alt или
people). При этом ситуация, когда можно закачать только выбранные
пакеты, а не весть комплект, существенно снижает время закачки (в
деревне GPRS хренов: вышка далеко и телефон держит только 1-2 палки) и
финансовые затраты.

-- 

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



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

Re: [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} (was: dependency needs Epoch warnings)

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 01:44:09AM +0400, Aleksey Avdeev wrote:
> 24.01.2013 20:52, Dmitry V. Levin пишет:
> > On Thu, Jan 24, 2013 at 04:21:11PM +0400, Aleksey Avdeev wrote:
> >> 24.01.2013 15:31, Dmitry V. Levin пишет:
> >>> On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
> >>>> 24.01.2013 10:53, Dmitry V. Levin пишет:
> >>>>> По моим данным, в Сизифе 44 пакета, которые собираются с этим
> >>>>> предупреждением, например:
> >>>>> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
> >>>>> warning: xorg-server: dependency on xorg-server-common needs Epoch
> >>>>> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
> >>>>> warning: xorg-xephyr: dependency on xorg-server needs Epoch
> >>>>> warning: xorg-xdmx: dependency on xorg-server needs Epoch
> >>>>> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
> >>>>> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
> >>>>>
> >>>>> То, что этот warning пора поднять до error, кажется очевидным.
> >>>>> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
> >>>>> обратно до уровня warning?
> >>>>
> >>>>   Нужно как миниум для apache2.
> >>>
> >>> Словам не верю, докажите.
> >>
> >>   OK, развёрнтый ответ пишу.
> 
>   См. соседнее письмо
> (<http://lists.altlinux.org/pipermail/devel/2013-January/196451.html>).
> 
> >>
> >>>
> >>>> В противном случаи будет сломана
> >>>> возможность делать точечные обновления компонентов apache2 и возможность
> >>>> установки новых модулей (или их версий) на старый apache2 (если нет
> >>>> противопоказаний по библиотекам, разумеется).
> >>>
> >>> Такая возможность не просто не нужна, она вредна и с ней надо бороться.
> >>> При сборке apache2 тестируется в лучшем случае модули и сервер, собранные
> >>> из одного исходного пакета, и не надо делать вид, что модули и сервер,
> >>> собранные из разных исходного пакета, могут случайно заработать.
> >>
> >>   Для apache это скорее правило чем исключение:
> >>
> >> 1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic
> >> Number, см. <http://httpd.apache.org/docs/2.2/glossary.html>), за
> >> которым следит арстрим. У нас это реализовано через предоставление
> >> зависимости Provides: %name-mmn = %mmn (где %mmn константа,
> >> соответствующая собираемому apache2) пакетом apache2-commom (все модули
> >> должны требовать зависимость с нужным им MMN).
> >>
> >> 2. Изменения сонеймов библиотек, с которыми собирается apache2, тоже
> >> кодируются в виде зависемостей предоставляемых пакетом apache2-commom.
> >> Список, правда, контролируется руками, и сейчас там только openssl:
> >>
> >> Provides: %name-%apache2_libssl_name = %apache2_libssl_soname
> >>
> >> где (см. пакет rpm-macros-apache2):
> >>
> >> %apache2_libssl_name libssl
> >>
> >> %apache2_libssl_soname %(rpm -qR %apache2_libssl_name-devel | sed -rn
> >> '/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')
> >>
> >> Если список надо расширить -- предложения принимаются. (Ранее, подобным
> >> механизмом контролировался и сонейм lindb4, но теперь apache2 напрямую с
> >> lindb4 не линкуется.)
> >>
> >> 3. Многие библиотеки apache2 использует через libapr/libaprutil, которые
> >> и скрывают изменения их ABI.
> >>
> >> 4. Наши set-version для библиотек снимают заметную часть проблем.
> >>
> >>   Это касательно ABI. Требования по каталогам/файлам и содержимым
> >> конфигов я контролирую руками.
> > 
> > Это все сложно и не дает гарантии, в отличие от простой конструкции вида
> > Requires: %name = %{?epoch:%epoch:}%version-%release
> > которая такую гарантию дает.
> 
>   Даст. Но она приведёт к строгой привязки модулей к тому бинарнику
> /usr/sbin/httpd2, для которого они собирались => вызовет строгую
> необходимость пересборки всех пакетов предоставляющих подпакеты
> apache2-mod_* (т. к. их требования к /usr/sbin/httpd2 ничем не
> отличаются от требований модулей находящихся в apache2-common) в рамках
> одной транзакции, при сборке каждого из _релизов_ apache2. А это (судя
> по <http://sisyphus.ru/ru/find.shtml?request=apache2-mod_>) 32 пакета,
> из которых мой только 1 (сам apache2).

Вы чего-то не поняли.  Все нестрогие зависимости, которые диагностирует
rpmbuild, относятся _исключительно_ к внутрипакетным зависимостям.
Так, нестрогие зависимости в apache2 - это нестрогие зависимости только
тех пакетов, которые получаются при сборке самого apache2.


-- 
ldv

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

Re: [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} (was: dependency needs Epoch warnings)

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 01:44:09AM +0400, Aleksey Avdeev wrote:
> 2. Если считать, что без изменения сонейма апстримы libapr{,util} и
> libpcre обратную совместимость ABI не ломают, то можно считать
> достаточным чтобы пакеты apache2-mod_* и apache2-httpd-* требовали
> пакеты libapr{,util}1 и libpcre3 с %{?epoch:%epoch:}%version-%release >=
> чем было предоставлено пакетами libapr{,util}1-devel и libpcre-devel с
> которыми они (модули и бинарник) собирались. Этот вариант самый лёгкий в
> поддержке.

Даже это overkill: если в libapr, libaprutil и libpcre обратную
совместимость ABI не ломают, то можно положиться на зависимости set-version.


-- 
ldv

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

Re: [devel] %EVR macro

[Dmitry V. Levin]

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

On Thu, Jan 24, 2013 at 06:22:13PM +0200, Led wrote:
> On Thursday 24 January 2013 18:00:54 Dmitry V. Levin wrote:
> > On Thu, Jan 24, 2013 at 05:54:09PM +0200, Led wrote:
> > > 2013/1/24 Dmitry V. Levin <ldv@altlinux.org>
> > >
> > > > On Thu, Jan 24, 2013 at 11:07:29AM +0300, Eugene Prokopiev wrote:
> > > > > Dmitry V. Levin:
> > > > > > On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> > > > > > > Igor Vlasenko:
> > > > > > > > Может, лучше не спешить, для начала пройтись NMU от repocop?
> > > > > > > > завтра-послезавтра напишу тест, будут доступны патчи от
> > > > > > > > repocop, можно будет опросить майнтайнеров и с учетом их
> > > > > > > > замечаний провести NMU от repocop.
> > > > > > > >
> > > > > > > > я не откажусь от NMU, заодно поглядим, как repocop справится с
> > > > > >
> > > > > > specsubst ;)
> > > > > >
> > > > > > И не надейтесь, не справится, лучше умелыми ручками.
> > > > >
> > > > > Тогда можно краткое объяснение или урл - что это за проблема и как ее
> > > > > лечить. Неужели просто прописать недостающие зависимости вручную
> > > > > (иначе текст предупреждения у меня интерпретировать не получается)?
> > > >
> > > > Да, более-менее вручную, с использованием макросов %version и %release.
> > > > :)
> > >
> > > Может тогда лучше добавить в /usr/lib/rpm/macros
> > >
> > > %EVR %{expand:%%{?epoch:%%epoch:}%%version-%%release}
> > >
> > > ?
> > >
> > > Тогда можно везде вместо %version-%release писать %EVR и не задумываться:
> > > есть Epoch или нет.
> >
> > Кажется, repocop, когда делал NMU, использовал что-то похожее.
> > Только зачем здесь нужен expand?
> 
> Не знаю. Похоже, что не нужен:)

Добавил в простом варианте, без expand'а.  Кстати, аналогичные макросы
с разными именами, преимущественно %evr, легко нагугливаются.  Видимо,
они достаточно широко распространены.


-- 
ldv

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

Re: [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common}

[Aleksey Avdeev]

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

25.01.2013 01:47, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 01:44:09AM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 20:52, Dmitry V. Levin пишет:
>>> On Thu, Jan 24, 2013 at 04:21:11PM +0400, Aleksey Avdeev wrote:
>>>> 24.01.2013 15:31, Dmitry V. Levin пишет:
>>>>> On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
>>>>>> 24.01.2013 10:53, Dmitry V. Levin пишет:
>>>>>>> По моим данным, в Сизифе 44 пакета, которые собираются с этим
>>>>>>> предупреждением, например:
>>>>>>> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
>>>>>>> warning: xorg-server: dependency on xorg-server-common needs Epoch
>>>>>>> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
>>>>>>> warning: xorg-xephyr: dependency on xorg-server needs Epoch
>>>>>>> warning: xorg-xdmx: dependency on xorg-server needs Epoch
>>>>>>> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
>>>>>>> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
>>>>>>>
>>>>>>> То, что этот warning пора поднять до error, кажется очевидным.
>>>>>>> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
>>>>>>> обратно до уровня warning?
>>>>>>
>>>>>>   Нужно как миниум для apache2.
>>>>>
>>>>> Словам не верю, докажите.
>>>>
>>>>   OK, развёрнтый ответ пишу.
>>
>>   См. соседнее письмо
>> (<http://lists.altlinux.org/pipermail/devel/2013-January/196451.html>).
>>
>>>>
>>>>>
>>>>>> В противном случаи будет сломана
>>>>>> возможность делать точечные обновления компонентов apache2 и возможность
>>>>>> установки новых модулей (или их версий) на старый apache2 (если нет
>>>>>> противопоказаний по библиотекам, разумеется).
>>>>>
>>>>> Такая возможность не просто не нужна, она вредна и с ней надо бороться.
>>>>> При сборке apache2 тестируется в лучшем случае модули и сервер, собранные
>>>>> из одного исходного пакета, и не надо делать вид, что модули и сервер,
>>>>> собранные из разных исходного пакета, могут случайно заработать.
>>>>
>>>>   Для apache это скорее правило чем исключение:
>>>>
>>>> 1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic
>>>> Number, см. <http://httpd.apache.org/docs/2.2/glossary.html>), за
>>>> которым следит арстрим. У нас это реализовано через предоставление
>>>> зависимости Provides: %name-mmn = %mmn (где %mmn константа,
>>>> соответствующая собираемому apache2) пакетом apache2-commom (все модули
>>>> должны требовать зависимость с нужным им MMN).
>>>>
>>>> 2. Изменения сонеймов библиотек, с которыми собирается apache2, тоже
>>>> кодируются в виде зависемостей предоставляемых пакетом apache2-commom.
>>>> Список, правда, контролируется руками, и сейчас там только openssl:
>>>>
>>>> Provides: %name-%apache2_libssl_name = %apache2_libssl_soname
>>>>
>>>> где (см. пакет rpm-macros-apache2):
>>>>
>>>> %apache2_libssl_name libssl
>>>>
>>>> %apache2_libssl_soname %(rpm -qR %apache2_libssl_name-devel | sed -rn
>>>> '/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')
>>>>
>>>> Если список надо расширить -- предложения принимаются. (Ранее, подобным
>>>> механизмом контролировался и сонейм lindb4, но теперь apache2 напрямую с
>>>> lindb4 не линкуется.)
>>>>
>>>> 3. Многие библиотеки apache2 использует через libapr/libaprutil, которые
>>>> и скрывают изменения их ABI.
>>>>
>>>> 4. Наши set-version для библиотек снимают заметную часть проблем.
>>>>
>>>>   Это касательно ABI. Требования по каталогам/файлам и содержимым
>>>> конфигов я контролирую руками.
>>>
>>> Это все сложно и не дает гарантии, в отличие от простой конструкции вида
>>> Requires: %name = %{?epoch:%epoch:}%version-%release
>>> которая такую гарантию дает.
>>
>>   Даст. Но она приведёт к строгой привязки модулей к тому бинарнику
>> /usr/sbin/httpd2, для которого они собирались => вызовет строгую
>> необходимость пересборки всех пакетов предоставляющих подпакеты
>> apache2-mod_* (т. к. их требования к /usr/sbin/httpd2 ничем не
>> отличаются от требований модулей находящихся в apache2-common) в рамках
>> одной транзакции, при сборке каждого из _релизов_ apache2. А это (судя
>> по <http://sisyphus.ru/ru/find.shtml?request=apache2-mod_>) 32 пакета,
>> из которых мой только 1 (сам apache2).
> 
> Вы чего-то не поняли.  Все нестрогие зависимости, которые диагностирует
> rpmbuild, относятся _исключительно_ к внутрипакетным зависимостям.
> Так, нестрогие зависимости в apache2 - это нестрогие зависимости только
> тех пакетов, которые получаются при сборке самого apache2.

  Это я понял. Как и то, что нет проблемы поставить строгую зависимость
между пакетами apache2-httpd-* (содержащими /usr/sbin/httpd2) и пакетами
с модулями apache2-{mod_*,common} собираемыми из одного
apache2-*.src.rpm. Здесь, в такой постановке, действительно проблем нет.
Но это приведёт к тому, что зависимости для "родных" (собираемых из
дистрибутива apache2) и "сторонних" модулей apache2 нужно будет ставить
по разным схемам...

  А я то стараюсь проставить зависимости между apache2-httpd-*
apache2-{mod_*,common} по той же схеме, как они будут стоять между
apache2-httpd-* и _сторонними_ apache2-mod_*! (Это возможно, т. к. и
"родные" модули apache2 и "сторонние" используют общий интерфейс
/usr/sbin/httpd2.) Такой подход позволяет:

1. Обнаруживать львиную долю проблем точечного обновления apache2 и его
модулей на этапе внутреннего тестирования новой сборки apache2, в
процессе точечного поэтапного обновления компонентов работающего apache2
в тестовой виртуалке.

2. Всегда иметь готовый (протестированный) рецепт по исправлению проблем
с зависимостями для мантейнеров сторонних apache2-mod_*. (Сборка apache2
не идёт в Сизиф, пока у меня нет такого рецепта, т. к. она не проходит
мои внутренние тесты на виртуалках.)

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

-- 

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



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

Re: [devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common}

[Aleksey Avdeev]

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

25.01.2013 01:53, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 01:44:09AM +0400, Aleksey Avdeev wrote:
>> 2. Если считать, что без изменения сонейма апстримы libapr{,util} и
>> libpcre обратную совместимость ABI не ломают, то можно считать
>> достаточным чтобы пакеты apache2-mod_* и apache2-httpd-* требовали
>> пакеты libapr{,util}1 и libpcre3 с %{?epoch:%epoch:}%version-%release >=
>> чем было предоставлено пакетами libapr{,util}1-devel и libpcre-devel с
>> которыми они (модули и бинарник) собирались. Этот вариант самый лёгкий в
>> поддержке.
> 
> Даже это overkill: если в libapr, libaprutil и libpcre обратную
> совместимость ABI не ломают, то можно положиться на зависимости set-version.

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

-- 

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



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

Re: [devel] %EVR macro

[Led]

On Friday 25 January 2013 00:16:14 Dmitry V. Levin wrote:
> On Thu, Jan 24, 2013 at 06:22:13PM +0200, Led wrote:
> > On Thursday 24 January 2013 18:00:54 Dmitry V. Levin wrote:
> > > On Thu, Jan 24, 2013 at 05:54:09PM +0200, Led wrote:
> > > > 2013/1/24 Dmitry V. Levin <ldv@altlinux.org>
> > > >
> > > > > On Thu, Jan 24, 2013 at 11:07:29AM +0300, Eugene Prokopiev wrote:
> > > > > > Dmitry V. Levin:
> > > > > > > On Thu, Jan 24, 2013 at 09:32:32AM +0300, Eugene Prokopiev wrote:
> > > > > > > > Igor Vlasenko:
> > > > > > > > > Может, лучше не спешить, для начала пройтись NMU от
> > > > > > > > > repocop? завтра-послезавтра напишу тест, будут доступны
> > > > > > > > > патчи от repocop, можно будет опросить майнтайнеров и с
> > > > > > > > > учетом их замечаний провести NMU от repocop.
> > > > > > > > >
> > > > > > > > > я не откажусь от NMU, заодно поглядим, как repocop
> > > > > > > > > справится с
> > > > > > >
> > > > > > > specsubst ;)
> > > > > > >
> > > > > > > И не надейтесь, не справится, лучше умелыми ручками.
> > > > > >
> > > > > > Тогда можно краткое объяснение или урл - что это за проблема и
> > > > > > как ее лечить. Неужели просто прописать недостающие зависимости
> > > > > > вручную (иначе текст предупреждения у меня интерпретировать не
> > > > > > получается)?
> > > > >
> > > > > Да, более-менее вручную, с использованием макросов %version и
> > > > > %release.
> > > > >
> > > > > :)
> > > >
> > > > Может тогда лучше добавить в /usr/lib/rpm/macros
> > > >
> > > > %EVR %{expand:%%{?epoch:%%epoch:}%%version-%%release}
> > > >
> > > > ?
> > > >
> > > > Тогда можно везде вместо %version-%release писать %EVR и не
> > > > задумываться: есть Epoch или нет.
> > >
> > > Кажется, repocop, когда делал NMU, использовал что-то похожее.
> > > Только зачем здесь нужен expand?
> >
> > Не знаю. Похоже, что не нужен:)
>
> Добавил в простом варианте, без expand'а.  Кстати, аналогичные макросы
> с разными именами, преимущественно %evr, легко нагугливаются.  Видимо,
> они достаточно широко распространены.

Я, когда "придумал" себе такой %EVR (для пакетов с Epoch и множеством субпакетов), пройдясь пару раз по граблям с 
забытым/непроставленным %epoch:, тоже обнаружил для себя, что некоторые уже используют что-то подобное (%_EVR, %evr, 
etc.):)

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

-- 
Led

Re: [devel] non-strict dependency in apache2

[Aleksey Avdeev]

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

24.01.2013 23:15, Dmitry V. Levin пишет:
> On Thu, Jan 24, 2013 at 09:58:12PM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 15:25, Dmitry V. Levin пишет:
>>> On Thu, Jan 24, 2013 at 02:47:26PM +0400, Aleksey Avdeev wrote:
>>>> 24.01.2013 10:44, Dmitry V. Levin пишет:
>>>> ...
>>>>> В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
>>>>> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
>>>>> списка разрешенных пар нестрогих зависимостей:
>>>>> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2
>>>>
>>>>   Прошу уточнения:
>>>>
>>>> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие
>>>> зависимости на любой другой пакет из него же?
>>>>
>>>> 2. В каком виде должны присутствовать имена пакетов в списке:
>>>> %name-<subname> или достаточно <subname>?
>>>
>>> Имеется в виду, что каждый случай применения этого макроса стоит проводить
>>> через обсуждение в этом списке, хотя бы только для того, чтобы убедиться,
>>> что нестрогие зависимости в данном конкретном пакете действительно имеют
>>> смысл, а не являются следствием приземления благих намерений.
>>
>>   Тогда давайте обсуждать apache2, то что сейчас собираю (см.
>> <http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=blob;f=apache2.spec;h=c9e9fad9fb4dc01789edc90d6757de8c77b734dd;hb=ALT/apache2/spec>):
>>
>> error: apache2: non-strict dependency on apache2-cgi-bin
>> error: apache2: non-strict dependency on apache2-html
>> error: apache2: non-strict dependency on apache2-icons
>>
>>   Вызвано зависимостями:
>>
>> Requires: webserver-cgi-bin
>> Requires: webserver-html
>> Requires: webserver-icons
>>
>>   Данные зависимости предоставляют не только пакеты
>> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
>> apache2 _действительно_ всё равно, какие именно пакеты данные
>> зависимости реализуют.
> 
> Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
> От этого действительно может быть какая-то польза?  Или все это
> разнообразие упаковывается просто потому, что это возможно?

  Действительно нужно: у нас сейчас содержимое
/var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между
собой, вариантах: "от apache" и "от apache2" (см.
<http://www.altlinux.org/WebSubsystem>). И при этом есть запросы вида
(см. <https://bugzilla.altlinux.org/show_bug.cgi?id=16353>, как пример
дискуссии):

1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я
apache2 ставлю." -- решается пакетом apache2-full, вытягивает
apache2-{cgi-bin,html,icons}.

2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache
ставлю." -- решается пакетом apache-full, вытягивает
apache-{cgi-bin,html,icons}.

3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." --
решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и
вытягиваущими apache2-{cgi-bin,html,icons} по факту).

4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается
apache{,2}-base.

> 
>> error: apache2-base: non-strict dependency on apache2-common
>>
>>   apache2-base это в основном сборище конфигов, каталогов и пр. не
>> исполняемых файлов. Бинарные вспомогательные утилиты там тоже есть, но
>> от бинарного содержимого apache2-common (и его ABI) они не зависят.
>> Несовместимости учтены зависимостями вида
>> Requires: %name-common > 2.2.22-alt11 в самом пакете и конфликтами вида
>> Conflicts: apache2-base <= 2.2.22-alt11 в apache2-common.
> 
> Есть ли смысл использовать apache2-base и apache2-common от разных сборок
> одновременно?  Мне кажется, что здесь чем проще, тем лучше.

  Да. apache2-base это: конфиги (и их примеры), стартовые файлы httpd2
(для init/systemd), вспомогательные утилиты, сообщения об ошибках и пр.
инфраструктура. apache2-common же это в основном модули и конфиги (и
утилиты) для них (хотя куски инфраструктуры там тоже есть). Для закрытия
большинства багов связанных с безопасностью (CVE и подобные) достаточно
обновить только apache2-common (если проблемный модуль там, или другой
нужный apache2-mod_*) и используемый apache2-httpd-* (причём, в заметном
числе случаев, когда бага и исправление затрагивают только модуль, его
тоже трогать не нужно).

> 
>> error: apache2-base: non-strict dependency on apache2-httpd-worker
>> error: apache2-base: non-strict dependency on apache2-httpd-prefork
>> error: apache2-base: non-strict dependency on apache2-httpd-event
>> error: apache2-base: non-strict dependency on apache2-httpd-itk
>> error: apache2-base: non-strict dependency on apache2-httpd-peruser
>>
>>   Вызвано требованием:
>>
>> Requires: %apache2_sbindir/%apache2_dname
>>
>> т. к. файл %apache2_sbindir/%apache2_dname альтернатива, предоставляемая
>> всеми перечисленными подпакетами
>> (apache2-httpd-{worker,prefork,event,itk,peruser}).
> 
> Вот это очень похоже на реальную альтернативу, где неявность зависимости
> объективно связана с возможностью осмысленного выбора.
> 
>> error: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
>> error: apache2-configs-A1PROXIED: non-strict dependency on apache2-common
>>
>>   Комплект конфигов. Совместимость учтена через зависимости.
> 
> Не понимаю.

$ rpm -ql apache2-configs-A1PROXIED
/etc/httpd2/conf/ports-available/http-A1PROXIED.conf
/etc/httpd2/conf/ports-enabled/http-A1PROXIED.conf
/etc/httpd2/conf/ports-start.d/020-A1PROXIED.conf
/etc/httpd2/conf/sites-available/vhosts-A1PROXIED.conf
/etc/httpd2/conf/sites-enabled/vhosts-A1PROXIED.conf
/etc/httpd2/conf/sites-start.d/020-A1PROXIED.conf

  Для пакета необходимо только чтобы существовали инклюдируемые файлы:
/etc/httpd2/conf/ports-available/http{,-localhost-8088}.conf для
/etc/httpd2/conf/ports-available/http-A1PROXIED.conf и
/etc/httpd2/conf/sites-available/vhosts{,-8088}.conf для
/etc/httpd2/conf/sites-available/vhosts-A1PROXIED.conf. Всё остальное (в
том числе _версия_ бинарников apache2 и содержимое инклюдируемых файлов)
-- данному пакету глубоко фиолетово.

> 
>> error: apache2-httpd-worker: non-strict dependency on apache2-common
>> error: apache2-httpd-prefork: non-strict dependency on apache2-common
>> error: apache2-httpd-event: non-strict dependency on apache2-common
>> error: apache2-httpd-itk: non-strict dependency on apache2-common
>> error: apache2-httpd-peruser: non-strict dependency on apache2-common
>>
>>   Фактически, здесь недолинкованные библиотеки (модули
>> в apache2-common) зависят от бинарников, подставляемых пакетми
>> apache2-httpd-{worker,prefork,event,itk,peruser} через альтернативу
>> %apache2_sbindir/%apache2_dname (/usr/sbin/httpd2), но направление
>> зависимостей выставлено обратным. Т. е. для rpm не модули
>> (apache2-common) зависят от исполняемых бинарников (/usr/sbin/httpd2),
>> что имеет место быть по факту, а бинарники (пакеты apache2-httpd-*) от
>> модулей (apache2-common). (Пакет apache2-common выбран центральной
>> сущностью.)
>>
>>   От проблем защищают:
>>
>> 1. Привязка к конкретному MMU (Module Magic Number, см.
>> <http://httpd.apache.org/docs/2.2/glossary.html>) (apache2-common
>> предоставляет %name-mmn = %mmn, а apache2-httpd-* его _строго_ требуют).
>>
>> 2. Есть защита от использования не той libaprutil1, через:
>>
>> а) Requires: libaprutil1 >= %n_aprutil_devel_ver в apache2-common
>> (%n_aprutil_devel_ver соответствует версии-релизу пакета
>> libaprutil1-devel использованного при сборке).
>>
>> б) Автозависимость вида libaprutil-1.so.0()(64bit) >= set:... (наши
>> set-version, или как их назвать правильно) в пакетах
>> apache2-httpd-{worker,prefork,event,itk,peruser}.
>>
>> Т. е. сейчас я считаю что пакет libaprutil1 такой-же или более новый чем
>> libaprutil1-devel использованный при сборке, скорее всего подойдёт для
>> модулей (в apache2-common). (С пакетами apache2-httpd-* проще -- там
>> set-version работает.)
>>
>>   Понятно что это тонкое место, и что для модулей нужно делать
>> автогенирацию нечто подобного /usr/sbin/httpd2 >= set:... (по аналогии
>> set-version сделанного для библиотек), но я не знаю как подступиться к
>> данной задачи.
>>
>>   Что здесь стоит сделать (могу, достаточно быстро):
>>
>> 1. Удалить устаревшие, не актуальные, условия (например, сейчас по
>> факту, от libssl зависит только apache2-mod_ssl).
>>
>> 2. Сделать защиту от использования не той libapr1 (по аналогии
>> сделанного для libaprutil1).
>>
>> 3. Сделать привязку к версии libpcre (требуется apache2-httpd-*, для
>> apache2-common похоже не нужно, но может потребоваться другим модулям).
> 
> Мне кажется, что здесь было бы вполне естественно просто поставить строгую
> зависимость apache2-httpd-* на apache2-common; мы ведь практически ничего
> не выигрываем от того, что существует возможность одновременно установить 
> apache2-httpd-worker и apache2-common от разных сборок.

  Здесь, пожалуй да: apache2-httpd-* пакеты маленькие. (Хотя релизы с
фактическим обновлением только кода модулей у apache2 бывают.)

> 
>>
>> error: apache2-manual: non-strict dependency on apache2-base
>> error: apache2-manual: non-strict dependency on apache2-common
>>
>>   Это контент. Заведомо будет работать с любыми совместимыми версиями
>> (задано нестрогими зависимостями и конфликтами).

  Точнее это конфиги + ссылка на контент.

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

  Когда необходимо закрыть дыру (затронут один из используемых модулей)
используя минимальное количество пакетов. Например, когда пакеты
ставятся с носителя на которой их выкачивают вручную через GPRS. А если
ещё в режиме телефонного управления ("обезьяна на телефоне"), когда
действия с консолью выполняет неподготовленный пользователь, которым ты
управляешь по телефону (был у меня подобный опыт).
> 
>> error: apache2-mod_ldap: non-strict dependency on apache2-common
>>
>>   Фактические требования модуля совпадают с требованием модулей
>> находящихся в apache2-common. Но т. к. apache2-common выбран центральной
>> сущностью -- все завязано на него. Модуль не зависит от
>> %apache2_sbindir/%apache2_dname, но требуют:
>>
>> PreReq: %name-common
>> Requires: %name-mmn = %mmn
>> Requires: libaprutil1-ldap >= %n_aprutil_devel_ver
>>
>> error: apache2-mod_disk_cache: non-strict dependency on apache2-common
>> error: apache2-mod_ssl: non-strict dependency on apache2-common
>> error: apache2-suexec: non-strict dependency on apache2-common
>>
>>   Практически аналогично apache2-mod_ldap. (Но похоже нужно использовать
>> Requires: libaprutil1 >= %n_aprutil_devel_ver -- сейчас зависимости на
>> libaprutil1 сдесь нет.)
> 
> Опять же, не вижу, какая могла бы быть польза в возможность одновременно
> установить эти пакеты и apache2-common от разных сборок.

  Например, когда срочно нужно закрыть дыру в mod_ssl, mod_suexec или
mod_disk_cache (не затрагивающею httpd2 и модули apache2-common) в
условиях необходимости минимизации числа устанавливаемых пакетов (см.
пример выше).

  Кроме того, на этих пакетах решается, и тестируется, задача корректной
установки зависимостей для сторонних модулей apache2. Подробности в
соседнем письме (см.
<http://lists.altlinux.org/pipermail/devel/2013-January/196457.html>).

> 
>> error: apache2-compat: non-strict dependency on apache2-base
>> error: apache2-compat: non-strict dependency on apache2-common
>> error: apache2-mod_ssl-compat: non-strict dependency on apache2-common
>>
>>   Конфиги. С бинарниками напрямую не связанны. Oт apache2-{base,common}
>> нужна инфроструктура и работающие с ней утилиты.
>>
>> error: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs
>> error: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs
>>
>>   CGI скрипты. С бинарниками напрямую не связанны.
>>
>> error: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache
>>
>>   Обусловлено требованием каталога, содержащегося
>> в apache2-mod_disk_cache:
>>
>> Requires: %apache2_htcacheclean_cachepath
> 
> За исключением альтернативных провайдеров %apache2_sbindir/%apache2_dname,
> все это выборное разнообразие выглядит самым что ни на есть сферическим
> индейцем в вакууме.

  Это разнообразие позволяет закрыть дыру, локализованную в неком
бинарном компоненте apache2 (в модуле или демоне), обойдясь точечным
обновлением минимального количества пакетов. И как правило оно удаётся.
(Кроме периодов инфраструктурных изменений в apache2 или системе.)

-- 

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



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

Re: [devel] %EVR macro

[Aleksey Avdeev]

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

25.01.2013 02:37, Led пишет:
...
> Я, когда "придумал" себе такой %EVR (для пакетов с Epoch и множеством субпакетов), пройдясь пару раз по граблям с 
> забытым/непроставленным %epoch:, тоже обнаружил для себя, что некоторые уже используют что-то подобное (%_EVR, %evr, 
> etc.):)
> 
> Но то, что он теперь у нас в стандартных макросах rpm, повышает удобство в разы. Осталось малое - заиметь привычку его 
> использовать и, возможно, на всякий случай, сбэкпортить в rpm в поддерживаемых бранчах (?)

  +1

  Это облегчит поддержку бранчей.

-- 

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



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

Re: [devel] non-strict dependency in apache2

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 03:19:07AM +0400, Aleksey Avdeev wrote:
[...]
> >> error: apache2: non-strict dependency on apache2-cgi-bin
> >> error: apache2: non-strict dependency on apache2-html
> >> error: apache2: non-strict dependency on apache2-icons
> >>
> >>   Вызвано зависимостями:
> >>
> >> Requires: webserver-cgi-bin
> >> Requires: webserver-html
> >> Requires: webserver-icons
> >>
> >>   Данные зависимости предоставляют не только пакеты
> >> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
> >> apache2 _действительно_ всё равно, какие именно пакеты данные
> >> зависимости реализуют.
> > 
> > Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
> > От этого действительно может быть какая-то польза?  Или все это
> > разнообразие упаковывается просто потому, что это возможно?
> 
>   Действительно нужно: у нас сейчас содержимое
> /var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между
> собой, вариантах: "от apache" и "от apache2" (см.
> <http://www.altlinux.org/WebSubsystem>). И при этом есть запросы вида
> (см. <https://bugzilla.altlinux.org/show_bug.cgi?id=16353>, как пример
> дискуссии):
> 
> 1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я
> apache2 ставлю." -- решается пакетом apache2-full, вытягивает
> apache2-{cgi-bin,html,icons}.
> 
> 2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache
> ставлю." -- решается пакетом apache-full, вытягивает
> apache-{cgi-bin,html,icons}.
> 
> 3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." --
> решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и
> вытягиваущими apache2-{cgi-bin,html,icons} по факту).
> 
> 4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается
> apache{,2}-base.

Сисадмин заполняет /var/www/ тем, чем считает нужным - это совершенно
нормально.  Но ведь это еще не повод паковать все, что в принципе можно
было бы положить в /var/www/, в Сизиф!  Неужели только мне очевидно,
что для Сизифа было бы более чем достаточно одного варианта заполнения
/var/www/ cgi-bin'ами, html'ами и icons'ами?  Это уже не гибкость, а
изменение агрегатного состояния получается.


-- 
ldv

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

Re: [devel] non-strict dependency in apache2

[Aleksey Avdeev]

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

25.01.2013 03:37, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 03:19:07AM +0400, Aleksey Avdeev wrote:
> [...]
>>>> error: apache2: non-strict dependency on apache2-cgi-bin
>>>> error: apache2: non-strict dependency on apache2-html
>>>> error: apache2: non-strict dependency on apache2-icons
>>>>
>>>>   Вызвано зависимостями:
>>>>
>>>> Requires: webserver-cgi-bin
>>>> Requires: webserver-html
>>>> Requires: webserver-icons
>>>>
>>>>   Данные зависимости предоставляют не только пакеты
>>>> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
>>>> apache2 _действительно_ всё равно, какие именно пакеты данные
>>>> зависимости реализуют.
>>>
>>> Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
>>> От этого действительно может быть какая-то польза?  Или все это
>>> разнообразие упаковывается просто потому, что это возможно?
>>
>>   Действительно нужно: у нас сейчас содержимое
>> /var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между
>> собой, вариантах: "от apache" и "от apache2" (см.
>> <http://www.altlinux.org/WebSubsystem>). И при этом есть запросы вида
>> (см. <https://bugzilla.altlinux.org/show_bug.cgi?id=16353>, как пример
>> дискуссии):
>>
>> 1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я
>> apache2 ставлю." -- решается пакетом apache2-full, вытягивает
>> apache2-{cgi-bin,html,icons}.
>>
>> 2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache
>> ставлю." -- решается пакетом apache-full, вытягивает
>> apache-{cgi-bin,html,icons}.
>>
>> 3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." --
>> решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и
>> вытягиваущими apache2-{cgi-bin,html,icons} по факту).
>>
>> 4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается
>> apache{,2}-base.
> 
> Сисадмин заполняет /var/www/ тем, чем считает нужным - это совершенно
> нормально.  Но ведь это еще не повод паковать все, что в принципе можно
> было бы положить в /var/www/, в Сизиф!  Неужели только мне очевидно,
> что для Сизифа было бы более чем достаточно одного варианта заполнения
> /var/www/ cgi-bin'ами, html'ами и icons'ами?  Это уже не гибкость, а
> изменение агрегатного состояния получается.

  Моё личное мнение -- Сизифа (и дистрибутивов) нужно сделать наше
фирменное наполнение /var/www/ и использовать его для всех web серверов.
Но далеко не все его поддерживают: претензии вида "а почему при
установке apache у меня ставятся пакеты от apache2" в наших рассылка
встречаются (по моему даже в 2012 что-то подобное было, про 2011 и 2010
молчу -- чем дальше назад тем претензия более частая). (Сейчас
стандартный ответ -- ставьте вариант apache{,2}-full, если для вас это
критично.) Т. е. есть люди, для которых вид умолчальной страницы кретичен...

  В данном случаи мне проще создать схему, в рамках которой пользователь
сможет поставить именно ту умолчальную страницу которую он хочет, чем
бодаться с каждым, кому нужна именно родная страница устанавливаемого
apache{,2}. (Благо никаких особых проблем поддержка данной схемы не
доставляет.)

-- 

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



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

Re: [devel] non-strict dependency in apache2

[Dmitry V. Levin]

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

On Fri, Jan 25, 2013 at 04:48:38AM +0400, Aleksey Avdeev wrote:
> 25.01.2013 03:37, Dmitry V. Levin пишет:
> > On Fri, Jan 25, 2013 at 03:19:07AM +0400, Aleksey Avdeev wrote:
> > [...]
> >>>> error: apache2: non-strict dependency on apache2-cgi-bin
> >>>> error: apache2: non-strict dependency on apache2-html
> >>>> error: apache2: non-strict dependency on apache2-icons
> >>>>
> >>>>   Вызвано зависимостями:
> >>>>
> >>>> Requires: webserver-cgi-bin
> >>>> Requires: webserver-html
> >>>> Requires: webserver-icons
> >>>>
> >>>>   Данные зависимости предоставляют не только пакеты
> >>>> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
> >>>> apache2 _действительно_ всё равно, какие именно пакеты данные
> >>>> зависимости реализуют.
> >>>
> >>> Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
> >>> От этого действительно может быть какая-то польза?  Или все это
> >>> разнообразие упаковывается просто потому, что это возможно?
> >>
> >>   Действительно нужно: у нас сейчас содержимое
> >> /var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между
> >> собой, вариантах: "от apache" и "от apache2" (см.
> >> <http://www.altlinux.org/WebSubsystem>). И при этом есть запросы вида
> >> (см. <https://bugzilla.altlinux.org/show_bug.cgi?id=16353>, как пример
> >> дискуссии):
> >>
> >> 1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я
> >> apache2 ставлю." -- решается пакетом apache2-full, вытягивает
> >> apache2-{cgi-bin,html,icons}.
> >>
> >> 2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache
> >> ставлю." -- решается пакетом apache-full, вытягивает
> >> apache-{cgi-bin,html,icons}.
> >>
> >> 3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." --
> >> решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и
> >> вытягиваущими apache2-{cgi-bin,html,icons} по факту).
> >>
> >> 4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается
> >> apache{,2}-base.
> > 
> > Сисадмин заполняет /var/www/ тем, чем считает нужным - это совершенно
> > нормально.  Но ведь это еще не повод паковать все, что в принципе можно
> > было бы положить в /var/www/, в Сизиф!  Неужели только мне очевидно,
> > что для Сизифа было бы более чем достаточно одного варианта заполнения
> > /var/www/ cgi-bin'ами, html'ами и icons'ами?  Это уже не гибкость, а
> > изменение агрегатного состояния получается.
> 
>   Моё личное мнение -- Сизифа (и дистрибутивов) нужно сделать наше
> фирменное наполнение /var/www/ и использовать его для всех web серверов.
> Но далеко не все его поддерживают: претензии вида "а почему при
> установке apache у меня ставятся пакеты от apache2" в наших рассылка
> встречаются (по моему даже в 2012 что-то подобное было, про 2011 и 2010
> молчу -- чем дальше назад тем претензия более частая). (Сейчас
> стандартный ответ -- ставьте вариант apache{,2}-full, если для вас это
> критично.) Т. е. есть люди, для которых вид умолчальной страницы кретичен...
> 
>   В данном случаи мне проще создать схему, в рамках которой пользователь
> сможет поставить именно ту умолчальную страницу которую он хочет, чем
> бодаться с каждым, кому нужна именно родная страница устанавливаемого
> apache{,2}. (Благо никаких особых проблем поддержка данной схемы не
> доставляет.)

Я понял, говорить не имеет смысла, потому что слова просто уходят в песок.
OK, тогда rpmbuild будет автоматически делать примерно следующее:

adding strict dependency to apache2 on apache2-cgi-bin
adding strict dependency to apache2 on apache2-html
adding strict dependency to apache2 on apache2-icons
adding strict dependency to apache2-base on apache2-common
adding strict dependency to apache2-configs-A1PROXIED on apache2-base
adding strict dependency to apache2-httpd-worker on apache2-common
adding strict dependency to apache2-httpd-prefork on apache2-common
adding strict dependency to apache2-httpd-event on apache2-common
adding strict dependency to apache2-httpd-itk on apache2-common
adding strict dependency to apache2-httpd-peruser on apache2-common
adding strict dependency to apache2-manual on apache2-base
adding strict dependency to apache2-cgi-bin-test-cgi on apache2-datadirs
adding strict dependency to apache2-cgi-bin-printenv on apache2-datadirs
adding strict dependency to apache2-mod_ssl on apache2-common
adding strict dependency to apache2-mod_ldap on apache2-common
adding strict dependency to apache2-mod_disk_cache on apache2-common
adding strict dependency to apache2-htcacheclean on apache2-mod_disk_cache
adding strict dependency to apache2-suexec on apache2-common
adding strict dependency to apache2-compat on apache2-base
adding strict dependency to apache2-mod_ssl-compat on apache2-common
warning: apache2-base: non-strict dependency on apache2-httpd-worker
warning: apache2-base: non-strict dependency on apache2-httpd-prefork
warning: apache2-base: non-strict dependency on apache2-httpd-event
warning: apache2-base: non-strict dependency on apache2-httpd-itk
warning: apache2-base: non-strict dependency on apache2-httpd-peruser
removing 1 extra deps from apache2 due to dependency on apache2-cgi-bin
removing 1 extra deps from apache2 due to dependency on apache2-html
removing 1 extra deps from apache2 due to dependency on apache2-icons
removing 5 extra deps from apache2-base due to dependency on apache2-common
removing 1 extra deps from apache2-configs-A1PROXIED due to dependency on apache2-base
removing 1 extra deps from apache2-manual due to dependency on apache2-base
removing 1 extra deps from apache2-compat due to dependency on apache2-base
removing 2 extra deps from apache2-httpd-worker due to dependency on apache2-common
removing 2 extra deps from apache2-httpd-prefork due to dependency on apache2-common
removing 2 extra deps from apache2-httpd-event due to dependency on apache2-common
removing 2 extra deps from apache2-httpd-itk due to dependency on apache2-common
removing 2 extra deps from apache2-httpd-peruser due to dependency on apache2-common
removing 4 extra deps from apache2-mod_ssl due to dependency on apache2-common
removing 1 extra deps from apache2-mod_ldap due to dependency on apache2-common
removing 1 extra deps from apache2-mod_disk_cache due to dependency on apache2-common
removing 4 extra deps from apache2-suexec due to dependency on apache2-common
removing 2 extra deps from apache2-mod_ssl-compat due to dependency on apache2-common
removing 1 extra deps from apache2-cgi-bin-test-cgi due to dependency on apache2-datadirs
removing 1 extra deps from apache2-cgi-bin-printenv due to dependency on apache2-datadirs
removing 1 extra deps from apache2-htcacheclean due to dependency on apache2-mod_disk_cache
removing 2 extra deps from apache2-configs-A1PROXIED due to dependency on apache2-common
removing 2 extra deps from apache2-manual due to dependency on apache2-common
removing 2 extra deps from apache2-compat due to dependency on apache2-common
removing 13 extra deps from apache2-base due to repentancy on apache2-common
removing 1 extra deps from apache2-devel due to repentancy on apache2-base
removing 1 extra deps from apache2-manual due to repentancy on apache2-base
removing 7 extra deps from apache2-httpd-worker due to repentancy on apache2-common
removing 7 extra deps from apache2-httpd-prefork due to repentancy on apache2-common
removing 7 extra deps from apache2-httpd-event due to repentancy on apache2-common
removing 7 extra deps from apache2-httpd-itk due to repentancy on apache2-common
removing 7 extra deps from apache2-httpd-peruser due to repentancy on apache2-common
removing 2 extra deps from apache2-devel due to repentancy on apache2-common
removing 5 extra deps from apache2-mod_ssl due to repentancy on apache2-common
removing 4 extra deps from apache2-mod_ldap due to repentancy on apache2-common
removing 5 extra deps from apache2-mod_disk_cache due to repentancy on apache2-common
removing 9 extra deps from apache2-htcacheclean due to repentancy on apache2-common
removing 4 extra deps from apache2-suexec due to repentancy on apache2-common


-- 
ldv

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

Re: [devel] non-strict dependency in apache2

[Aleksey Avdeev]

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

25.01.2013 12:53, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 04:48:38AM +0400, Aleksey Avdeev wrote:
>> 25.01.2013 03:37, Dmitry V. Levin пишет:
>>> On Fri, Jan 25, 2013 at 03:19:07AM +0400, Aleksey Avdeev wrote:
>>> [...]
>>>>>> error: apache2: non-strict dependency on apache2-cgi-bin
>>>>>> error: apache2: non-strict dependency on apache2-html
>>>>>> error: apache2: non-strict dependency on apache2-icons
>>>>>>
>>>>>>   Вызвано зависимостями:
>>>>>>
>>>>>> Requires: webserver-cgi-bin
>>>>>> Requires: webserver-html
>>>>>> Requires: webserver-icons
>>>>>>
>>>>>>   Данные зависимости предоставляют не только пакеты
>>>>>> apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету
>>>>>> apache2 _действительно_ всё равно, какие именно пакеты данные
>>>>>> зависимости реализуют.
>>>>>
>>>>> Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}?
>>>>> От этого действительно может быть какая-то польза?  Или все это
>>>>> разнообразие упаковывается просто потому, что это возможно?
>>>>
>>>>   Действительно нужно: у нас сейчас содержимое
>>>> /var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между
>>>> собой, вариантах: "от apache" и "от apache2" (см.
>>>> <http://www.altlinux.org/WebSubsystem>). И при этом есть запросы вида
>>>> (см. <https://bugzilla.altlinux.org/show_bug.cgi?id=16353>, как пример
>>>> дискуссии):
>>>>
>>>> 1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я
>>>> apache2 ставлю." -- решается пакетом apache2-full, вытягивает
>>>> apache2-{cgi-bin,html,icons}.
>>>>
>>>> 2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache
>>>> ставлю." -- решается пакетом apache-full, вытягивает
>>>> apache-{cgi-bin,html,icons}.
>>>>
>>>> 3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." --
>>>> решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и
>>>> вытягиваущими apache2-{cgi-bin,html,icons} по факту).
>>>>
>>>> 4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается
>>>> apache{,2}-base.
>>>
>>> Сисадмин заполняет /var/www/ тем, чем считает нужным - это совершенно
>>> нормально.  Но ведь это еще не повод паковать все, что в принципе можно
>>> было бы положить в /var/www/, в Сизиф!  Неужели только мне очевидно,
>>> что для Сизифа было бы более чем достаточно одного варианта заполнения
>>> /var/www/ cgi-bin'ами, html'ами и icons'ами?  Это уже не гибкость, а
>>> изменение агрегатного состояния получается.
>>
>>   Моё личное мнение -- Сизифа (и дистрибутивов) нужно сделать наше
>> фирменное наполнение /var/www/ и использовать его для всех web серверов.
>> Но далеко не все его поддерживают: претензии вида "а почему при
>> установке apache у меня ставятся пакеты от apache2" в наших рассылка
>> встречаются (по моему даже в 2012 что-то подобное было, про 2011 и 2010
>> молчу -- чем дальше назад тем претензия более частая). (Сейчас
>> стандартный ответ -- ставьте вариант apache{,2}-full, если для вас это
>> критично.) Т. е. есть люди, для которых вид умолчальной страницы кретичен...
>>
>>   В данном случаи мне проще создать схему, в рамках которой пользователь
>> сможет поставить именно ту умолчальную страницу которую он хочет, чем
>> бодаться с каждым, кому нужна именно родная страница устанавливаемого
>> apache{,2}. (Благо никаких особых проблем поддержка данной схемы не
>> доставляет.)
> 
> Я понял, говорить не имеет смысла, потому что слова просто уходят в песок.
> OK, тогда rpmbuild будет автоматически делать примерно следующее:
> 
> adding strict dependency to apache2 on apache2-cgi-bin
...
> removing 4 extra deps from apache2-suexec due to repentancy on apache2-common

1. Где можно посмотреть на результат пересборки apache2 данным вариантом
rpmbuild`а? Интересует фактическое состояние Requires/Provides собранных
пакетов. (Пока складывается впечатление что точечные обновления apache2
будут сломаны.)

2. Возвращает ли %define _allowed_nonstrict_interdeps  старое поведение
(возможность non-strict dependency для указанных пакетов)?

-- 

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



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

Re: [devel] Рано поднимать до error

[REAL]

24.01.2013 17:57, Sergey V Turchin пишет:
> Диагностика не учитывает жесткие зависимости через другие _подпакеты_, как у
> меня во многих сделано.

она ещё не учитывает, что зависимости на библиотеки у нас 
проставляются автоматом плюс set-versions.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] %_allowed_nonstrict_interdeps (was: non-strict dependency warnings)

[Aleksey Avdeev]

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

24.01.2013 14:47, Aleksey Avdeev пишет:
> 24.01.2013 10:44, Dmitry V. Levin пишет:
> ...
>> В rpm-build-4.0.4-alt100.61 этот warning превратился в error,
>> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки
>> списка разрешенных пар нестрогих зависимостей:
>> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2
> 
>   Прошу уточнения:
> 
> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие
> зависимости на любой другой пакет из него же?
> 
> 2. В каком виде должны присутствовать имена пакетов в списке:
> %name-<subname> или достаточно <subname>?

  Практика показала, что %_allowed_nonstrict_interdeps -- список пар
подпакетов (вида %name-<subname>, внутрипарный разделитель ",")
разделённых пробелами.

  В качестве примера см. коммит
<http://git.altlinux.org/people/solo/packages/apache2.git?p=apache2.git;a=commitdiff;h=c55cf013c66df598a29d03ef7432c96942804d01>,
исправляющий ситуацию в apache2:

error: apache2: non-strict dependency on apache2-cgi-bin
error: apache2: non-strict dependency on apache2-html
error: apache2: non-strict dependency on apache2-icons
error: apache2-base: non-strict dependency on apache2-common
error: apache2-configs-A1PROXIED: non-strict dependency on apache2-base
error: apache2-base: non-strict dependency on apache2-httpd-worker
error: apache2-base: non-strict dependency on apache2-httpd-prefork
error: apache2-base: non-strict dependency on apache2-httpd-event
error: apache2-base: non-strict dependency on apache2-httpd-itk
error: apache2-base: non-strict dependency on apache2-httpd-peruser
error: apache2-manual: non-strict dependency on apache2-base
error: apache2-compat: non-strict dependency on apache2-base
error: apache2-configs-A1PROXIED: non-strict dependency on apache2-common
error: apache2-httpd-worker: non-strict dependency on apache2-common
error: apache2-httpd-prefork: non-strict dependency on apache2-common
error: apache2-httpd-event: non-strict dependency on apache2-common
error: apache2-httpd-itk: non-strict dependency on apache2-common
error: apache2-httpd-peruser: non-strict dependency on apache2-common
...

-- 

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



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

Re: [devel] Рано поднимать до error

[Dmitry V. Levin]

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

On Sat, Jan 26, 2013 at 02:49:14PM +0600, REAL wrote:
> 24.01.2013 17:57, Sergey V Turchin пишет:
> >Диагностика не учитывает жесткие 
> >зависимости через другие _подпакеты_, 
> >как у
> >меня во многих сделано.
> 
> она ещё не учитывает, что зависимости на 
> библиотеки у нас проставляются 
> автоматом плюс set-versions.

Любые зависимости дают меньшую гарантию, чем строгие внутрипакетные
зависимости.  Кроме того, наличие строгих внутрипакетных зависимостей
делает многие другие зависимости избыточными и позволяет их оптимизировать
(см. сообщения вида "removing N extra deps from ...' в логах сборки),
в том числе относительно дорогие зависимости в формате set-versions.


-- 
ldv

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

Re: [devel] Рано поднимать до error

[Aleksey Avdeev]

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

26.01.2013 14:39, Dmitry V. Levin пишет:
> On Sat, Jan 26, 2013 at 02:49:14PM +0600, REAL wrote:
>> 24.01.2013 17:57, Sergey V Turchin пишет:
>>> Диагностика не учитывает жесткие 
>>> зависимости через другие _подпакеты_, 
>>> как у
>>> меня во многих сделано.
>>
>> она ещё не учитывает, что зависимости на 
>> библиотеки у нас проставляются 
>> автоматом плюс set-versions.
> 
> Любые зависимости дают меньшую гарантию, чем строгие внутрипакетные
> зависимости.  Кроме того, наличие строгих внутрипакетных зависимостей
> делает многие другие зависимости избыточными и позволяет их оптимизировать
> (см. сообщения вида "removing N extra deps from ...' в логах сборки),
> в том числе относительно дорогие зависимости в формате set-versions.

  Если дело в сокращении set-versions (через замену их на строгие
зависимости), так может и ограничиться ими (простановкой строгих
зависимостей вместо внутрипакетных set-versions) и не стоит остальное с
плеча рубить?

  Как на счёт варианта:

1. Проставлять строгие зависимости вместо нестрогих с внутрипакетными
set-versions, без возможности отключения данного механизма.

2. Во всех остальных случаях, по умолчанию менять внутрипакетные
нестрогие зависимости на строгие, предусмотреть ручку для отключения
таких замен.

-- 

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



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

Re: [devel] Рано поднимать до error

[Sergey Vlasov]

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

On Sat, Jan 26, 2013 at 09:36:17PM +0400, Aleksey Avdeev wrote:
[...]
>   Если дело в сокращении set-versions (через замену их на строгие
> зависимости), так может и ограничиться ими (простановкой строгих
> зависимостей вместо внутрипакетных set-versions) и не стоит остальное с
> плеча рубить?
> 
>   Как на счёт варианта:
> 
> 1. Проставлять строгие зависимости вместо нестрогих с внутрипакетными
> set-versions, без возможности отключения данного механизма.
> 
> 2. Во всех остальных случаях, по умолчанию менять внутрипакетные
> нестрогие зависимости на строгие, предусмотреть ручку для отключения
> таких замен.

В соседней ветке предложен похожий вариант:

  http://lists.altlinux.org/pipermail/devel/2013-January/196540.html

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

Можно переформулировать это описание таким образом:

 1. Зависимости, найденные через find-requires (это могут быть не
    только set-versions, а и, например, perl(foo.pm)), которые
    удовлетворяются ровно одним подпакетом собираемого пакета,
    заменяются на строгие зависимости на этот подпакет без возможности
    отключения.

    (Интересно, встречаются ли реально ситуации, когда зависимость,
    найденная find-requires, удовлетворяется более чем одним
    подпакетом.)

 2. Зависимости, явно указанные в Requires, в которых указано реальное
    имя подпакета, заменяются на строгие зависимости на этот подпакет
    также без возможности отключения.

    (Теоретически возможна ситуация, когда имя реального подпакета
    присутствует также в другом подпакете в Provides - не уверен, что
    такое стоит вообще допускать; в этом случае, согласно приведённому
    алгоритму, зависимость не будет заменяться на строгую.)

 3. Зависимости, явно указанные в Requires, но с именем, не
    совпадающим ни с одним реальным именем подпакета, оставляются без
    изменения, даже если эта зависимость удовлетворяется ровно одним
    подпакетом.

    Это правило позволяет не сломать пакеты типа xboard, в которых
    присутствует подпакет, допускающий замену на альтернативные
    варианты (в случае xboard в том же пакете собирается подпакет с
    темой по умолчанию, но вместо него может быть установлен любой
    другой пакет с темой, при этом минимум одна тема должна
    присутствовать).  Аналогичная ситуация и в пакете osec (с той лишь
    разницей, что в данный момент в Сизифе нет ни одного пакета,
    которым можно было бы заменить osec-mailreport, но указанные в
    osec-cronjob зависимости позволяют создать такой альтернативный
    пакет).

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

При использовании этих правил, если требуется обеспечить нестрогую
зависимость между подпакетами, собираемыми из одного исходного пакета,
такую зависимость нужно будет реализовывать через промежуточный
виртуальный пакет (при этом могут быть наложены ограничения на версию
этого виртуального пакета, отражающие особенности собираемого ПО -
например, можно требовать совпадения major-версии или какого-то
внутреннего номера версии API).

Кстати, при анализе этих правил возник ещё один вопрос - что делать с
зависимостями, более сложными, чем "Requires: B" без указания версии,
в которых, тем не менее, указано реальное имя подпакета?  Например,
если указано "Requires: B = %version" (без "-%release"), нужно ли
менять эту зависимость на строгую?  А ведь возможен ещё вариант вида
"Requires: B >= x.y", для которого автоматическая замена на строгую
зависимость выглядит ещё более сомнительно (ведь зачем-то эта
нестрогая зависимость была записана именно в таком виде).  Возможно,
зависимости с условием, отличающимся от "=", также стоит оставлять в
неизменном виде, что также даст возможность создания ограниченно
нестрогих зависимостей - например, в пакете версии x.y.z может быть
указано "Requires: B >= x.y" и "Conflicts: B >= x.(y+1)".

[-- 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: 1935 bytes --]

On Sat, Jan 26, 2013 at 11:07:10PM +0400, Sergey Vlasov wrote:
[...]
>  2. Зависимости, явно указанные в Requires, в которых указано реальное
>     имя подпакета, заменяются на строгие зависимости на этот подпакет
>     также без возможности отключения.
> 
>     (Теоретически возможна ситуация, когда имя реального подпакета
>     присутствует также в другом подпакете в Provides - не уверен, что
>     такое стоит вообще допускать; в этом случае, согласно приведённому
>     алгоритму, зависимость не будет заменяться на строгую.)

Думаю что зависимость (как явную, так и неявную), в которой указано имя
подпакета, надо заменять на строгую.  Наличие в одном подпакете Provides
имени другого подпакета ничего, кроме путаницы, не принесет.  Такие
странные Provides, кстати, легко диагностировать во время сборки.

> Кстати, при анализе этих правил возник ещё один вопрос - что делать с
> зависимостями, более сложными, чем "Requires: B" без указания версии, в
> которых, тем не менее, указано реальное имя подпакета?  Например, если
> указано "Requires: B = %version" (без "-%release"), нужно ли менять эту
> зависимость на строгую?  А ведь возможен ещё вариант вида "Requires: B
> >= x.y", для которого автоматическая замена на строгую зависимость
> >выглядит ещё более сомнительно (ведь зачем-то эта нестрогая зависимость
> >была записана именно в таком виде).  Возможно, зависимости с условием,
> >отличающимся от "=", также стоит оставлять в неизменном виде, что также
> >даст возможность создания ограниченно нестрогих зависимостей -
> >например, в пакете версии x.y.z может быть указано "Requires: B >= x.y"
> >и "Conflicts: B >= x.(y+1)".

Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
не трогать.  Зависимости вида "B = %version" мне попадались, и это все
были случаи забытого -%release.  Думаю, что их надо усиливать так же, как
и зависимости без версии.


-- 
ldv

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

Re: [devel] Рано поднимать до error

[Aleksey Avdeev]

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

26.01.2013 23:07, Sergey Vlasov пишет:
> On Sat, Jan 26, 2013 at 09:36:17PM +0400, Aleksey Avdeev wrote:
> [...]
>>   Если дело в сокращении set-versions (через замену их на строгие
>> зависимости), так может и ограничиться ими (простановкой строгих
>> зависимостей вместо внутрипакетных set-versions) и не стоит остальное с
>> плеча рубить?
>>
>>   Как на счёт варианта:
>>
>> 1. Проставлять строгие зависимости вместо нестрогих с внутрипакетными
>> set-versions, без возможности отключения данного механизма.
>>
>> 2. Во всех остальных случаях, по умолчанию менять внутрипакетные
>> нестрогие зависимости на строгие, предусмотреть ручку для отключения
>> таких замен.
> 
> В соседней ветке предложен похожий вариант:
> 
>   http://lists.altlinux.org/pipermail/devel/2013-January/196540.html
> 
> | Другими словами, предлагается модифицировать алгоритм, чтобы он работал
> | следующим образом: подпакет A исходного пакета S автоматически получает
> | строгую зависимость от подпакета B исходного пакета S, если выполнено любое
> | из следующих условий:
> | - у A есть зависимость от B;
> | - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B
> |   является единственным подпакетом S, удовлетворяющим эту зависимость X.
> 
> Можно переформулировать это описание таким образом:
> 
>  1. Зависимости, найденные через find-requires (это могут быть не
>     только set-versions, а и, например, perl(foo.pm)), которые
>     удовлетворяются ровно одним подпакетом собираемого пакета,
>     заменяются на строгие зависимости на этот подпакет без возможности
>     отключения.

  Для меня допустимо, если явно указанные файловые зависимости
("Requires: <file>" при наличии "Provides: <file>" в соответствующем
подпакете) под этот пункт не попадают.

> 
>     (Интересно, встречаются ли реально ситуации, когда зависимость,
>     найденная find-requires, удовлетворяется более чем одним
>     подпакетом.)
> 
>  2. Зависимости, явно указанные в Requires, в которых указано реальное
>     имя подпакета, заменяются на строгие зависимости на этот подпакет
>     также без возможности отключения.
> 
>     (Теоретически возможна ситуация, когда имя реального подпакета
>     присутствует также в другом подпакете в Provides - не уверен, что
>     такое стоит вообще допускать; в этом случае, согласно приведённому
>     алгоритму, зависимость не будет заменяться на строгую.)
> 
>  3. Зависимости, явно указанные в Requires, но с именем, не
>     совпадающим ни с одним реальным именем подпакета, оставляются без
>     изменения, даже если эта зависимость удовлетворяется ровно одним
>     подпакетом.
> 
>     Это правило позволяет не сломать пакеты типа xboard, в которых
>     присутствует подпакет, допускающий замену на альтернативные
>     варианты (в случае xboard в том же пакете собирается подпакет с
>     темой по умолчанию, но вместо него может быть установлен любой
>     другой пакет с темой, при этом минимум одна тема должна
>     присутствовать).  Аналогичная ситуация и в пакете osec (с той лишь
>     разницей, что в данный момент в Сизифе нет ни одного пакета,
>     которым можно было бы заменить osec-mailreport, но указанные в
>     osec-cronjob зависимости позволяют создать такой альтернативный
>     пакет).
> 
>     Также под этот пункт могут попасть ошибочно оставленные
>     зависимости на устаревшее имя подпакета, если производилось
>     переименование подпакета с проставлением соответствующих Provides
>     и Obsoletes, но такую ситуацию можно обнаружить по наличию
>     Obsoletes с этим именем (если же ещё и Obsoletes забыли, тут уже
>     ничего не поможет, одна надежда на багрепорты по поводу
>     неработающего обновления).
> 
> При использовании этих правил, если требуется обеспечить нестрогую
> зависимость между подпакетами, собираемыми из одного исходного пакета,
> такую зависимость нужно будет реализовывать через промежуточный
> виртуальный пакет (при этом могут быть наложены ограничения на версию
> этого виртуального пакета, отражающие особенности собираемого ПО -
> например, можно требовать совпадения major-версии или какого-то
> внутреннего номера версии API).
> 
> Кстати, при анализе этих правил возник ещё один вопрос - что делать с
> зависимостями, более сложными, чем "Requires: B" без указания версии,
> в которых, тем не менее, указано реальное имя подпакета?  Например,
> если указано "Requires: B = %version" (без "-%release"), нужно ли
> менять эту зависимость на строгую?  А ведь возможен ещё вариант вида
> "Requires: B >= x.y", для которого автоматическая замена на строгую
> зависимость выглядит ещё более сомнительно (ведь зачем-то эта
> нестрогая зависимость была записана именно в таком виде).  Возможно,
> зависимости с условием, отличающимся от "=", также стоит оставлять в
> неизменном виде, что также даст возможность создания ограниченно
> нестрогих зависимостей - например, в пакете версии x.y.z может быть
> указано "Requires: B >= x.y" и "Conflicts: B >= x.(y+1)".

  У меня в качестве типовых нестрогих внутрипакетных зависимостей как
правило используются: "Requires: B >= x.y", "Conflicts: С <= x.y" (где B
и C как реальные так и виртуальные подпакеты) и "Requires: <file>" (как
правило при этом есть подпекет предоставляющий соответствующий
"Provides: <file>"). Принудительная замена такого рода внутрипакетных
зависимостей, без возможностей её отключения -- большая засада, для меня...

PS: Пересборка apache2-2.2.22-alt15 средствами
librpmbuild-4.0.4-alt100.63 (на people) показала что не так страшен
чёрт, как его малюют: результат вполне приемлемый, на первый взгляд.
(Более детально разбтраться в понедельник буду.)

-- 

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



[-- 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: 419 bytes --]

On Sun, Jan 27, 2013 at 12:08:14AM +0400, Dmitry V. Levin wrote:
> Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
> не трогать.

Это я поторопился, у нас как минимум find-requires генерит такие
зависимости (>= set:...).  Указанные в спеке зависимости с RPMSENSE_LESS
или RPMSENSE_GREATER, может быть, действительно лучше не трогать, но для
find-requires никаких исключений.


-- 
ldv

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

Re: [devel] non-strict deps

[Igor Zubkov]

2013/1/26 Dmitry V. Levin:
> Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
> не трогать.  Зависимости вида "B = %version" мне попадались, и это все
> были случаи забытого -%release.  Думаю, что их надо усиливать так же, как
> и зависимости без версии.

У меня в пакете supertux2 была зависимость на supertux2-data =
%version. Без релиза. Это было сделано для того что сами датники
просто не менялись и их можно не обновлять . Я такое делаю регулярно.
Это теперь не законно? :)

Мне в принципе не особо важно (в крупных пакетах типа nexuiz я всегда
датники упаковываю отдельно), просто для уточнения.

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Sun, Jan 27, 2013 at 01:31:29AM +0200, Igor Zubkov wrote:
> 2013/1/26 Dmitry V. Levin:
> > Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
> > не трогать.  Зависимости вида "B = %version" мне попадались, и это все
> > были случаи забытого -%release.  Думаю, что их надо усиливать так же, как
> > и зависимости без версии.
> 
> У меня в пакете supertux2 была зависимость на supertux2-data =
> %version. Без релиза. Это было сделано для того что сами датники
> просто не менялись и их можно не обновлять . Я такое делаю регулярно.

В supertux2.spec написано иначе:
Requires: %name-data = %version-%release

> Это теперь не законно? :)

rpmbuild просто поменяет ту зависимость на строгую.

> Мне в принципе не особо важно (в крупных пакетах типа nexuiz я всегда
> датники упаковываю отдельно), просто для уточнения.

Если данные живут своей жизнью, то логичнее было бы их упаковывать из своих
исходных пакетов.


-- 
ldv

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

Re: [devel] non-strict deps

[Led]

On Sunday 27 January 2013 01:56:35 Dmitry V. Levin wrote:
> On Sun, Jan 27, 2013 at 01:31:29AM +0200, Igor Zubkov wrote:
> > 2013/1/26 Dmitry V. Levin:
> > > Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
> > > не трогать.  Зависимости вида "B = %version" мне попадались, и это все
> > > были случаи забытого -%release.  Думаю, что их надо усиливать так же,
> > > как и зависимости без версии.
> >
> > У меня в пакете supertux2 была зависимость на supertux2-data =
> > %version. Без релиза. Это было сделано для того что сами датники
> > просто не менялись и их можно не обновлять . Я такое делаю регулярно.
>
> В supertux2.spec написано иначе:
> Requires: %name-data = %version-%release
>
> > Это теперь не законно? :)
>
> rpmbuild просто поменяет ту зависимость на строгую.
>
> > Мне в принципе не особо важно (в крупных пакетах типа nexuiz я всегда
> > датники упаковываю отдельно), просто для уточнения.
>
> Если данные живут своей жизнью, то логичнее было бы их упаковывать из своих
> исходных пакетов.

Данные находятся в том же git-дереве. Их легко было бы упаковать в отдельный "исходный пакет", если бы в "tar:" в 
gear-rules была возможность сделать exclude для каталога.

-- 
Led

Re: [devel] gear-rules

[Dmitry V. Levin]

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

On Sun, Jan 27, 2013 at 02:25:24AM +0200, Led wrote:
> On Sunday 27 January 2013 01:56:35 Dmitry V. Levin wrote:
[...]
> > Если данные живут своей жизнью, то логичнее было бы их упаковывать из своих
> > исходных пакетов.
> 
> Данные находятся в том же git-дереве. Их легко было бы упаковать в отдельный "исходный пакет", если бы в "tar:" в 
> gear-rules была возможность сделать exclude для каталога.

Метод "tar:" реализован поверх git-archive(1), в котором нет exclude.
Хотя мог бы быть, наверное...


-- 
ldv

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

Re: [devel] gear-rules

[Led]

On Sunday 27 January 2013 02:37:32 Dmitry V. Levin wrote:
> On Sun, Jan 27, 2013 at 02:25:24AM +0200, Led wrote:
> > On Sunday 27 January 2013 01:56:35 Dmitry V. Levin wrote:
>
> [...]
>
> > > Если данные живут своей жизнью, то логичнее было бы их упаковывать из
> > > своих исходных пакетов.
> >
> > Данные находятся в том же git-дереве. Их легко было бы упаковать в
> > отдельный "исходный пакет", если бы в "tar:" в gear-rules была
> > возможность сделать exclude для каталога.
>
> Метод "tar:" реализован поверх git-archive(1), в котором нет exclude.

Зато в tar есть '--delete':

git archive HEAD | tar --delete data > /tmp/tmp.tar

> Хотя мог бы быть, наверное...


-- 
Led

Re: [devel] gear-rules

[Dmitry V. Levin]

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

On Sun, Jan 27, 2013 at 02:56:25AM +0200, Led wrote:
> On Sunday 27 January 2013 02:37:32 Dmitry V. Levin wrote:
> > On Sun, Jan 27, 2013 at 02:25:24AM +0200, Led wrote:
> > > On Sunday 27 January 2013 01:56:35 Dmitry V. Levin wrote:
> >
> > [...]
> >
> > > > Если данные живут своей жизнью, то логичнее было бы их упаковывать из
> > > > своих исходных пакетов.
> > >
> > > Данные находятся в том же git-дереве. Их легко было бы упаковать в
> > > отдельный "исходный пакет", если бы в "tar:" в gear-rules была
> > > возможность сделать exclude для каталога.
> >
> > Метод "tar:" реализован поверх git-archive(1), в котором нет exclude.
> 
> Зато в tar есть '--delete':
> 
> git archive HEAD | tar --delete data > /tmp/tmp.tar

"The `--delete' option has been reported to work properly when `tar'
acts as a filter from `stdin' to `stdout'."

Она действительно работает?


-- 
ldv

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

Re: [devel] gear-rules

[Led]

On Sunday 27 January 2013 03:01:36 Dmitry V. Levin wrote:
> On Sun, Jan 27, 2013 at 02:56:25AM +0200, Led wrote:
> > On Sunday 27 January 2013 02:37:32 Dmitry V. Levin wrote:
> > > On Sun, Jan 27, 2013 at 02:25:24AM +0200, Led wrote:
> > > > On Sunday 27 January 2013 01:56:35 Dmitry V. Levin wrote:
> > >
> > > [...]
> > >
> > > > > Если данные живут своей жизнью, то логичнее было бы их упаковывать
> > > > > из своих исходных пакетов.
> > > >
> > > > Данные находятся в том же git-дереве. Их легко было бы упаковать в
> > > > отдельный "исходный пакет", если бы в "tar:" в gear-rules была
> > > > возможность сделать exclude для каталога.
> > >
> > > Метод "tar:" реализован поверх git-archive(1), в котором нет exclude.
> >
> > Зато в tar есть '--delete':
> >
> > git archive HEAD | tar --delete data > /tmp/tmp.tar
>
> "The `--delete' option has been reported to work properly when `tar'
> acts as a filter from `stdin' to `stdout'."
>
> Она действительно работает?

Да. Я привёл пример, который работает на supertux.git - исключает каталог data из результирующего тарбола.

-- 
Led

Re: [devel] Рано поднимать до error

[Sergey Vlasov]

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

On Sun, Jan 27, 2013 at 12:38:31AM +0400, Aleksey Avdeev wrote:
[...]
> >  1. Зависимости, найденные через find-requires (это могут быть не
> >     только set-versions, а и, например, perl(foo.pm)), которые
> >     удовлетворяются ровно одним подпакетом собираемого пакета,
> >     заменяются на строгие зависимости на этот подпакет без возможности
> >     отключения.
> 
>   Для меня допустимо, если явно указанные файловые зависимости
> ("Requires: <file>" при наличии "Provides: <file>" в соответствующем
> подпакете) под этот пункт не попадают.

Они и не должны попадать под этот пункт, поскольку явно указанные
зависимости не будут иметь флага RPMSENSE_FIND_REQUIRES.

[...]
>   У меня в качестве типовых нестрогих внутрипакетных зависимостей как
> правило используются: "Requires: B >= x.y", "Conflicts: С <= x.y" (где B
> и C как реальные так и виртуальные подпакеты) и "Requires: <file>" (как
> правило при этом есть подпекет предоставляющий соответствующий
> "Provides: <file>"). Принудительная замена такого рода внутрипакетных
> зависимостей, без возможностей её отключения -- большая засада, для меня...

Все такие зависимости, явно указанные в spec-файле, по обсуждаемым
правилам и не будут ни на что заменяться (Conflicts не предлагалось
трогать вовсе, Requires с условиями, кроме "=", по последним
сведениям, тоже остаются без изменений, зависимости на файлы
рассматриваются как зависимости на виртуальные пакеты и тоже не
меняются).

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

Re: [devel] non-strict deps

[Igor Zubkov]

2013/1/27 Dmitry V. Levin:
> On Sun, Jan 27, 2013 at 01:31:29AM +0200, Igor Zubkov wrote:
>> 2013/1/26 Dmitry V. Levin:
>> > Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
>> > не трогать.  Зависимости вида "B = %version" мне попадались, и это все
>> > были случаи забытого -%release.  Думаю, что их надо усиливать так же, как
>> > и зависимости без версии.
>>
>> У меня в пакете supertux2 была зависимость на supertux2-data =
>> %version. Без релиза. Это было сделано для того что сами датники
>> просто не менялись и их можно не обновлять . Я такое делаю регулярно.
>
> В supertux2.spec написано иначе:
> Requires: %name-data = %version-%release

Это сейчас. Версия из Сизифа сейчас собирается из git репозитория
апстрима и что бы ничего не сломалось, там строгая зависиость. А вот
версия 0.3.3-alt3.1
(http://ftp.altlinux.org/pub/distributions/archive/Sisyphus/2012/08/18/files/SRPMS/supertux2-0.3.3-alt3.1.src.rpm)
имела именно такую не строгую зависимость:

Requires: %name-data = %version

>> Это теперь не законно? :)
>
> rpmbuild просто поменяет ту зависимость на строгую.

Я ведь правильно понимаю все эти разговоры:
что Requires: %name-data = %version
будет заменен на Requires: %name-data = %version-%release ?

>> Мне в принципе не особо важно (в крупных пакетах типа nexuiz я всегда
>> датники упаковываю отдельно), просто для уточнения.
>
> Если данные живут своей жизнью, то логичнее было бы их упаковывать из своих
> исходных пакетов.


-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] non-strict deps

[Dmitry V. Levin]

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

On Wed, Jan 30, 2013 at 02:50:48AM +0200, Igor Zubkov wrote:
> 2013/1/27 Dmitry V. Levin:
> > On Sun, Jan 27, 2013 at 01:31:29AM +0200, Igor Zubkov wrote:
> >> 2013/1/26 Dmitry V. Levin:
> >> > Зависимости, в которых есть RPMSENSE_LESS или RPMSENSE_GREATER, лучше
> >> > не трогать.  Зависимости вида "B = %version" мне попадались, и это все
> >> > были случаи забытого -%release.  Думаю, что их надо усиливать так же, как
> >> > и зависимости без версии.
> >>
> >> У меня в пакете supertux2 была зависимость на supertux2-data =
> >> %version. Без релиза. Это было сделано для того что сами датники
> >> просто не менялись и их можно не обновлять . Я такое делаю регулярно.
> >
> > В supertux2.spec написано иначе:
> > Requires: %name-data = %version-%release
> 
> Это сейчас. Версия из Сизифа сейчас собирается из git репозитория
> апстрима и что бы ничего не сломалось, там строгая зависиость. А вот
> версия 0.3.3-alt3.1
> (http://ftp.altlinux.org/pub/distributions/archive/Sisyphus/2012/08/18/files/SRPMS/supertux2-0.3.3-alt3.1.src.rpm)
> имела именно такую не строгую зависимость:
> 
> Requires: %name-data = %version
> 
> >> Это теперь не законно? :)
> >
> > rpmbuild просто поменяет ту зависимость на строгую.
> 
> Я ведь правильно понимаю все эти разговоры:
> что Requires: %name-data = %version
> будет заменен на Requires: %name-data = %version-%release ?

Да, rpmbuild теперь делает это автоматически.


-- 
ldv

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