[devel] О ранижировании пакетов

[devel] О ранижировании пакетов

[Денис Смирнов]

Таки написал я код для ранжирования пакетов по важности и автоматического
выявления наиболее требующих внимания участков.

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

Соответственно у меня вопрос -- какие пакеты мы должны считать наиболее
важными _без учета зависимостей_? То есть, скажем, с этой точки зрения
glibс не важный пакет -- сам по себе он никому не нужен, а, скажем,
какой-нибудь bc может быть для кого-то один из самых важных пакетов, так
как его использует какой-нибудь ОченьВажныйСкрипт.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
С миру по ячейке - программисту банк данных.

[devel] Re: О ранижировании пакетов

[Michael Shigorin]

On Sun, Jan 29, 2006 at 04:46:20PM +0300, Денис Смирнов wrote:
> Соответственно у меня вопрос -- какие пакеты мы должны считать
> наиболее важными _без учета зависимостей_?

Ммм... /etc/apt/pkgpriorities тебя явно не удовлетворит...
но, может, за основу /etc/buildreqs/packages/essential сгодится?

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

Re: [devel] Re: О ранижировании пакетов

[Денис Смирнов]

On Mon, Jan 30, 2006 at 11:37:28AM +0200, Michael Shigorin wrote:

MS> Ммм... /etc/apt/pkgpriorities тебя явно не удовлетворит...
MS> но, может, за основу /etc/buildreqs/packages/essential сгодится?

Не, это именно базовые для сборочных зависимостей. А мне нужны базовые для
пользователя. Скажем glibc тебе нафиг не нужен. И zlib тоже. А вот mutt
очень даже нужен, и лично для тебя его ценность много больше ценности
glibc, которая "случайно" тянется по зависимостям.

Собственно задача как раз и выцепить автоматически важные для QA-пакеты,
зная ценные. Скажем для меня наиболее критичными для бизнеса являются
сейчас:

asterisk-full
openssh
postfix
nginx
iptables
... и некоторые перловые пакеты

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> > >Как добиться сборки с gcc3.4?
> > select-gcc 3.4
> В hasher? Каким образом?
%set_gcc_version
		-- inger in devel@

[devel] Re: О ранижировании пакетов

[Michael Shigorin]

On Mon, Jan 30, 2006 at 03:01:14PM +0300, Денис Смирнов wrote:
> Не, это именно базовые для сборочных зависимостей. А мне нужны
> базовые для пользователя.

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

> Собственно задача как раз и выцепить автоматически важные для
> QA-пакеты, зная ценные. Скажем для меня наиболее критичными для
> бизнеса являются сейчас:
> 
> asterisk-full
> openssh
> postfix
> nginx
> iptables
> ... и некоторые перловые пакеты

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

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

Re: [devel] Re: О ранижировании пакетов

[Денис Смирнов]

On Mon, Jan 30, 2006 at 04:28:44PM +0200, Michael Shigorin wrote:
>> Не, это именно базовые для сборочных зависимостей. А мне нужны
>> базовые для пользователя.
MS> Ну да; так а сколько пользователей, столько и наборов выйдет.

Именно.

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

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

Пока скрипты написаны ТАК, что я их сам смотреть боюсь. Как будет
работоспособно -- вывалю. Пока, для экспериментов, мне нужно несколько
наборов данных, вот их я и пытаюсь собрать.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
а может ну её вообще, эту jfs ?
неславная она какая-то.
		-- sbolshakov in #7039

[devel] Re: Re: О ранижировании пакетов

[Anton Farygin]

On Mon, 30 Jan 2006 15:01:14 +0300, Денис Смирнов wrote:

> On Mon, Jan 30, 2006 at 11:37:28AM +0200, Michael Shigorin wrote:
> 
> MS> Ммм... /etc/apt/pkgpriorities тебя явно не
> удовлетворит... MS> но, может, за основу
> /etc/buildreqs/packages/essential сгодится?
> 
> Не, это именно базовые для сборочных
> зависимостей. А мне нужны базовые для
> пользователя. Скажем glibc тебе нафиг не
> нужен. И zlib тоже. А вот mutt очень даже
> нужен, и лично для тебя его ценность
> много больше ценности glibc, которая
> "случайно" тянется по зависимостям.
> 
> Собственно задача как раз и выцепить
> автоматически важные для QA-пакеты, зная
> ценные. Скажем для меня наиболее
> критичными для бизнеса являются сейчас:
> 
> asterisk-full
> openssh
> postfix
> nginx
> iptables
> ... и некоторые перловые пакеты

