(In reply to comment #0)
> т.е. никаких пакетов, обносящихся к apache1, нет.
> некоему приложению под mod_perl2 требуется модуль perl-Apache-DBI.
> 
> но при попытке его установить происходит такое:
> The following extra packages will be installed:
>   apache-common apache-mod_perl libmm perl-B-Graph perl-BSD-Resource
> perl-Devel-Symdump
> 
> т.е. он, хотя мог бы работать с apache2/mod_perl2, он тащит за собой apache1.
> 
> предлагаю либо вообще отвязать его от apache (кто его ставит - знает что делает,

Это возможное решение.

> и apache он поставит/л и самостоятельно) либо собрать второй пакет
> perl-Apache2-DBI, который будет тянуть с собой apache2 ;)

"Тянет" apache1 на самом деле скрипт генерации зависимостей rpm (в данном случае
perl.req). В самом коде Apache-DBI есть условная run-time загрузка модулей
(require) в зависимости от того, какой MOD_PERL_API_VERSION был обнаружен. То
есть, от того работаем ли мы с mod_perl для apache1 или apache2:

use constant MP2 => (exists $ENV{MOD_PERL_API_VERSION}
    && $ENV{MOD_PERL_API_VERSION} == 2) ? 1 : 0;

BEGIN {
  my @constants = qw( OK AUTH_REQUIRED FORBIDDEN DECLINED SERVER_ERROR );
  if (MP2) {
                require Apache2::Access;
    require Apache2::Const;
    import Apache2::Const @constants;
  }
  else {
    require Apache::Constants;
    import Apache::Constants @constants;
  }
}

Ближнесрочным решением мне видится релаксация зависимостей perl-Apache-DBI, как
Вы и предлагаете. В дальнейшем, чтобы все-таки отразить требование любого из
mod_perl, можно вручную прописать требование виртуального провайда,
предоставляемого и apache-mod_perl и apache2-mod_perl.

хех. то есть сейчас он будет требовать оба одновременно, получается, что бы ни
стояло. как-то это неправильно ;)

чтобы выполнить среднесрочную перспективу надо договориться с маинтейнерами
apache*-mod_perl, чтобы они проставили у себя.

ну а пока, может, пришлете мне модуль без зависимостей? ;)

(In reply to comment #2)
> хех. то есть сейчас он будет требовать оба одновременно, получается, что бы ни
> стояло. как-то это неправильно ;)

Нет, конечно. Из чего Вы делаете такой вывод?

> чтобы выполнить среднесрочную перспективу надо договориться с маинтейнерами
> apache*-mod_perl, чтобы они проставили у себя.

Да.
 
> ну а пока, может, пришлете мне модуль без зависимостей? ;)
 
Он уже в сизифе: perl-Apache-DBI-1.06-alt2

(In reply to comment #1)
> В дальнейшем, чтобы все-таки отразить требование любого из
> mod_perl, можно вручную прописать требование виртуального провайда,
> предоставляемого и apache-mod_perl и apache2-mod_perl.
Ну я не против.

спасибо, Виктор. поставил сейчас из сизифа таким образом:

The following NEW packages will be installed:
  perl-Apache-DBI
0 upgraded, 1 newly installed, 0 removed and 733 not upgraded.
Need to get 48.7kB of archives.
After unpacking 132kB of additional disk space will be used.
Get:1 ftp://ftp.altlinux.org noarch/classic perl-Apache-DBI 1.06-alt2 [48.7kB]
Fetched 48.7kB in 1s (38.5kB/s)

без зависимостей ;)

а что не реагирует naf@ ?
написал ему ;)

> а что не реагирует naf@ ?
А я внимательно читаю. Единственный вопрос, который вроде бы остался - это имя  
виртуального провайда. mod_perl-general ?

(In reply to comment #6)
> А я внимательно читаю. Единственный вопрос, который вроде бы остался - это имя  
> виртуального провайда. mod_perl-general ?

Не очень как-то красиво... Поскольку у нас имена пакетов с mod_perl префиксуются
указанием апача (apache-mod_perl, apache2-mod_perl), то почему бы виртуальный
провайд не назвать просто mod_perl

(In reply to comment #7)
> то почему бы виртуальный провайд не назвать просто mod_perl

Тем более что я его и так уже провайдю:
%package mod_perl
# ...
Provides: mod_perl = %mod_perl_version
;-)