LINUX.ORG.RU

RPM 4.18

 ,


0

3

RPM — менеджер пакетов в дистрибутивах на базе Red Hat, а также в некоторых прочих.

Изменения в RPM 4.18:

  • Добавлена защита от уязвимостей в коде обработки больших файлов.
  • Новый макрос %bcond для определения условий при сборке.
  • Добавлена поддержка тегов meta и pre при определении слабых зависимостей.
  • Новый OpenPGP-бэкенд для работы с подписями пакетов, основанный на Sequoia.
  • Новая интерактивная оболочка rpmspec --shell с поддержкой макросов и Lua (rpmlua).
  • Новая секция в spec-файлах %conf для сборки файлов конфигурации.
  • Новая утилита командной строки rpmuncompress для простой распаковки нескольких файлов.
  • Многочисленные мелкие исправления и улучшения
  • Многочисленные исправления безопасности внутреннего парсера OpenPGP.

>>> Подробности

★★★

Проверено: cetjs2 ()

Хорошо, что в этом мире есть постоянные вещи.

GFORGX ★★☆ ()

По сути же, вот изначально хоть я и Debian-человек (моим вторым линуксом был присланный Шаттлвортом CD убунты 6.04) – после десятилетнего опыта больше с BSD, как-то мне rpm удобнее, чем dpkg…

GFORGX ★★☆ ()
Ответ на: комментарий от GFORGX

Чем удобнее? Я когда-то работал над Red Hat based дистрибутивом, собирал пакеты, с тех пор избегаю всего, связанного с RPM и Red Hat инстинктивно. Моей психике тогда был нанесён непоправимый урон.

В RPM тогда (как сейчас - не знаю, и знать не хочу) было совершенно невозможно сделать многие вещи, которые очень нужны в реальной жизни. Типа того, чтобы установить две версии одного пакета. И вообще, с управлением зависимостями и гибкостью у него было просто никак. Это был примитивный, как топор, инструмент, и если не хотелось или не было возможности устанавливать программы и библиотеки через ./configure; make; make install, а создатель дистрибутива так сделать не может, то приходилось выкручиваться через жутко уродливые костыли.

emorozov ()
Последнее исправление: emorozov (всего исправлений: 2)
Ответ на: комментарий от GFORGX

Debian-человек

Итак, господа, перед нами homo debianus (демьян-человек обыкновенный) в естественной среде обитания. По внешним признакам и манере выражаться практически не отличим от человека разумного (homo sapiens). Однако, при внимательном рассмотрении становиться очевидным, что перед нами великолепный образец многоуровневой мимикрии.

Этот вид хорошо адаптировался на ЛОРе. Уровень естественных агрессий довольно низкий. Размножается быстро. Привычки не меняет. С точки зрения эволюции ветвь довольно тупиковая — переход в другие виды маловероятен.

Предлагают высказаться по этому вопросу более узким специалистам.

papin-aziat ★★★★★ ()
Ответ на: комментарий от papin-aziat

Привычки не меняет

человек же тебе написал, что поменял дистр.

я вот не знаю, что мне удобнее. если не сношать систему, удобно всё.

flant ★★ ()
Ответ на: комментарий от flant

человек же тебе написал, что поменял дистр

Редкая мутация, со мной тоже такая произошла, и бздя тоже была, кстати.

papin-aziat ★★★★★ ()
Ответ на: комментарий от emorozov

Типа того, чтобы установить две версии одного пакета.

А в debian это возможно ? Пример в студию.

По крайне мере у меня в Шапке стоят сразу куча питонов, postgres и т.д. И это вообще вопрос не к RPM а знанию инструмента.

spec файл достаточно простой и удобный и причем куча софта (да к примеру тот же python) сам автоматом генерит все это. (python setup.py bdist_rpm)

ксати а как debian утилита аналог mock ?

