<?xml version="1.0" encoding="UTF-8" ?>

<bugzilla version="5.2"
          urlbase="https://bugzilla.altlinux.org/"
          
          maintainer="jenya@basealt.ru"
>

    <bug>
          <bug_id>7253</bug_id>
          
          <creation_ts>2005-06-30 17:09:04 +0400</creation_ts>
          <short_desc>findreq fix</short_desc>
          <delta_ts>2007-10-02 22:25:48 +0400</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>4</classification_id>
          <classification>Development</classification>
          <product>Sisyphus</product>
          <component>gtk-doc</component>
          <version>unstable</version>
          <rep_platform>all</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>CLOSED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          <dependson>7139</dependson>
    
    <dependson>7315</dependson>
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Kachalov Anton">mouse</reporter>
          <assigned_to name="Mikhail Zabaluev">mhz</assigned_to>
          <cc>aris</cc>
    
    <cc>ldv</cc>
          
          <qa_contact>qa-sisyphus</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>26693</commentid>
    <comment_count>0</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-06-30 17:09:07 +0400</bug_when>
    <thetext>findreq fix</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>26694</commentid>
    <comment_count>1</comment_count>
      <attachid>962</attachid>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-06-30 17:11:08 +0400</bug_when>
    <thetext>Created attachment 962
findreq fix</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>26695</commentid>
    <comment_count>2</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-06-30 17:24:48 +0400</bug_when>
    <thetext>вдогонку про arch/noarch.
