RPM 4.12

Мягкие зависимости в RPM есть уже лет 10-12.

Не в upstream.

Можно строить граф зависимостей, но все существующие варианты не отменяют того, что устанавливающему придётся думать головой что будет, если самому выбирать пакеты.

Что-то типа ${misc:Perl}. Как точно - вечером могу глянуть. Но к вечеру тебе проще открыть Гуго на 30 секунд :)

Тут скорее нужно объединять в какие-то группы с внятным описанием. Например, если поставить дополнительно несколько этих библиотек, то добавится такой-то функционал, несколько тех - другой функционал и т.п.

Это на каждый пакет надо писать кучу всего.

Что-то типа ${misc:Perl}. Как точно - вечером могу глянуть. Но к вечеру тебе проще открыть Гуго на 30 секунд :)

Открывал. Ничего внятного не нашёл.

На ближайшей убунте посмотрел на зависимости нескольких пакетов — там только пакеты.

Ходил и на https://packages.debian.org/stable/ ­— там тоже на нескольких просмотренных наугад пакетах в зависимостях только пакеты же.

Дык, эта строка и генерирует список пакетов. Т.е. ты это пишешь в строке Depends в control файле и при сборке dh разворачивает это в список нужных пакетов

В том что научиться писать rpm-спеки можно за пять минут, а в форматах deb-пакетов и всевозможных утилит для упрощения работы с ними разобраться нельзя.

Толсто же :) rpm наркоманский формат, а deb примитивный и за полчаса осваивается

Только для тех пакетов, для которых часть функционала выносится в рекомендуемое.

deb примитивный

То-то и оно.

и за полчаса осваивается

Ссылками на литературу класса «Maximum RPM», только про deb, не поделишься?

Я правда практического применения особо не вижу

Зависимость libfoo-dev от libfoo-doc. Если библиотека ставится для сборки чужого софта, документация не нужна. Если библиотека ставится для своей разработки, документация обычно нужна.

Тут еще важно, чтобы был какой-то удобный интерфейс выбора и возможность понять, что они дают. А если можно будет или не ставить ничего или все рекомендуемые пакеты, то оно же кучу мусора понаставит :) В дебе же apt-get только так и умеет или я что-то путаю?

У aptitude есть интерактивный режим.

На практике никто этим заморачиваться не будет, максимум комментарий в spec-файле.

У deb нет формата. Это набор несистематизированных костылей на все случаи жизни. На то есть конечно объективные исторические и идеологические причины, но сути дела это не меняет. Одно пакетирование бд чего стоит.

Толсто же :) rpm наркоманский формат, а deb примитивный и за полчаса осваивается

Вот это действительно толсто :) Собирал и то и другое, в deb вникать дольше. У rpm один спек и одна утилита. У deb 4 файлов надо написать минимум, плюс у каждого свой формат и пачка скриптов, чтобы со всем этим делом работать. А еще емнип при смене Standards-Version какие-то ньюансы были.

Зависимость libfoo-dev от libfoo-doc. Если библиотека ставится для сборки чужого софта, документация не нужна. Если библиотека ставится для своей разработки, документация обычно нужна.

Да, в таком случае было бы полезно. Естественно, при наличии адекватной поддержки в утилитах и гуях к ним.

deb примитивный и за полчаса осваивается

дохренища утилит для создания и конфигов внутри? apt-get source, apt-get build-dep, debuild, lintian, licensecheck, piuparts лол. не говоря уже о dpkg, apt-get, aptitude я конечно уважаю дебиан потому что сидел 3 года на нем, но никогда никому не врал что пакетирование в нем охренеть какое простое и интуитивное. в сравнении с этой кучей говноутилит rpm просто суперпуперкрутоипросто. а чекинг выглядит вот так:

sudo apt-get install lintian lintian4python libcrypt-ssleay-perl libwww-perl cppcheck devscripts pyflakes libperl-critic-perl desktop-file-utils mp3check checkmp3 mp3val fontforge-nox freetype2-demos gettext-lint jlint pngcheck jpeginfo vorbis-tools oggz-tools lacheck fdupes python-magic libxml2-utils similarity-tester moreutils pep8 blhc libconfig-model-perl libconfig-model-dpkg-perl bfbtester elfutils hlint adequate i18nspector epubcheck iwyu python-jpylyzer libb-lint-perl codespell duck
export BUILDPATH=/home/foo/path/to/foo-1.2.3
cd $BUILDPATH
lintian ../*.changes
lintian4py ../*.changes
cme check dpkg
cme check dpkg-control
cme check dpkg-copyright
debuild && debuild && debuild
uscan --verbose
licensecheck --check=. --recursive --copyright .
grep -i warn ../*.build
blhc --all ../*.build
cppcheck -j8 --quiet -f .
jlint.sh 2>&1 | fgrep -v 'Verification completed: '
pyflakes .
pep8 --ignore W191 .
perlcritic -1 .
suspicious-source
bfbtester -x 10 -a debian/*/bin debian/*/usr/bin debian/*/sbin debian/*/usr/sbin debian/*/usr/games
hlint .
codespell --quiet-level=3
find -iname \*.sh -print0 | xargs --no-run-if-empty --null -n1 sh -n
find -iname \*.sh -print0 | xargs --no-run-if-empty --null -n1 checkbashisms
find \( -iname \*.pm -o -iname \*.pl \) -print0 | xargs --no-run-if-empty --null -n1 perl -wc
find \( -iname \*.pm -o -iname \*.pl \) -print0 | xargs --no-run-if-empty --null -n1 perl -MO=Lint 2>&1 | grep -v ' syntax OK$'
find -iname \*.php\* -print0 | xargs --no-run-if-empty --null -n1 php -l -f
find \( -iname \*.c -o -iname \*.cxx -o -iname \*.cpp -o -iname \*.cc -o -iname \*.h -o -iname \*.hpp -o -iname \*.hh -o -iname \*.hxx \) -print0 | xargs --no-run-if-empty --null -n1 include-what-you-use
find -iname \*.desktop -print0 | xargs --no-run-if-empty --null -n1 desktop-file-validate
find -iname \*.mp3 -print0 | xargs --no-run-if-empty --null mp3check --error-check --anomaly-check
find -iname \*.mp3 -print0 | xargs --no-run-if-empty --null checkmp3
find -iname \*.mp3 -print0 | xargs --no-run-if-empty --null mp3val
find \( -iname \*.ttf -o -iname \*.otf -o -iname \*.sfd -o -iname \*.pfa -o -iname \*.pfb -o -iname \*.bdf -o -iname \*.pk -o -iname \*.ttc -o -iname \*.pcf \) -print0 | xargs --null --no-run-if-empty --max-args=1 fontlint
find \( -iname \*.ttf -o -iname \*.otf \) -print0 | xargs --no-run-if-empty --null -n1 ftvalid
find \( -name \*.po -o -name \*.pot \) -print0 | xargs --max-args=1 --no-run-if-empty --null msgfmt --check --check-compatibility --check-accelerators
find \( -name \*.po -o -name \*.pot \) -print0 | xargs --no-run-if-empty --null POFileChecker
find \( -name \*.po -o -name \*.pot \) -print0 | xargs --no-run-if-empty --null POFileSpell
find \( -name \*.mo -o -name \*.po -o -name \*.pot \) -print0 | xargs --no-run-if-empty --null i18nspector
find -iname *.png -print0 | xargs --no-run-if-empty --null pngcheck -q
find \( -iname \*.jpg -o -iname \*.jpeg \) -print0 | xargs --no-run-if-empty --null jpeginfo --check --quiet | fgrep -v "[OK]"
find \( -iname \*.jp2 -o -iname \*.j2k -o -iname \*.jpf -o -iname \*.jpx -o -iname \*.jpm -o -iname \*.mj2 \) | xargs jpylyzer --wrapper | xmllint --format - | egrep 'fileName|isValid' | tr -d \\n | sed 's_</isValidJP2>_&\n_g;s_ *<fileName>__g;s_</fileName> *__g;s_</\?isValidJP2>_ _g;s_False_is an invalid JPEG2000 file_g' | sed '/True *$/d'
find \( -iname \*.ogg -o -iname \*.oga -o -iname \*.ogv \) -print0 | xargs --no-run-if-empty --null ogginfo -q | grep -v 'Processing file ' | cat -s
find \( -iname \*.ogg -o -iname \*.oga -o -iname \*.ogv \) -print0 | xargs --no-run-if-empty --null oggz-validate
find -iname \*.xml -print0 | xargs --no-run-if-empty --null xmllint --noout
find -iname \*.tex -print0 | xargs --no-run-if-empty --null lacheck
find -iname \*.epub -print0 | xargs --no-run-if-empty --null -n1 epubcheck -quiet | egrep -v '^(Check finished with warnings or errors| *)$'
find -iname *.py -print0 | xargs --no-run-if-empty --null grep 'environ *\[.HOME.\]'
find -iname \*paypal\*.png -o -iname \*paypal\*.gif -o -iname \*flattr\*.png -iname \*flattr\*.gif
find \( -iname \*.png -o -iname \*.gif -o -iname \*.jpg -o -iname \*.jpeg \) -print0 | xargs --no-run-if-empty --null grep -iE 'inkscape|gimp'
find ! \( -iname \*.icns -o -iname \*.bmp -o -iname \*.ico -o -iname \*.png -o -iname \*.gif -o -iname \*.jpg -o -iname \*.jpeg -o -iname \*.mo -o -iname \*.gz -o -iname \*.zip -o -iname \*.pdf -o -iname \*.bz2 -o -iname \*.tar -o -iname \*.odt -o -iname \*.docx -o -iname \*.torrent -o -iname \*.pyc -o -iname \*.pyo -o -iname \*.o -o -iname \*.wav -o -iname \*.ttf -o -iname \*.ogg -o -iname \*.oga -o -iname \*.ogv -o -iname \*.xcf -o -iname \*.so -o -iname \*.so.\* -o -iname \*.gmo -o -iname \*.debug -o -iname \*.tga \) -print0 | xargs --no-run-if-empty --null isutf8
find ! -type d | xargs file  | grep ': *ELF ' | sed 's/: +*.*//' | xargs --no-run-if-empty eu-elflint --quiet --gnu-ld --strict
find -type f -iname \*.gz -print0 | xargs --no-run-if-empty --null gzip --test
find -type f -iname \*.bz2 -print0 | xargs --no-run-if-empty --null bzip2 --test
find -type f -iname \*.xz -print0 | xargs --no-run-if-empty --null xz --test
find \( -type f -iname \*.zip -o -iname \*.jar -o -iname \*.pk3 -o -iname \*.wz \) -print0 | xargs --no-run-if-empty --null unzip -t
find -type f -iname \*.lzma -print0 | xargs --no-run-if-empty --null lzma --test
find -type f -iname \*.lzo -print0 | xargs --no-run-if-empty --null lzop --test
find -type f -iname \*.lz -print0 | xargs --no-run-if-empty --null lzip --test
find -type f -iname \*.uu -print0 | xargs --no-run-if-empty --null uudecode -o /dev/null
grep -r '/tmp/' .
grep -r '/home' .
grep -r '/srv' .
grep -r '/opt' .
grep -r 'PATH' .
grep -r 'PERLLIB' .
grep -r 'x86_64-linux-gnu' .
grep -r 'site-packages' .
grep -rC4 'system *(' .
grep -rC4 'popen *(' .
grep -ri 'fixme' .
grep -ri 'todo' .
grep -ri 'hack' .
fdupes -r .
find -type f | sim_text -ipTt 75 | tac | column -t
apt-get install $(sed -n 's/^Package: //p' debian/control | tr '\n' ' ') ; debi ; apt-get -f install ; adequate $(sed -n 's/^Package: //p' debian/control | tr '\n' ' ')
duck
echo TODO: jslint puppet-lint acheck linkchecker ssl-cert-check