P.S. Я пока сильно с dpkg не разбирался в будущем это, но разбираюсь с строением репозитария на apt, это явно бред какой то. Ощущение что годами куча народа все валила там в кучу … :(

Вот пример пути :

/debian/dists/Debian11.5/main/installer-amd64/20210731+deb11u5/images/netboot/gtk/debian-installer/amd64/
mx__ ★★★★★ ()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

А в debian это возможно ? Пример в студию

А что в этом сложного? У меня получалось. Хотя шанс превратить систему в помойку и развалить её существует.

utanho ★★★ ()
Ответ на: комментарий от mx__

Я говорю про времена ещё до появления Федоры. Ориентировочно начало-середина 2000-х.

Тогда RPM был самым убогим форматом пакетов, и это было общепризнано. Он не позволял правильно указать зависимости во множестве случаев, конкретные подробности сейчас не вспомню, т.к. прошло 15 лет или больше.

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

Работать с пакетами и зависимостями в Red Hat было просто непрерывной болью.

Когда где-то в 2005 году попробовал Debian, то после убожества Red Hat он показался мне космическим кораблем. Я еще удивлялся, как энтузиасты могут сделать что-то на порядки лучшее, чем коммерческая компания с деньгами.

Что там сделали в Red Hat/RPM после этого времени мне уже неинтересно. Даже если они исправили убогий формат указания и алгоритм разрешения зависимостей, у меня мой опыт пакетирования под Red Hat вызвал настолько стойкое отвращение ко всему, что исходит из их рук, что нет желания даже пойти и проверить, что изменилось.

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

emorozov ()
Ответ на: комментарий от emorozov

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

Так стареем, и хотелось бы чтобы просто работало без всякого красноглазого чтения ховту типа как в :

Как избежать дико глючной и тормозной Plasma 5.25 на Manjaro KDE

Как исправить мигание изображения и прочие глюки отрисовки на связке KDE Plasma + Wayland + Nvidia

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

Ржунимагу, астанавите! KDE - уже страшно, а тут ещё Wayland + Nvidia. И чтобы всё гладенько… Hentai!

SharpTits ()
Ответ на: комментарий от emorozov

Типа того, чтобы установить две версии одного пакета.

То-то на Deb-based дистрибутивах происходит всяческий разврат, когда надо, чтобы в системе была и 32-битная версия пакета и 64-битная одновременно. [А именно: wine собирать на них отвратительно в отличие от RPM-based]

X-Pilot ★★★★★ ()
Ответ на: комментарий от SpaceRanger

apt и rpm - разные вещи по предназначению. Тогда уж надо бы сравнивать dpkg и rpm.

emorozov ()

Там уже можно тянуть исходники по сети без костылей с проверкой хеш-сум или все так же по «олсдкулу» в нужную папочку ручакми закинуть?

permafrost ★★ ()
Ответ на: комментарий от utanho

Ну так это везде можно.

И приемы одинаковые. Чаще всего меняют название пакета и все.

python*

python3*

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

Не чушь, просто в современном Интернете сложно найти что-то с ограничением по дате. А так, если бы можно было посмотреть списки рассылки, форумы, соц. сети 2000-х, то там были тонны обсуждений, какая уродская и тупая система зависимостей в RPM и костыли, чтобы её обойти.

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

emorozov ()
Ответ на: комментарий от mx__

Типа того, чтобы установить две версии одного пакета.

А в debian это возможно ? Пример в студию.

Вероятно, имелась в виду Политика Debian, которая делает обязательным присутствие версии ABI в имени пакета библиотеки, что позволяет иметь установленными одновременно несколько версий библиотек.

Но это больше про политику, нежели про формат пакетов.

ксати а как debian утилита аналог mock ?

pbuilder?

Вот пример пути :

Это явно путь к образам установщика, а не репозиторий APT.


Ну и у меня есть небольшой вопросик.

Вот мы разрабатываем в том числе и под ARM. В Debian я установил окружение для кросс-компиляции:

apt install crossbuild-essential-armhf crossbuild-essential-arm64

— добавил архитектуры armhf и arm64:

dpkg --add-architecture armhf
dpkg --add-architecture arm64

— установил все нужные библиотеки и пакеты разработчика для этих архитектур:

apt install lib{ssl,xml2,…}-dev:{armhf,arm64}

— и просто тестово собираю для ARM на своей машине, выбирая соответствующую цель (которая устанавливает используемый компилятор C).

Как этого добиться в, скажем, Fedora, не извращаясь с QEMU? Окружение для кросс-компиляции как бы есть, но библиотек там — кот наплакал. И если в Debian я просто беру и устанавливаю любые библиотеки из репозитория для нужной мне архитектуры, то как с этим в Fedora?

Rootlexx ★★★ ()
Последнее исправление: Rootlexx (всего исправлений: 1)
Ответ на: комментарий от Rootlexx

Хз понял ли я ВАС.

mock это типа минимальный набор для сборки чтобы не забыть какую либо зависимость …

setarch i386 mock -r –rebuild package-1.2-3.src.rpm

Делается чанж-рут и туда ставиться самый минимальный набор.

(хотя теперь есть контейнеры и это не сильно актуально …)

mx__ ★★★★★ ()
Ответ на: комментарий от mx__

смешалось все кони, люди…. :)