А для меня - всё что уложилось в Compact-3.0 на один CD ;-)

У меня даже список есть, но он большой. А смысл это делать ?

Rgds,
Rider

[devel] Re: О ранижировании пакетов

[Michael Shigorin]

On Tue, Jan 31, 2006 at 04:53:52PM +0300, Anton Farygin wrote:
> У меня даже список есть, но он большой. А смысл это делать ?

Чтоб была надёжная кофейная гуща для предсказаний, что ещё
из нужного может отвалиться, если цепануть во-он тот маленький
пакетик? :)

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

Тебе, в принципе, может быть полезно при планировании выпуска,
но тут не знаю.

-- 
Миша,
слушая, как хрустит
собирающийся без libdb4 openldap

[devel] Re: О ранижировании пакетов

[Anton Farygin]

On Tue, 31 Jan 2006 16:41:13 +0200, Michael Shigorin wrote:

> On Tue, Jan 31, 2006 at 04:53:52PM +0300, Anton Farygin wrote:
>> У меня даже список есть, но он большой. А
>> смысл это делать ?
> 
> Чтоб была надёжная кофейная гуща для
> предсказаний, что ещё из нужного может
> отвалиться, если цепануть во-он тот
> маленький пакетик? :)
> 
> Насколько понимаю, тем, кто поддерживает
> сервисы наверху приличной стопки
> библиотек и других сервисов, при этом
> умудряется делать это всё на сизифе --
> актуально.  Вот вроде Дениса.
> 
> Тебе, в принципе, может быть полезно при
> планировании выпуска, но тут не знаю.

Дело в том, что для меня оптимально
непрерывно отслеживать состояние Sisyphus,
например путём еженедельной сборки livecd/installer.

Вот сейчас я знаю, что собрать таковой не
смогу, ибо install3 несколько поломан.

Rgds,
Rider

Re: [devel] Re: О ранижировании пакетов

[Денис Смирнов]

On Wed, Feb 01, 2006 at 10:41:54AM +0300, Anton Farygin wrote:

AF> Дело в том, что для меня оптимально
AF> непрерывно отслеживать состояние Sisyphus,
AF> например путём еженедельной сборки livecd/installer.

Ты отслеживаешь состояние всех багов на все пакеты, содержащиеся в
репозитории? 

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[devel] Re: Re: О ранижировании пакетов

[Anton Farygin]

On Wed, 01 Feb 2006 12:45:37 +0300, Денис Смирнов wrote:

> On Wed, Feb 01, 2006 at 10:41:54AM +0300, Anton Farygin wrote:
> 
> AF> Дело в том, что для меня оптимально AF>
> непрерывно отслеживать состояние Sisyphus,
> AF> например путём еженедельной сборки
> livecd/installer.
> 
> Ты отслеживаешь состояние всех багов на
> все пакеты, содержащиеся в репозитории?

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

Rgds,
Rider

Re: [devel] Re: Re: О ранижировании пакетов

[Денис Смирнов]

On Wed, Feb 01, 2006 at 02:03:51PM +0300, Anton Farygin wrote:

AF> Я получаю уведомления по почте об этих
AF> багах. Т.е. - можно сказать что
AF> отслеживаю. Но смотрю только за теми, которые мне сильно актуальны ;)

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Т.к. Compact уже выпущен, то все что не успели исправить - ошибками
не считается.
		-- rider in #3005

[devel] Re: Re: Re: О ранижировании пакетов

[Anton Farygin]

On Wed, 01 Feb 2006 16:20:43 +0300, Денис Смирнов wrote:

> On Wed, Feb 01, 2006 at 02:03:51PM +0300, Anton Farygin wrote:
> 
> AF> Я получаю уведомления по почте об этих
> AF> багах. Т.е. - можно сказать что AF>
> отслеживаю. Но смотрю только за теми,
> которые мне сильно актуальны ;)
> 
> Вот задача как раз в том, чтобы быстро
> получить _автоматически_ список из
> десятка-другого багов, ранжированых по
> важности для конкретного пользователя
> или разработчика, с учётом его текущей
> рабочей задачи. Скажем сейчас я работаю
> над астериском -- и хочу быстро получить
> список всех багов, которые наиболее
> заметно влияют на меня. Часто, когда это
> системообразующие пакеты -- я о них знаю.
> Иногда же могу не знать или забыть
> (скажем зависимость астериска на libgsm
> появилась совсем недавно).

Ну так это же скриптуется.. ;-)

При чём на локальной машине.

Rgds,
Rider

Re: [devel] Re: Re: Re: О ранижировании пакетов

[Денис Смирнов]

On Wed, Feb 01, 2006 at 04:29:43PM +0300, Anton Farygin wrote:

AF> Ну так это же скриптуется.. ;-)
AF> При чём на локальной машине.

Да. А хождение по цепочке зависимостей с выявлением наиболее критичных
тоже скриптуется? ;-)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> alias char-major-10-134 fglrx
сурово. Это надо в фортунки ;)
		-- lakostis in community@

[devel] Re: Re: Re: Re: О ранижировании пакетов

[Anton Farygin]

On Wed, 01 Feb 2006 17:59:03 +0300, Денис Смирнов wrote:

> On Wed, Feb 01, 2006 at 04:29:43PM +0300, Anton Farygin wrote:
> 
> AF> Ну так это же скриптуется.. ;-) AF> При чём
> на локальной машине.
> 
> Да. А хождение по цепочке зависимостей с
> выявлением наиболее критичных тоже
> скриптуется? ;-)

Конечно.

Тем более что считать надо не исходные пакеты, а бинарные.

Rgds,
Rider

Re: [devel] О ранижировании пакетов

[Alexey Tourbin]

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

On Sun, Jan 29, 2006 at 04:46:20PM +0300, Денис Смирнов wrote:
> Таки написал я код для ранжирования пакетов по важности и автоматического
> выявления наиболее требующих внимания участков.
> 
> Проблема в том, что сейчас я подразумеваю одинаковую важность всех пакетов
> изначально, что явно не соответствует действительности.
> 
> Соответственно у меня вопрос -- какие пакеты мы должны считать наиболее
> важными _без учета зависимостей_? То есть, скажем, с этой точки зрения
> glibс не важный пакет -- сам по себе он никому не нужен, а, скажем,
> какой-нибудь bc может быть для кого-то один из самых важных пакетов, так
> как его использует какой-нибудь ОченьВажныйСкрипт.
> 
> Сейчас я могу легко получить список пакетов, требующих внимания, по своему
> списку используемых в работе пакетов.

Я тоже думал над этой задачей.  Что касается сборочных зависимостей, то,
оказывается, существует неожиданное решение: список установленных
пакетов можно извлечь из лога пересборки.  Поскольку логи пересборки
репозитария существуют, остается только сосчитать пакеты, которые встают
в чрут (в логах указаны все пакеты, которые встают в чрут, за вычетом
базовой сборочной среды, т.е. basesystem+rpm-build; последнее
обстоятельство можно рассматривать и как преимущество).

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

buildlog_uris()
{
	find "$@" -type f -print0 |xargs -r0 gzip -cdfq |
		awk '/^Preparing packages for installation/,/^Installing .*[.]src[.]rpm$/ {
			if (/^[[:alnum:]][[:graph:]]*[[:alnum:]]-(alt|ipl)[[:graph:]]*$/ && !/[.]rpm$/)
				print }' |sort |uniq -c |awk '{print $1 "\t" $2 }' |sort -n
}

(Название функции buildlog_uris интуитивно не понятно, потому что эта
функция используется в рамках решения другой задачи.)

