rpmbuild изменить формат сжатия

Я пытаюсь упаковать некоторые файлы карт для нашего геосервера во внутренний пакет rpm. Для части сборки это просто копирование файлов. Я думаю, что это работает так, как ожидалось. Но упаковка этих 20 ГБ изображений занимает ужасно много времени.

Я читал, что rpm внутренне сжимает данные и что это можно сделать с помощью нескольких различных алгоритмов сжатия. Но я понятия не имею, какое сжатие выбирают мои обороты и как я могу на это повлиять. Я не смог найти никаких параметров ни для команды rpmbuild, ни для specfile, ни для общих параметров rpm, которые я могу перечислить с помощью rpmbuild --showrc

Я не очень разбираюсь в rpmbuild и specfiles, но после прочтения множества справочных страниц и туториалов на rpm.org у меня больше нет идей.

Спецфайл, который я использую, выглядит так:

%define debug_package %{nil}

%global mapsversion 0.9
# If this is a snapshot, put the date here and uncomment
#global snapshot_version 20100519

# This is the version in a form acceptable
# an an RPM version string (i.e. no '-')
# Hier werden die Makros definiert.
%global rpmversion %(echo %{mapsversion} | tr '-' '_')
%global pkgversion %{mapsversion}%{?snapshot_version:-SNAPSHOT}
%global pkgname %{name}

Name:           geoserver-maps-part2
Version:        %{rpmversion}
Release:        1%{?dist}
Summary:        Swiss Maps for GeoServer
Group:          Application/ourApp
License:        Copyright (c) 2011
URL:            http://doc.polyalert.local
#Source0:        %{name}-%{version}.tgz
BuildArch:  noarch
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires:   geoserver

%define mapshome /opt/geoserver/swisstopo
%define mapssource /home/user/polyalert_env/geoserver/swisstopo

%description
Swiss Maps for GeoServer

%prep

%build
/bin/true

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{mapshome}
cp -a %{mapssource}/pk100 $RPM_BUILD_ROOT%{mapshome}

%clean
rm -rf $RPM_BUILD_ROOT

%pre

%post

%preun


%files
%{mapshome}/pk100

%changelog
* Tue Feb 14 2012 user - 1.0
- First version of specfile

Я вызываю rpmbuild следующим образом:

rpmbuild -bb --define "_topdir $TOP_DIR" --define "_gpg_name ourkey" --define "_signature gpg" --sign $TOP_DIR/SPECS/$SPEC_FILE_NAME $RPM_BUILD_PARAMETER

Какие-либо предложения?


person mkraemerx    schedule 15.02.2012    source источник
comment
Единственное сжатие, о котором я знаю, это /usr/lib/rpm/brp-compress, которое будет сжимать справочные страницы.   -  person Aaron D. Marasco    schedule 11.04.2012
comment
поскольку RPM намного меньше, чем предоставленные входные данные, я почти уверен, что все данные там сжаты. Я даже понял, что zip-архивы (в моем случае файлы jar), содержащиеся в RPM, будут снова сжаты, так что jar, установленный из RPM, отличается от входного (даже если его содержимое идентично)..   -  person mkraemerx    schedule 13.04.2012
comment
Хорошо, тогда я должен был предварить это единственным контролируемым пользователем сжатием... ;)   -  person Aaron D. Marasco    schedule 18.04.2012


Ответы (4)


Сегодня я работал с некоторыми RPM-вещами и случайно наткнулся на ответ для тебя!

Поместите их в свой spec файл:

%define _source_payload w0.gzdio
%define _binary_payload w0.gzdio

Это по-прежнему будет использовать gzip, но передать его -0 для уровня, который следует просто сохранить. На моем RPM он увеличился с 21 МБ до 76 МБ, поэтому я почти уверен, что это ваш ответ!

Кстати, я обнаружил, что в одном из файлов macro вы также можете сделать bzdio и любое число от 0 до 9, чтобы использовать bzip2. Это было на RHEL4; более поздние версии RPM, кажется, поддерживают больше параметров сжатия; но опять же, для того, что вы хотите, вышеперечисленное должно быть тем, что вам нужно.

person Aaron D. Marasco    schedule 21.04.2012
comment
хотелось бы, чтобы кто-нибудь проверил это на Fedora 20 или RHEL7. - person mxmader; 16.09.2014
comment
Они должны поддерживать xz — см. здесь. - person Aaron D. Marasco; 17.09.2014

Пожалуйста, проверьте файл /usr/lib/rpm/macros на вашей сборочной машине (файл может отличаться по пути), там есть полный список поддерживаемых методов сжатия: например:

329 #       Compression type and level for source/binary package payloads.
330 #               "w9.gzdio"      gzip level 9 (default).
331 #               "w9.bzdio"      bzip2 level 9.
332 #               "w7.xzdio"      xz level 7, xz's default.
333 #               "w7.lzdio"      lzma-alone level 7, lzma's default
334 #
335 #%_source_payload       w9.gzdio
336 #%_binary_payload       w9.gzdio

так что здесь, как сказал Аарон, вы можете установить его здесь для универсального или установить специально для вашего проекта. спец.

person Rozen Lin    schedule 16.09.2014

Я столкнулся с той же проблемой, когда Ant создал работающий Jar RPM с помощью Spring Boot Loader, жалуясь на это:

Причина: java.lang.IllegalStateException: невозможно открыть вложенную запись "BOOT-INF/lib/accessors-smart-1.2.jar". Он был сжат, и вложенные файлы jar должны храниться без сжатия. Пожалуйста, проверьте механизм, используемый для создания исполняемого файла jar

Моя задача сборки муравья была такой:

<exec executable="rpmbuild"  failonerror="true"> 
  <env key="version" value="${fullversion}" /> 
  <arg value="-ba" /> 
  <arg value="--clean" />
  <arg value="${specfile}" />
</exec>

Мое решение создать RPM с исполняемым JAR состояло в том, чтобы отключить переупаковку, установка определений макросов в файле спецификаций не сделала этого для меня.

Добавление этого в файл спецификации помогло мне:

#Disable jar unpacking
%define __jar_repack 0

Ссылка: https://bugzilla.redhat.com/show_bug.cgi?id=219731< /а>

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

Эрион

person Erion Omeri    schedule 13.12.2018

Я использовал «%define _binary_payload w9.xzdio» на RHEL 6.6. Насколько я понимаю, инструмент сжатия по умолчанию, используемый в RHEL 6, — это xz, но уровень сжатия по умолчанию равен 2, хотя 7 должен быть по умолчанию для xz. Я увеличил его до 9, и некоторые гигантские RPM увеличились с 653 МБ до 439 МБ. Я смог сэкономить в общей сложности 1 гигабайт по сравнению со сжатием по умолчанию.

person Chuck    schedule 05.11.2015
comment
Это было отмечено в моем комментарии выше от сентября 2014 года. - person Aaron D. Marasco; 06.11.2015