ты это пишешь в строке Depends в control файле и при сборке dh разворачивает это в список нужных пакетов

Вот! В зависимостях у deb в итоге всё равно пакеты. А у RPM — библиотеку/файл/модуль независимо от того, в каком пакете оно находится на самом деле. Т.е. RPM сам проверяет, есть ли пакет, предоставляющий необходимую библиотека/файл/модуль.

Вот пример от того же squid'а:

> rpm -i squid-3.4.6-1.5.x86_64.rpm
ошибка: Неудовлетворенные зависимости:
        libecap.so.2()(64bit) нужен для squid-3.4.6-1.5.x86_64

Т.е. squid'у помимо всего прочего необходима библиотека libecap.so.2. Библиотека! Не пакет! При этом библиотека может находиться в пакете с произвольным названием: libecap2, libecap, ecap-lib и т.п.

Специально хочу обратить внимание, что RPM, равно как и deb — оба ничего не знают о репозиториях и соотвественно, о доступных пакетах (и их содержимом в случае RPM). Это забота тулзы более высокого уровня — apt, yum, zypper, dnf и т.п.

> zypper wp libecap.so.2
Команда 'what-provides' заменена на 'search --provides --match-exact'.
Все доступные параметры приведены в 'help search'.
Загрузка данных о репозиториях...
Чтение установленных пакетов...