организация структуры репозитория оставлено на усмотрения менеджера репозитория. апт ее никак не регламентирует.
апт требует валидную строчку url пакета в параметре Filename: листинга репозитория.

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

в рпм думаю тож самое.

pfg ★★★★★ ()
Ответ на: комментарий от UriZzz

Разобрать диван, внести комплектующие дивана в помещение, собрать диван в помещении.

Mischutka ★★★ ()
Ответ на: комментарий от emorozov

rpm удобнее, чем dpkg…

Чем удобнее?

Чем dpkf, написал же человек.

установить две версии одного пакета

$ rpm -qa | grep openjdk
java-1.8.0-openjdk-headless-1.8.0.345.b01-1.fc36.x86_64
java-1.8.0-openjdk-1.8.0.345.b01-1.fc36.x86_64
java-17-openjdk-headless-17.0.4.1.1-1.fc36.x86_64
java-17-openjdk-17.0.4.1.1-1.fc36.x86_64

$rpm -q kernel-core
kernel-core-5.19.4-200.fc36.x86_64
kernel-core-5.19.8-200.fc36.x86_64
kernel-core-5.19.9-200.fc36.x86_64

Ну, не знаю… Hands.sys?

TI_Eugene ★★ ()
Ответ на: комментарий от TI_Eugene

Я говорил про ситуацию, которая была в начале 2000-х. Даже явно подчеркнул, что уверен, что какую-то часть изначальных проблем RPM Red Hat наверняка с тех пор починил. Ибо в начале 2000-х он был невероятно крив и туп.

Ещё раз просто повторяю: ужасная кривизна RPM в те времена, навсегда сделали мне прививку от любви к компании Red Hat и любым её продуктам. Может быть, они замечательные. Но я, в своё время, так з#$%$% с этим RPM, который был тупой как валенок, что даже сейчас, спустя много лет, при виде буковок Red Hat или RPM, меня начинает трясти от ненависти и отвращения. Это мой субъективный опыт.

Сейчас может быть RPM превзошел dpkg и всё остальное (хотя вряд ли, на такой изначально ущербной основе), но проверять принципиально не хочется. А так как и необходимости нет - выбор других дистрибов и пакетных менеджеров огромный - то надеюсь и не придётся проверять, что изменилось.

emorozov ()
Ответ на: комментарий от SpaceRanger

Щас бы спорить о двух видах кала: apt и rpm…

AltLinux использует apt поверх rpm.

TI_Eugene ★★ ()
Ответ на: комментарий от emorozov

На самом деле и rpm и dpkg - это просто сжатые архивы (cpio и tar соответственно), так что там никаких особых чудес нет. Другой вопрос как ними манипулируют соответствующие утилиты. Но это уже вопрос консерватизма vs моднохороводности.

TI_Eugene ★★ ()
Ответ на: комментарий от TI_Eugene

Говорит человек, который, видимо, никогда не собирал пакеты.

«На самом деле, программа — это просто бинарный код процессора. Поэтому никаких чудес нет, как и разницы между Windows и Linux или PostgreSQL и SQLite. Всё это вопрос консерватизма vs моды»

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

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

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

emorozov ()
Ответ на: комментарий от emorozov

Просто mock это ручная и тестовая сборка еденичных пакетов. Давно уже все spec с патчами лежат в git и koji собирают дистрибутивы под разные архитектуры …

mx__ ★★★★★ ()
Ответ на: комментарий от TI_Eugene

ты же специально выбрал те пакеты, под которые изначально задумывалась возможность установки несколько версий параллельно (ядро) и разные пакеты (java)? Да, java-17-openjdk-headless и java-1.8.0-openjdk-headless это совершенно разные пакеты, потому и нет проблем ставить вместе. точно также как для какого-нибудь python2/python3

user_undefined ()
Ответ на: комментарий от pfg