в этом пакете есть gtk-doc.pc.
pkgconfig живёт в разных директориях на i586 и x86_64 ввиду того, что .pc-файлы
зачастую архитектурно-зависимые (содержат специфичные опции линковки).
что делать?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>26949</commentid>
    <comment_count>3</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-07 09:24:58 +0400</bug_when>
    <thetext>(In reply to comment #2)
&gt; что делать?

См. bug #7139</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>26956</commentid>
    <comment_count>4</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-07-07 11:03:33 +0400</bug_when>
    <thetext>Не, ты не понял. Тут всё хуже. Дело в том, что каким-то волшебным образом, в
gtk-doc есть файл pkgconfig, который в других пакетах arch-зависимый из-за
возможных специфических параметров линковки и т.д. Поэтому, %_pkgconfigdir
разворачивается в %_libdir/pkgconfig.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27010</commentid>
    <comment_count>5</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-07 23:05:52 +0400</bug_when>
    <thetext>Вопрос тот же: нахрена в noarch-пакете %_lib раскрывается в lib64 в зависимости
от --target ? У него же BuildArch: noarch, все target&apos;ы при этом должны
приводиться в noarch и макросы разворачиваются уже оттуда.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27013</commentid>
    <comment_count>6</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-07-08 00:37:29 +0400</bug_when>
    <thetext>опять-двадцать пять.
речь сейчас о том, что в пакете gtk-doc есть файл, который по определению бывает
arch-зависимым. в разные дистрах вставляют разные костыли на эту тему. некоторые
патчах pkgconfig, чтобы тот смотрел и в /usr/lib/pkgconfig, и в
/usr/lib64/pkgconfig. некоторые просто фиксят rpm-post-скриптами pc-файлы так,
чтобы там не было ни одного упоминания про %_libdir, %_x11libdir и т.д.

rpm Vs. noarch -- это отдельная тема. Не говоря уже про pkgconfig.
А gtk-doc, как я уже сказал, зафиксить нетрудно -- было бы желание. А судя по
реакции его нет. Разве не так? Мне уже хватило баданий с xml-commons.
я не отрицаю проблем с rpm, но где их нет? А заниматься перекидыванием стрелок
-- так мы ничего никогда не решим и не сделаем.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27014</commentid>
    <comment_count>7</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-08 00:45:25 +0400</bug_when>
    <thetext>(In reply to comment #6)
&gt; речь сейчас о том, что в пакете gtk-doc есть файл, который по определению бывает
&gt; arch-зависимым.

Не понимаю, что значит &quot;по определению&quot;. Если пакет noarch, какая может быть
arch-зависимость?

&gt; rpm Vs. noarch -- это отдельная тема. Не говоря уже про pkgconfig.
&gt; А gtk-doc, как я уже сказал, зафиксить нетрудно -- было бы желание.

Огласите список всех noarch-пакетов, которые держат что-либо в /usr/lib и
которые нужно фиксить из-за просчета в системе макросов rpm. Просто лучше сразу
оценить все трудозатраты.

Может, ExclusiveArch: noarch как-нибудь поможет? Можно как-то ограничить выбор
--target?
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27015</commentid>
    <comment_count>8</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-07-08 01:13:36 +0400</bug_when>
    <thetext>(In reply to comment #7)
&gt; Не понимаю, что значит &quot;по определению&quot;. Если пакет noarch, какая может быть
&gt; arch-зависимость?
Вспоминаем xml-commons... вспомнился? о чём там шла речь? Чем всё закончилось?
Да, он стал полноценным noarch, но уже без %_libdir. Со всеми вытекающими.
По определению - это значит, что данный файл _будет_ различаться при сборке
пакета на _разных_ архитектурах. А то, что ему кто-то проставил noarch ещё ни о
чём не говорит. Я могу и на glibc noarch поставить. Легче от этого станет?

&gt; Огласите список всех noarch-пакетов, которые держат что-либо в /usr/lib и
&gt; которые нужно фиксить из-за просчета в системе макросов rpm. Просто лучше сразу
&gt; оценить все трудозатраты.
Я собираюсь зарядить на пересборку все noarch-пакеты на выходных. Тогда и будет
список того, что возможно не noarch. Критерия два: собираемость (с учётом
удовлетворённых зависимостей) и идентичность вновь собранных на x86_64 с
&quot;эталонными&quot; в Сизифе. Я тут уже натыкался на пакеты, которые не желают без
каких-либо видимых причин собираться под x86_64.

&gt; Может, ExclusiveArch: noarch как-нибудь поможет? Можно как-то ограничить выбор
&gt; --target?
А что это изменит? Посмотрите, что из себя представляет /usr/lib/noarch-* - это
симлинк на arch.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27029</commentid>
    <comment_count>9</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-08 10:36:55 +0400</bug_when>
    <thetext>(In reply to comment #8)
&gt; Вспоминаем xml-commons... вспомнился? о чём там шла речь? Чем всё закончилось?
&gt; Да, он стал полноценным noarch, но уже без %_libdir.

Там все было проще: расположением файлов я могу всецело управлять.
Файлы для pkgconfig по конвенции должны быть в @libdir@/pkgconfig и с этим
ничего не сделать.

&gt; По определению - это значит, что данный файл _будет_ различаться при сборке
&gt; пакета на _разных_ архитектурах. А то, что ему кто-то проставил noarch ещё ни о
&gt; чём не говорит.

И как конкретно будет различаться этот файл для gtk-doc?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27034</commentid>
    <comment_count>10</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-07-08 11:43:46 +0400</bug_when>
    <thetext>(In reply to comment #9)
&gt; Там все было проще: расположением файлов я могу всецело управлять.
&gt; Файлы для pkgconfig по конвенции должны быть в @libdir@/pkgconfig и с этим
&gt; ничего не сделать.
А что должно быть для noarch? Если сам pkgconfig ищет именно в
@libdir@/pkgconfig. Но при этом @libdir@ различен для arch/noarch?

&gt; И как конкретно будет различаться этот файл для gtk-doc?
Я говорил про pc-файлы в целом. Посмотрите на файл
/usr/lib/pkgconfig/glib-2.0.pc для примера. Можно было бы и вырезать libdir, а
при работе pkgconfig его подставлять, но вот Cflags имеет право быть завязанным
на архитектуру. Хотя, я пока таких не встречал.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27036</commentid>
    <comment_count>11</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-08 12:03:24 +0400</bug_when>
    <thetext>(In reply to comment #10)
&gt; А что должно быть для noarch? Если сам pkgconfig ищет именно в
&gt; @libdir@/pkgconfig. Но при этом @libdir@ различен для arch/noarch?

Угу. Для noarch он должен раскрываться в lib _без_вариантов_.

&gt; &gt; И как конкретно будет различаться этот файл для gtk-doc?
&gt; Я говорил про pc-файлы в целом.

В целом по больнице неинтересно. pkgconfig для архитектурно-независимых пакетов
различаться заведомо не может. Загляните в gtk-doc.pc</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27037</commentid>
    <comment_count>12</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-07-08 12:25:23 +0400</bug_when>
    <thetext>(In reply to comment #11)
&gt; Угу. Для noarch он должен раскрываться в lib _без_вариантов_.
...
&gt; В целом по больнице неинтересно. pkgconfig для архитектурно-независимых пакетов
&gt; различаться заведомо не может. Загляните в gtk-doc.pc
У вас есть уже готовые предложения по _правильному_ поведению pkgconfig?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27050</commentid>
    <comment_count>13</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-08 15:13:56 +0400</bug_when>
    <thetext>(In reply to comment #12)
&gt; У вас есть уже готовые предложения по _правильному_ поведению pkgconfig?

К pkgconfig никаких претензий нет: если он ищет свои файлы в пути
/usr/lib/pkgconfig:/usr/lib64/pkgconfig, пускай себе.

Все претензии к макросам rpm, по которым конфигурация noarch пакета меняется в
зависимости от параметра --target, что есть полнейший нонсенс.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>27728</commentid>
    <comment_count>14</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-07-26 10:35:22 +0400</bug_when>
    <thetext>Fixed in 1.4-alt1

Сделал проще: фальшивый Provides: perl(gtkdoc-common.pl)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>30340</commentid>
    <comment_count>15</comment_count>
    <who name="Mikhail Zabaluev">mhz</who>
    <bug_when>2005-09-10 17:10:41 +0400</bug_when>
    <thetext>Вдогонку по pkg-config: gtk-doc-1.4-alt2 помещает .pc в /usr/share/pkgconfig.
Новый pkg-config умеет там искать.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>30359</commentid>
    <comment_count>16</comment_count>
    <who name="Dmitry V. Levin">ldv</who>
    <bug_when>2005-09-10 20:11:41 +0400</bug_when>
    <thetext>В догонку про pkgconfig: что будет с %_pkgconfigdir?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>30360</commentid>
    <comment_count>17</comment_count>
    <who name="Kachalov Anton">mouse</who>
    <bug_when>2005-09-10 20:21:53 +0400</bug_when>
    <thetext>Народ в devel@ это уже обсудил.
Т.ч.это ещё один повод собрать rpm с нормальным noarch... Ток нужно ещё
зафиксить, чтоб rpm подсасывал нужные макросы при выставлени в спеке BuildArch,
оверрайдя --target</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>962</attachid>
            <date>2005-06-30 17:11:08 +0400</date>
            <delta_ts>2005-06-30 17:11:08 +0400</delta_ts>
            <desc>findreq fix</desc>
            <filename>gtk-doc.tar.bz2</filename>
            <type>application/octet-stream</type>
            <size>1066</size>
            <attacher name="Kachalov Anton">mouse</attacher>
            
              <data encoding="base64">QlpoOTFBWSZTWfL0HNYAAmR/hM2wAIB+//+//v//Wv////4IAQAIUAO+m7TkxagUBqaEAmp5Tamm
0mTQGQeUwnqAGT1GajQADGp6mIEVH6o0yAANGjQNADQAaNpAAAAAABpogBJNqT9U9IzUBo2o0bUM
gNAPUAaDQABkHMmmhkADEZBkANMEDEA0aaADIGgASRRk0CU9kQxMTJPVPTSeU9GQ01NB6g2hqAeo
AYTynqXd93Xm3TVbQqEhPJJCIaR4i1MTvr1a7qBY0wACwjLv7mwKTsZ8ljBsutEy/adrhtVCcPEc
IC/vC6lZpp5ucKb6MLHlRtvR8Oa1QqmZMwDNGxxZT4ioqmcEx5+1XARKUGqBpylBucge2aWwQanK
wEtuBkk8hHQskDjTVQsyhfk5CC5HSZ4msUS6yCptOX858Ne8ZyG9R0HiZp6ZbANK1MevQbNYRnXo
NVsWxBmqNrY8lBKTrY5LyFTWxCREcf1TeScwICmUJCowd+lI+O00B8UaxTfVQSpYIQ3Uzbu02dnY
4SRcFXB4aREjSYuHOH8QB4WuXMHvgXl/upVBbk6krcBmF4AyMcXR3pTzRHm6ZZ7jGdC5mLpi+ZP1
Ot9AwvTAX2AxTogLszSUVvVtFI9HLTM7W6Fomjz37rNZhrslAnBwMCg8WeL+mFTa7Qw3hOc0jdgq
jTEJQvyGzIZaQ9cXhIoQ4EYBZBWlNYeBBc1yo6WJ6oYXTIYVKFwj2XO1uHd4o5YN86za7M5R4Lxb
B+nmUNEJAAcCyArVQBARpSGuWC98X0hQgZIIoBMgKAoWJUBF44lmuMKYQqEW4Nx4KfRIJczR5wKa
VxE/QbBxYTvkMrjmLsZMrl6pP2ztk+sCrC7WiGlkWXNGLoHz0ToRcYCAJ4Rv6WxE5ZVEyAoIRT5T
K9woQ2rEV4WPKUqnPFyzIn4a6yHZArOsZK0KbRXtO0dufC8ceNUGQF8BIOcFcqHvJXce6RzjsfSz
mSdrAORIobrpNgV1KnK+3BSpMGDo9mq/w27WfDn0fXl9CKjXNSM/FKYJVVFzTqcsckzNvfh3bDc3
mG1tRc+dMdGvu0GjFTh+fg3gxoLWUeFwmKhkXFVckpH5DZKEGVjLc0xVgrNg0R4iOpjOsA+LTYa4
lcWBkxY1jV2OnuXb7sRNcFAcy7VRbCqhwtZJm3yEJ0wzqdyabb4x0ckDjMt+RIzMFL1rUEsml1jG
YYn0wJS0hYchb0laUcT3vtZUvt9TUGrsUb6IgoheAQrUgHJszkI5JiOiAlxrDUn4t87yVRkpUdf0
7Jwx3OqTcf9WRwNtCiDG7IpvNhMoBbdfgqaZqsAZVTMo/HBXn0WQLGDcSIkqB+HisNl8O5bMiWZd
/n0WsgbNxLLcNni3C24MSINh38U+HFj5SSfjAD/xdyRThQkPL0HNYA==
</data>

          </attachment>
      

    </bug>

</bugzilla>