С | Имя      | Заключение                                     | Тип  
--+----------+------------------------------------------------+------
  | libecap2 | The libecap library implements eCAP API in C++ | пакет

Как видите, тулза более высокого уровня в состоянии разрешить подобные зависимости.

чекинг выглядит вот так

Это стена не относящегося к deb текста.

Добавлю так же, что подобные зависимости весьма облегчают использование сторонних репозиториев (качество сборки пакетов и возможность наступить на грабли, в т.ч. из-за конфликта пакетов — отдельная тема).

В частности сам собираю RPM в OBS для openSUSE и CentOS. Для openSUSE в OBS при опакечивании (как отжёг!) библиотек необходимо (хотя можно и забить) соблюдать правила именования пакетов, в то время как для RHEL/CentOS такого требования нет. Это позволяет мне не заморачиваться и собирать пакеты под разные системы из одного spec'а с правилами именования для SUSE:

# cat /etc/*-release
CentOS release 6.5 (Final)
CentOS release 6.5 (Final)
CentOS release 6.5 (Final)

# rpm -qa | grep ecap
libecap2-0.2.0-2.5.x86_64

# rpm -e libecap2
ошибка: Неудовлетворенные зависимости:
        libecap.so.2()(64bit) нужен для (установлен)squid-10:3.4.6-1.1.x86_64

Неплохо бы теперь чтобы был хоть один хороший дистрибутив на рпм. Если только внезапно федора перестанет радовать критическими багами в релизах

centos, подключаешь репозитории remi,rpmfusion , epel и свежих кед, и получаешь чуть более старые пакеты чем в fedora.

rpm куда лучше чем deb

Куд-куда лучше, да?

apt-get source, apt-get build-dep, debuild, lintian, licensecheck, piuparts лол. не говоря уже о dpkg, apt-get, aptitude

Перевожу для всех остальных: я знаю кучу умных команд, я не знаю что они делают и какое отношение имеют к пакетированию, но я могу считать, а 2 > 1, соответственно 2 — это плохо, а 1 — отлично.

Вруниша, там их далеко не две. Или дальше двух тебя не научили читать?

Ставь релиз через пару месяцев, когда баги пофиксят. В чем проблема? )

ответить по существу не может
текст прочитанный не понимает

Тут выше по треду на тебя правильную рецензию дали.

Пакеты теперь могут содержать файлы, размер которых превышает 4Гб ...

Зачем такой большой размер файла? Чтобы тестировать IPv6 Jumbogram?

Например пакет с тестовыми данными.

Вот! В зависимостях у deb в итоге всё равно пакеты. А у RPM — библиотеку/файл/модуль независимо от того, в каком пакете оно находится на самом деле. Т.е. RPM сам проверяет, есть ли пакет, предоставляющий необходимую библиотека/файл/модуль.