[at@basalt ~]$ buildlog_uris /raid/beehive/success |tail -33
934     libfreetype-devel-2.2.1-alt2
938     libXaw-1.0.2-alt1
940     libxml2-2.6.23-alt2
940     xml-common-0.6.3-alt11
974     libXp-1.0.0-alt3
985     libXmu-1.0.1-alt1
1013    libXinerama-1.0.1-alt3
1049    libjpeg-6b-alt7
1054    libXcursor-1.1.6-alt1
1056    libXrandr-1.1.1-alt1
1059    libXfixes-4.0-alt2
1071    libX11-devel-1.0.0-alt6
1072    libXau-devel-1.0.1-alt1
1073    libXdmcp-devel-1.0.1-alt1
1075    libXft-2.1.8.2-alt5
1078    libXi-1.0.1-alt1
1086    libXpm-3.5.5-alt1
1092    libXt-1.0.2-alt1
1093    libXrender-0.9.1-alt1
1139    libssl-0.9.7g-alt3
1145    libSM-1.0.1-alt1
1149    xorg-x11-proto-devel-7.1.0-alt1
1150    libICE-1.0.1-alt1
1219    zlib-devel-1.2.3-alt3
1230    libXext-1.0.0-alt4
1335    libpng3-1.2.8-alt3
1349    fontconfig-2.3.2-alt8
1399    libfreetype-2.2.1-alt2
1463    libexpat-2.0.0-alt3.1
1539    libX11-1.0.0-alt6
1541    libXdmcp-1.0.1-alt1
1619    libstdc++4.1-4.1.1-alt1
1660    libXau-1.0.1-alt1
[at@basalt ~]$ 

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

Поскольку логи сборки содержат результаты find-requires, то становится
также возможным произвести взвешенное иерархическое ранжирование
реальных (а не сборочных) зависимостей.  Это несколько сложнее, но не
намного (основная проблема состоит в том, чтоб отмаппить виртуальные
пакеты в реальные).  Поскольку я сейчас хочу выпить пива, я не буду до
конца показывать, как это сделать... Ж)  Суть опять же в том, что
специально делать ничего не нужно.

buildlog_deps()
{
	find "$@" -type f -print0 |xargs -r0 gzip -cdfq |
		awk  -F'[:,] +' '/^Processing files:/ { pkg = $NF }
			/^PreReq:|^Requires([(].+[)])?:|^Provides:|^Obsoletes:/ {
				if (pkg) for(i=2;i<=NF;i++) print pkg "\t" $1 "\t" $i }' |sort -u
}

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

Re: [devel] О ранижировании пакетов

[Alexey Tourbin]

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

On Fri, Jun 02, 2006 at 07:07:08AM +0400, Alexey Tourbin wrote:
> > Соответственно у меня вопрос -- какие пакеты мы должны считать наиболее
> > важными _без учета зависимостей_? То есть, скажем, с этой точки зрения

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

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

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

Re: [devel] О ранжировании пакетов

[Slava Semushin]

--- Alexey Tourbin 2006-06-02 07:07:08 +0400
+++ Vyacheslav Semushin 2006-06-02 10:47:38 +0700

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

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

    1) в BuildRequires могут попадать пакеты, которые _вообще_ не нужны
       для сборки. Такие случаи есть и их не так уж и мало.

    2) в отдельный случай я хотел бы выделить зависимости на виртуальные
       пакеты. В частности, раньше иксы были не модульными и для многих
       чисто иксовых программ было достаточно прописать xorg-x11-devel (а
       ещё раньше XFree86-devel AFAIR). С приходом модульного Xorg7 иксы
       разделились на отдельные пакеты, а xorg-x11-devel стал виртуальным
       пакетом, который вытягивает за собой не меньше десятка отдельных
       пакетов. Ситуация такая, что очень многие мэйнтейнеры то ли из-за
       нехватки времени, то ли по ленности своей не стали изменять
       BuildRequires, а оставили xorg-x11-devel, т.к. с ним всё равно
       пакеты собираются и работают. Соответственно у очень многих
       пакетов, как я думаю, в chroot ставятся пакеты которые вытягивает
       xorg-x11-devel, но при этом программа их реально не использует.

       Ваши результаты IMHO это лишь подтверждают:

AT> [at@basalt ~]$ buildlog_uris /raid/beehive/success |tail -33
AT> 934     libfreetype-devel-2.2.1-alt2
AT> 938     libXaw-1.0.2-alt1
AT> 940     libxml2-2.6.23-alt2
AT> 940     xml-common-0.6.3-alt11
AT> 974     libXp-1.0.0-alt3
AT> 985     libXmu-1.0.1-alt1
AT> 1013    libXinerama-1.0.1-alt3
AT> 1049    libjpeg-6b-alt7
AT> 1054    libXcursor-1.1.6-alt1
AT> 1056    libXrandr-1.1.1-alt1
AT> 1059    libXfixes-4.0-alt2
AT> 1071    libX11-devel-1.0.0-alt6
AT> 1072    libXau-devel-1.0.1-alt1
AT> 1073    libXdmcp-devel-1.0.1-alt1
AT> 1075    libXft-2.1.8.2-alt5
AT> 1078    libXi-1.0.1-alt1
AT> 1086    libXpm-3.5.5-alt1
AT> 1092    libXt-1.0.2-alt1
AT> 1093    libXrender-0.9.1-alt1
AT> 1139    libssl-0.9.7g-alt3
AT> 1145    libSM-1.0.1-alt1
AT> 1149    xorg-x11-proto-devel-7.1.0-alt1
AT> 1150    libICE-1.0.1-alt1
AT> 1219    zlib-devel-1.2.3-alt3
AT> 1230    libXext-1.0.0-alt4
AT> 1335    libpng3-1.2.8-alt3
AT> 1349    fontconfig-2.3.2-alt8
AT> 1399    libfreetype-2.2.1-alt2
AT> 1463    libexpat-2.0.0-alt3.1
AT> 1539    libX11-1.0.0-alt6
AT> 1541    libXdmcp-1.0.1-alt1
AT> 1619    libstdc++4.1-4.1.1-alt1
AT> 1660    libXau-1.0.1-alt1
AT> [at@basalt ~]$ 

    БОльшая часть из этих пакетов как раз являются теми частями бывшего
    когда-то единым xorg-x11-devel. А то что libXau является более
    востребованной чем даже libstdc++ вообще удивительно :)

    Я с этим уже давно столкнулся при сборке программы требующей
    glib-devel, которая в свою очередь при сборке требовала
    xorg-x11-devel. Я даже предлагал убрать эту зависимость, но ldv@
    сказал что пусть так и будет. Поэтому программа (wmclockmon кажется) в
    Сизиф так и не попала.

-- 
+ Slava Semushin | php-coder @ ngs.ru
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] О ранжировании пакетов

[Alexey Tourbin]

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

On Fri, Jun 02, 2006 at 11:06:37AM +0700, Slava Semushin wrote:
> AT> То есть для взвешенного иерархического ранжирования сборочных зависимостей
> AT> ничего специально делать не нужно, и наиболее "трудным" моментом в этой задаче
> AT> было как раз осознать, что специально ничего делать не нужно.
> 
>     Признаться результаты кажутся мне несколько завышенными. Их проблема в
>     том, что они основываются на BuildRequires, которые прописываются
>     мэйнтейнерами и следовательно могут врать. В частности есть две

То есть мы сталкиваемся с тем, что мэйнтейнеры могут врать.
Увы, поэты много врут.  Это не новость.

>     1) в BuildRequires могут попадать пакеты, которые _вообще_ не нужны
>        для сборки. Такие случаи есть и их не так уж и мало.

С другой стороны, если пакет из BuildRequires не удается установить,
тогда соответствующий пакет нельзя собрать.  Ви знайете что такое \sup и \inf?
В случае с BuildRequires речь идёт о \sup.  В случае Requires получаем \inf.

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

