From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DNS_FROM_AHBL_RHSBL,RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1457973613; bh=1lhmHMyTPfKooQsuQ9ZRr/5jJIFLxp+at8qUuN2RHZ4=; h=Date:From:To:Subject; b=RvILXLnIlQgidCovfXklJX53sw1m5TN2TSq9FmKWmAZtAli71GDJfK7UvFmpVerNN HgmwIfaTSpnQnSInj8PGyfixOZT9UFqD6rWMaFynPpropWulwM2zrQ587+2KkgCE4T +khkt7DzPYcFWbj+7iv3YQfqrgNIgt2HF1D3015s= X-Virus-Scanned: amavisd-new at imath.kiev.ua DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imath.kiev.ua; s=hydra; t=1457973607; bh=1lhmHMyTPfKooQsuQ9ZRr/5jJIFLxp+at8qUuN2RHZ4=; h=Date:From:To:Subject; b=EigMK+01IxqvaFxLhXVjNpGjfGZCIe61Pyb64j2D7neCtu+5OalKtPtDGT/qUE+ru 8NVe2maRyQBe2fU0cqBadmbxTOVpNce3rE3T8v6zZWsYjm79LWWVi4keS0CZpvafxk YKlTCWH9rfFCGPtKOG+iYcjVCaH7iLNfpOOr7t2k= Date: Mon, 14 Mar 2016 18:40:07 +0200 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20160314164006.GA4046@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Subject: [devel] =?utf-8?b?STog0KPRgtC40LvQuNGC0LAgYnVpbGRyZXEtc3Jj?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 16:40:16 -0000 Archived-At: List-Archive: List-Post: Утилита buildreq-src ____________________ Утилита живет сейчас в пакете perl-RPM-Source-Dependency-Analyzer. Однако так как ранее она уже кочевала из пакета в пакет, ее лучше устанавливать как apt-get install /usr/bin/buildreq-src Утилиту можно использовать как при создании пакета, так и при сопровождении пакета. Создание пакета. _______________ При создании пакета у нас есть только исходники. Их и передадим утилите. Это может быть * архив исходников buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz * каталог с распакованными исходниками buildreq-src ../BUILD/lbreakout2-2.6.5 * или даже отдельные файлы: buildreq-src ../BUILD/lbreakout2-2.6.5/configure.ac Запустим, к примеру, buildreq-src с архивом исходников. $ buildreq-src ../SOURCES/lbreakout2-2.6.5.tar.gz утилита выведет найденные сборочные зависимости: # BEGIN SourceDeps(oneline): BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel libpng-devel zlib-devel # END SourceDeps(oneline) Их можно вручную вставить в spec файл. Однако утилита и сама может сделать это, если ей дать еще и spec файл. Сопровождение пакета. _____________________ Утилита buildreq-src не работает напрямую c src.rpm пакетом. его надо сначала установить: rpm -i ../SRPMS/lbreakout2-2.6.5-alt1.src.rpm В gear git репозитории обычно уже ничего делать не нужно, и спек файл, и каталог с распакованными исходниками уже под рукой. Опять запустим buildreq-src, дополнительно передав ей spec файл опцией --spec <путь>. С опцией --spec buildreq-src только прочитает spec файл. Никаких изменений в spec файле не произойдет. buildreq-src --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz На этот раз утилита выведет более короткий список: # BEGIN SourceDeps(oneline): BuildRequires: libSDL_net-devel zlib-devel # END SourceDeps(oneline) Этот список -- разность между сборочными зависимостями пакета lbreakout2, найденными утилитой buildreq-src, и сборочными зависимостями пакета, прописанными в его спек файле. Список не пустой --- buildreq-src для lbreakout2 нашла две зависимости для lbreakout2, которые не указаны в спек файле: libSDL_net-devel и zlib-devel. Отсутствие zlib-devel не имело последствий, так как в итоге lbreakout2 все равно слинковался с -lz. Ее в итоге вытянула какая-то из других зависимостей. Однако поскольку lbreakout2 явно линкуется с zlib, то zlib-devel лучше добавить в BuildRequires явно. Сегодня она неявно вытягивается по зависимостям, а завтра может и не вытянуться. Тогда сборка сломается, или, что еще хуже, пакет молча соберется но потеряет часть функциональности -- не сможет работать со сжатыми данными. С libSDL_net-devel проблема немножко серьезнее. lbreakout2 собирается и без libSDL_net-devel, но у lbreakout2 есть режим сетевой игры. для которого libSDL_net-devel и нужен. Эту ситуацию я называю недособранным пакетом. В 99% случаев имеющейся функциональности lbreakout2 достаточно, но если вдруг пришли бы к ребенку гости и дети захотели бы попробовать по сети сыграть, то --enable-network был бы кстати. buildreq-src -bp ________________ Имеющиеся патчи могут существенно изменить пакет, в частности, поменять его сборочные зависимости. Поэтому имеет смысл запускать утилиту уже на правленные исходники. Для удобства, в buildreq-src есть опция -bp, которая как раз это и делает: вызывает rpmbuild -bp .spec, затем напускает buildreq-src на %builddir. $ buildreq-src -bp lbreakout2.spec Выполняется(%prep): /bin/sh -e /tmp/rpm-tmp.83798 + umask 022 + /bin/mkdir -p /home/RPM/BUILD + cd /home/RPM/BUILD + cd /home/RPM/BUILD + rm -rf lbreakout2-2.6.5 + echo 'Source #0 (lbreakout2-2.6.5.tar):' Source #0 (lbreakout2-2.6.5.tar): + /bin/tar -xf - + cd lbreakout2-2.6.5 + /bin/chmod -c -Rf u+rwX,go-w . + exit 0 # BEGIN SourceDeps(oneline): BuildRequires: libSDL_net-devel zlib-devel # END SourceDeps(oneline) Секция BEGIN/END SourceDeps ___________________________ Если все найденные зависимости уже есть в spec файле, buildreq-src выдаст сообщение buildreq-src: c2050.spec already contains all found dependencies если каких-то зависимостей нет, то они будут выведены в виде # BEGIN SourceDeps(oneline): BuildRequires: libSDL_net-devel zlib-devel # END SourceDeps(oneline) здесь "# BEGIN SourceDeps(oneline):" и "# END SourceDeps(oneline)" -- волшебные комментарии. BuildRequires: libSDL_net-devel zlib-devel, которые нашла buildreq-src, можно вставить в lbreakout2.spec руками. Однако если добавить опцию --update (примеры вызова:) buildreq-src --update --spec lbreakout2.spec ../SOURCES/lbreakout2-2.6.5.tar.gz buildreq-src --update -bp lbreakout2.spec то buildreq-src вставит в lbreakout2.spec фрагмент # BEGIN SourceDeps(oneline): BuildRequires: libSDL_net-devel zlib-devel # END SourceDeps(oneline) как раз в окружении волшебных комментариев. Эти комментарии очень важны: они позволяют организовать полуавтоматическое обновление сборочных зависимостей пакета. Работает оно следующим образом: без опции --update buildreq-src вообще не трогает пакет. С опцией --update buildreq-src правит только то, что находится между # BEGIN SourceDeps(oneline): и # END SourceDeps(oneline) Все, что вне, считается неприкосновенным. Как это работает: пусть у нас в lbreakout2.spec вручную вписано BuildRequires: libSDL-devel libSDL_mixer-devel BuildRequires: libpng-devel zlib-devel и в новой версии lbreakout2 переехал на libSDL2. Вызовем buildreq-src --update ... утилита вставит в спек новые найденные зависимости # BEGIN SourceDeps(oneline): BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel # END SourceDeps(oneline) но старые устаревшие BuildRequires: libSDL-devel libSDL_mixer-devel останутся, так как они внесены вручную, а майнтайнер всегда прав. Если же в спеке было # BEGIN SourceDeps(oneline): BuildRequires: libSDL-devel libSDL_mixer-devel libSDL_net-devel # END SourceDeps(oneline) то после вызова buildreq-src --update ... # BEGIN SourceDeps(oneline): BuildRequires: libSDL2-devel libSDL2_mixer-devel libSDL2_net-devel # END SourceDeps(oneline) т.е. новые автонайденные зависимости перезапишут собой старые автонайденные зависимости и старые устаревшие зависимости libSDL-devel libSDL_mixer-devel удалятся из спека. В итоге получается полуавтоматическое обновление сборочных зависимостей пакета. Формат найденных зависимостей. ______________________________ По умолчанию, buildreq-src там, где можно, пытается вывести найденные зависимости в пакетнонезависимом формате, так, как они упоминаются в тексте: # BEGIN SourceDeps(oneline): BuildRequires: /usr/bin/glib-gettextize perl(GD/Text/Wrap.pm) pkgconfig(cairo) # END SourceDeps(oneline) Это поведение можно изменить, указав --sourcedep-resolve=all или, что то же самое --sourcedep-resolve=path,perl,pkgconfig получим более привычные # BEGIN SourceDeps(oneline): BuildRequires: glib2-devel perl-GD-Text libcairo-devel # END SourceDeps(oneline) В следующем письме алгоритм работы утилиты, известные баги и фичи. Содержание: в силу самого своего алгоритма buildreq-src сожет зачерпнуть (и зачерпывает) и реально не нужные, лишние зависимости. Как их распознать и как с этим бороться. Как помочь утилите, когда она не справляется. Продолжение следует. -- I V