За это приходится платить изрядно возрастающим объёмом базы пакетов в репозитории. В Fedora, к примеру, обновление индекса выливается в скачивание порядка 80 МБ, что на порядок больше, чем в Debian. Не говоря уже о том, что изменения в базе в Debian обычно скачиваются дельтами.

У deb нет формата.

lolwut?

Вот в rpm аналогов нормальных нет yast --install?

Так это нормально, пыхомакаки же!

дохренища утилит для создания и конфигов внутри? apt-get source, apt-get build-dep, debuild, lintian, licensecheck, piuparts лол.

md5deep ещё забыл. Как ни странно, она не во всяком дебианоподобном дистре есть, хотя для создания deb требуется, ЕМНИП, всегда.

md5deep ещё забыл. Как ни странно, она не во всяком дебианоподобном дистре есть, хотя для создания deb требуется, ЕМНИП, всегда.

4.2

Что именно 4.2 - первая половина фразы или вторая?

Вторая.

Вообще-то, когда на ЕМНИП отвечают 4.2, это несколько нелогично.

Теперь по сути. Насколько я помню, DEBIAN/md5sums для создания пакета обязателен. А md5deep применяется потому, что md5sum не умеет рекурсивный подсчёт.

Где здесь ошибка?

Насколько я помню, DEBIAN/md5sums для создания пакета обязателен

Да? А я видел пакеты без MD5-сумм и даже делал такие сам.

md5deep применяется потому, что md5sum не умеет рекурсивный подсчёт.

Где здесь ошибка?

Ты хочешь знать, где именно? Мне-то это никогда не было интересно - MD5 в пакете есть, а рассчитываются они md5sum, find | xargs | md5sum или неведомой md5deep - неважно.

openSUSE же

В Alt/PCLinuxOS RPM через APT.

соблюдать правила именования пакетов, в то время как для RHEL/CentOS такого требования нет. Это позволяет мне не заморачиваться и собирать пакеты под разные системы из одного spec'а с правилами именования для SUSE

Наконец-то!

Вот это хорошее объяснение нужности фичи. Спасибо.

Просто все остальное что писали выше про файло-зависимости либо легко решается виртуальными пакетами, либо просто не нужно.

Пакеты теперь могут содержать файлы, размер которых превышает 4Гб

xkcd по теме

RPM-пакеты собирать из исходников сильно проще, чем deb? Имею в виду жирные пакеты, типа qcad.

RPM-пакеты собирать из исходников сильно проще, чем deb? Имею в виду жирные пакеты, типа qcad.

Если «жирные» подразумевает объём, то вообще без разницы, поскольку билд бинарей всё равно делается одинаково — configure && make && make install (или аналоги).

Интересует не просто сборка бинарей, а упаковка их в пакеты. Зачем нужен configure && make && make install и помойка в системе, когда можно собрать пакет и установить при помощи ПМ. Так вот, где это проще, в деб или рпм?

Интересует не просто сборка бинарей, а упаковка их в пакеты. Зачем нужен configure && make && make install и помойка в системе, когда можно собрать пакет и установить при помощи ПМ.

А при чём здесь тогда «жирность»?

Так вот, где это проще, в деб или рпм?

Я deb не осилил.

А при чём здесь тогда «жирность»?

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

Я deb не осилил.

Почему? А что тогда осилил?

Имею в виду жирные пакеты, типа qcad.

А что с ним не так?

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

Количество зависимостей в общем случае на сложность сборки не влияет. Ну т.е. в том смысле, что если все необходимые пакеты для сборки данного уже готовы, то что сложного в том чтобы установить их в сборочное окружение? Тем более что такие вещи, как подготовка сборочного окружения, можно доверить автоматике — OBS, например, или mock.

Если всех пакетов, необходимых для сборки данного нет, то соответственно с них и нужно начинать.

Я deb не осилил.

Почему?

Слабак :-(

А что тогда осилил?

Я думал это очевидно в данном контексте — RPM.