>     2) в отдельный случай я хотел бы выделить зависимости на виртуальные
>        пакеты. В частности, раньше иксы были не модульными и для многих
>        чисто иксовых программ было достаточно прописать xorg-x11-devel (а
>        ещё раньше XFree86-devel AFAIR). С приходом модульного Xorg7 иксы
>        разделились на отдельные пакеты, а xorg-x11-devel стал виртуальным
>        пакетом, который вытягивает за собой не меньше десятка отдельных
>        пакетов. Ситуация такая, что очень многие мэйнтейнеры то ли из-за
>        нехватки времени, то ли по ленности своей не стали изменять
>        BuildRequires, а оставили xorg-x11-devel, т.к. с ним всё равно
>        пакеты собираются и работают. Соответственно у очень многих
>        пакетов, как я думаю, в chroot ставятся пакеты которые вытягивает
>        xorg-x11-devel, но при этом программа их реально не использует.
> 
>        Ваши результаты IMHO это лишь подтверждают:
> 
> AT> [at@basalt ~]$ buildlog_uris /raid/beehive/success |tail -33
> AT> 934     libfreetype-devel-2.2.1-alt2
> AT> 938     libXaw-1.0.2-alt1
> AT> 940     libxml2-2.6.23-alt2
> AT> 940     xml-common-0.6.3-alt11
> AT> 974     libXp-1.0.0-alt3
> AT> 985     libXmu-1.0.1-alt1
> AT> 1013    libXinerama-1.0.1-alt3
> AT> 1049    libjpeg-6b-alt7
> AT> 1054    libXcursor-1.1.6-alt1
> AT> 1056    libXrandr-1.1.1-alt1
> AT> 1059    libXfixes-4.0-alt2
> AT> 1071    libX11-devel-1.0.0-alt6
> AT> 1072    libXau-devel-1.0.1-alt1
> AT> 1073    libXdmcp-devel-1.0.1-alt1
> AT> 1075    libXft-2.1.8.2-alt5
> AT> 1078    libXi-1.0.1-alt1
> AT> 1086    libXpm-3.5.5-alt1
> AT> 1092    libXt-1.0.2-alt1
> AT> 1093    libXrender-0.9.1-alt1
> AT> 1139    libssl-0.9.7g-alt3
> AT> 1145    libSM-1.0.1-alt1
> AT> 1149    xorg-x11-proto-devel-7.1.0-alt1
> AT> 1150    libICE-1.0.1-alt1
> AT> 1219    zlib-devel-1.2.3-alt3
> AT> 1230    libXext-1.0.0-alt4
> AT> 1335    libpng3-1.2.8-alt3
> AT> 1349    fontconfig-2.3.2-alt8
> AT> 1399    libfreetype-2.2.1-alt2
> AT> 1463    libexpat-2.0.0-alt3.1
> AT> 1539    libX11-1.0.0-alt6
> AT> 1541    libXdmcp-1.0.1-alt1
> AT> 1619    libstdc++4.1-4.1.1-alt1
> AT> 1660    libXau-1.0.1-alt1
> AT> [at@basalt ~]$ 
> 
>     БОльшая часть из этих пакетов как раз являются теми частями бывшего
>     когда-то единым xorg-x11-devel. А то что libXau является более
>     востребованной чем даже libstdc++ вообще удивительно :)

Да.  Тем не менее это не отменяеть \sup-семантики BuildRequires.

>     Я с этим уже давно столкнулся при сборке программы требующей
>     glib-devel, которая в свою очередь при сборке требовала
>     xorg-x11-devel. Я даже предлагал убрать эту зависимость, но ldv@
>     сказал что пусть так и будет. Поэтому программа (wmclockmon кажется) в
>     Сизиф так и не попала.

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

[devel] [JT] Re: О ранжировании пакетов

[Michael Shigorin]

On Fri, Jun 02, 2006 at 08:39:54AM +0400, Alexey Tourbin wrote:
> > проблема в том, что они основываются на BuildRequires,
> > которые прописываются мэйнтейнерами и следовательно могут
> > врать.
> То есть мы сталкиваемся с тем, что мэйнтейнеры могут врать.

Ты не врёшь, но ошибаешься.

> > 1) в BuildRequires могут попадать пакеты, которые _вообще_ не нужны
> >    для сборки. Такие случаи есть и их не так уж и мало.
> С другой стороны, если пакет из BuildRequires не удается
> установить, тогда соответствующий пакет нельзя собрать.

Бишь не надо смешивать две разных проблемы, даже пересекающихся.

PS: 2 at: спасибо, что добрался снова.

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