стоят обе, каждая используется тогода когда она нужна…

И без chroot? Как-то не верится:

https://wiki.winehq.org/Multiarch

Я сам пытался собирать несколько лет назад на SteamOS (по сути, Debian с шеллом от Steam) и состояние тогда было совсем не «стоят обе». В RPM-based дистрибутивах с этим намного проще

X-Pilot ★★★★★ ()
Ответ на: комментарий от user_undefined

ты же специально выбрал те пакеты, под которые изначально задумывалась возможность установки несколько версий параллельно (ядро) и разные пакеты (java)?

Можно подумать, в дебиан по другому.

 apt search python | grep  minimal | grep python

libpython2.7-minimal/stable,now 2.7.13-2+deb9u5 amd64 [установлен, автоматически]
libpython3.5-minimal/stable,now 3.5.3-1+deb9u4+ci202104261458+astra1 amd64 [установлен, автоматически]
libpython3.7-minimal/stable,now 3.7.3-2+deb10u3+ci202107011746+astra2 amd64 [установлен, автоматически]
python-minimal/stable,oldoldstable,now 2.7.13-2 amd64 [установлен, автоматически]
python2.7-minimal/stable,now 2.7.13-2+deb9u5 amd64 [установлен, автоматически]
python3-minimal/stable,now 3.5.3-1+ci202106240040+astra1 amd64 [установлен, автоматически]
python3.5-minimal/stable,now 3.5.3-1+deb9u4+ci202104261458+astra1 amd64 [установлен, автоматически]
python3.7-minimal/stable,now 3.7.3-2+deb10u3+ci202107011746+astra2 amd64 [установлен, автоматически]

AVL2 ★★★★★ ()
Последнее исправление: AVL2 (всего исправлений: 1)
Ответ на: комментарий от emorozov

Я с 1998 года занимаюсь редхатом.

Проблема зависимостей в том, что иногда сломаны. Хоть в дебиане, хоть редхате. И если для рпм это неприятно, то для дебов это катастрофа.

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

AVL2 ★★★★★ ()
Ответ на: комментарий от AVL2

apt просто отказывается работать при незамкнутом дереве зависимостей

Это не так. APT откажется устанавливать сломанный подграф (это не дерево, если что), но всё, что не входит в текущую операцию, может быть хоть 100 раз сломано - это не повлияет на неё.

Rootlexx ★★★ ()
Ответ на: комментарий от AVL2

Можно подумать, в дебиан по другому.

Ещё раз: в Debian Политика обязывает пакеты библиотек иметь версию ABI как часть имени, что позволяет устанавливать несколько версий библиотеки одновременно (например, в buster были libreadline5 и libreadline7), а в той же Fedora это применимо лишь к малой доле пакетов. Но для системы это разные пакеты, а не разные версии одного пакета. Установить же одновременно несколько версий одного и того же произвольного пакета нельзя ни там, ни там.

Это вопрос не менеджеров пакетов, а политики дистрибутива.

Rootlexx ★★★ ()
Ответ на: комментарий от Rootlexx

Кажется ты путаешь с yum. В yum.conf действительно есть настройка installonlypkgs со значением по умолчанию kernel. В самом rpm ограничений нет. Ты можешь любой пакет инсталлировать -i вместо апгрейда -U. И если конфликтов по файлам нет, он инсталлируется.

iliyap ★★★★★ ()
Последнее исправление: iliyap (всего исправлений: 1)
Ответ на: комментарий от iliyap

И тем не менее, используется это исключительно для пакетов ядра, а всякие там python, java и проч. имеют версию как часть имени пакета — почему так?

Rootlexx ★★★ ()
Ответ на: комментарий от X-Pilot

wine требует i386 :-/ так что вот так. стоят, друг другу не мешают.

$ dpkg -l
||/ Имя                 Версия                    Архитектура
ii  libdb5.3:amd64      5.3.28+dfsg1-0.8ubuntu3   amd64
ii  libdb5.3:i386       5.3.28+dfsg1-0.8ubuntu3   i386
ii  libdbus-1-3:amd64   1.12.20-2ubuntu4          amd64
ii  libdbus-1-3:i386    1.12.20-2ubuntu4          i386
pfg ★★★★★ ()
Последнее исправление: pfg (всего исправлений: 2)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.