После года разработки состоялся релиз пакетного менеджера RPM 4.20.0. Проект RPM4 развивается компанией Red Hat и используется в таких дистрибутивах, как RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS и Tizen. Код проекта распространяется под лицензиями GPLv2 и LGPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62035
>В новой ветке также намерены разрешить использование языка C++ для разработки RPM.какое-то безумие при наличии rust и go
какое-то безумие предлагать раст и го при наличии питона и джаваскрипта
Почему 6 а не сразу 60?
запросто, просто нужно успеть поднять 53 проекта которые непосредственно не связаны с RPM от Red Hat и будут иметь названия
RPM6
RPM7
...
RPM59
Выпустят RPM2024
потому что в какой-то момент некие энтузиасты сказали: "Мы будем пилить свой RPM. Назовём его RPM5."
Энтузиазма хватило на полсеместра. Потом сессия - не до пакетных менеджеров стало.Но название RPM5 уже разбрелось по умам наивных юзеров, ожидавших что сейчас им подгонят классный менеджер.
Так что в целях избежания путаницы перепрыгнули цифру 5
... и этим студентом был основной разработчик рпм, ушедший из редхата.
> Альты кажется могут рассказать часть иcторий про рпм.И про свойства файлов в файловых менеджерах, например в простой крысе для домохозяек?
>... и этим студентом был основной разработчик рпм, ушедший из редхата.Вот вам немного баек от дидов.
RPM5 занимался некий весьма пожилой дедушка Джефф Джонсон, выходец из Шапки. Может там и были какие-то его студенты(а он за одно работал в каком-то мериканьском ВУЗе), кто за него все пилил, но общались мы именно с ним, когда делали РОСУ/Мандриву самым первым составом компании.
В одно не самое прекрасное утро поступило распоряжение сверху - переходим на RPM5, чтобы чем-то отличаться в "крустость" от альта с которым воевали за место под солнцем :). В чем тут крутость на рынке осей по мысли боссов - нам было непонятно, но избавиться от перлового г*вна перейдя на С++(или там С был, я не помню уже) - было заманчиво и здраво.
Сказано - сделано, перебилдили все с RPM4 на RPM5. Но выяснилось по дороге, что Джефф патологически не способен к сотрудничеству, постоянно мне писал пространные простыни на тему "почему именно сегодня он снова не успел к дедлайну". В итоге, мы плюнули и накатали на коленке свои обвязки к его поделке на писТоне и как-то жили дальше с ними через одно место (например сперва даж исошку собрать было нечем - репы стали несовместимы и т.д и т.п. Поэтому всякие urpmi, yum'ы, mock'и и прочие лиф-тулзы шли лесом).
Мы внутри енту мандриву называли не иначе как "федрива" за замену/портирование (мною лично) всех основных тулов на федоровские вместо давно протухего broken/unsupported perl-мусора от мандрейка который нам достался на нашу голову.
Потом, первый состав сотрудников был жестко уволен наher из-за нашествия _новых_ гиперконвергентных высокоэффективных менеджеров в топах, да и самой РОСЫ вскорости практически не стало благодаря усилиям этих уникальных варягов.
Те кто щас тянут возрожденную росу (а это совсем другие люди) пилят ее на RPM4. Кажется, там федривы стало еще больше :), как минимум, ничего не поменялось ни в dracut, ни в тулах, ни в сборочном сервере (abf.io), которые мы сделали первым составом.
от такие дела, малята
Знатно тот дедушка вас затроллил. fdatasync на каждый чих, из-за которого 1 Гиг обновлений устанавливался джва часа на SSD и система на это время вставала колом - это позор. Понимаю, что никто не заметил, кроме пользователей - на виртуалке не воспроизводится. Ну и прежде чем спорить, идём на форум и читаем эпопею о сравнении rpm4 с rpm5 и имеем ввиду, что исправили это всё макросом, смысл которого не понимал никто, даже я. ;) Потому мой патч накатывали-откатывали раз 5.
> на виртуалке не воспроизводитсяты думаешь, у них в 11м году были виртуалки а не железная билдферма из пяти-восьми серверов?
Другое дело что кого оно там колебло...
Ну после сборки надо же где-то протестировать, так сказать, в работе? И куда в то время шли все эти "я тестирую на виртуалке" после собеседований?
> Знатно тот дедушка вас затроллил. fdatasync на каждый чих, из-за которого 1
> Гиг обновлений устанавливался джва часа на SSD и система на это
> время вставала колом - это позор.Вообще-то так себя ведут практически все пакетники. Для атомарности операций. Ибо познакомиться с ситуацией когда бд пакетника разъехалась с фактически сделанными операциями - очень такое себе. И если база развалится, можно познать много радости. Особенно с RPM-образными. Впрочем, в deb-образных тоже при случае с ЭТИМ попыхтеть - придется. Если все же удастся на это нарваться.
Поэтому те кто поумнее уже делают что-то типа:
btrfs subvol snapshot / /snapshots/before-upgrade
eatmydata apt upgrade
(апгрейд 1005000 пакетов)А если не прокатило - вместо канители с порушеной БД пакетника и системой в неконсистентном состоянии воооон там снапшот взять - и весь откат неудачного апгрейда. Вместо потуг что-то сделать по поводу десинка базы пакетника с реальным состоянием вещей и прочими прелестями типа полуустановленых пакетов.
Кстати, MSI Installer в таком духе - ломается еще охотнее, и потом его ни туда, ни сюда, а если сравнить скорость инсталла N программ в винде и линухе, окажется что большая часть линуховых пакетников - были не такие уж и плохие. На механику вьюжлстудию можно было ставить иной раз и добрые полдня, с тремя ребутами на всякие апгрейды дотнетов и проч. И это на топовый по своим временам комп.
> Понимаю, что никто не заметил, кроме пользователей - на виртуалке не воспроизводится.
Если кто гоняет виртуалки с порушеной семантикой операций - они "почему-то" очень склонны дохнуть потом при любых отклонений от идеала. Хотя на одноразовых виртуалках это не важно.
> rpm5 и имеем ввиду, что исправили это всё макросом, смысл которого
> не понимал никто, даже я. ;) Потому мой патч накатывали-откатывали раз 5.Экая у вас подборочка мега-разработчиков. А ты 1 из уволенных оттуда чтоли? Если что с точки зрения манагера логично уволить чела который сам не понимает зачем он делает вон то :)
>> Знатно тот дедушка вас затроллил. fdatasync на каждый чих, из-за которого 1
>> Гиг обновлений устанавливался джва часа на SSD и система на это
>> время вставала колом - это позор.
> Вообще-то так себя ведут практически все пакетники.Какая чушь. Дальше читать нет смысла. И наверняка небезопасно погружаться в маня-мирок.
Ещё раз повторяю неосиленное экспертом: rpm4 так себя не ведёт.
Обычное дело: когда какой нибудь доцент или профессор приписывает как свои собственные научные достижения поделки своих студентов и аспирантов.
Спасибо за ответы. Неожиданно открыл для себя новое
>Спасибо за ответы. Неожиданно открыл для себя новоеа уж сколько я для себя открыл нового в тогдашнем цэ еуропейском "коммерческом опенсорце" и как там все устроено у хранцузских коллег - например, нормальным считалось написать в технической корпоративной переписке мандривы, что "некий условный Жак Кокто сегодня не может выйти на работу по причинам наркотического делирия" и прочая и прочая.. Деньги получать они очень любили, а работу работать почему-то считали западло. Особенно Джефф бесил этим.
Я столько ухи не ел никогда пока с ними работал.
Но сейчас-то все охрошо стало?
>>Спасибо за ответы. Неожиданно открыл для себя новое
> а уж сколько я для себя открыл нового в тогдашнем цэ еуропейском
> "коммерческом опенсорце" и как там все устроено у хранцузских коллег -
> например, нормальным считалось написать в технической корпоративной переписке мандривы,
> что "некий условный Жак Кокто сегодня не может выйти на работу
> по причинам наркотического делирия" и прочая и прочая..Примечательно, кто именно вынес пикантные детали на всеобщее обозрение.
Точно так же как и пришедший после него условный Андрюша Сюрволог написал в официальной группе ВК о том, что Хромиум обновится, когда условный Алзим "выйдет из запоя, или что там у него" (ц).
> Деньги получать они
> очень любили, а работу работать почему-то считали западло. Особенно Джефф бесил
> этим.А условный keleg тогда бегал по ВК с "помогите, люди добрые", или его ещё не было?
> Я столько ухи не ел никогда пока с ними работал.
Может, это заразное? и дело не в "хранцузах"?
> Потом, первый состав сотрудников был жестко уволен наher
> из-за нашествия _новых_ гиперконвергентных высокоэффективных
> менеджеров в топах, да и самой РОСЫ вскорости практически не
> стало благодаря усилиям этих уникальных варягов.Это не те сvo1o4i из POCA, которые доработали FreeIPA, что в нее можно виндовые ПК ввести без костылей, как в родную Active Directory, и управлять настройками пользователей (обои, ярлыки, настройки броузеров...) российскими линуксами через их клиент для FreeIPA? Их гадкий вариант FreeIPA (dd) имеет настоящую древовидную структуру в LDAP, а не эмитирует ее через расширенный атрибут объекта, как у некоторых российских (и западных) компаний (полный аналог есть только RHEIPA без настроек для пользователя). Они заставили Puppet брать конфигурацию для ПК из LDAP.
Там предысторию знать надо. РХ продвинула свой рпм всем как стандарт пакетов. Всё будет совместимо между
совершенно различнийшеми дистрибутивами. Ну максимум может пересобрать придется. Такие юниты в новой системе инициализации, ага.
А потом просто отказывались принимать все изменения. Им не надо. Стандартизировать макросы, как предлагали другие.
Альты кажется могут рассказать часть иcторий про рпм.
Всё больше проектов используют для версии год, месяц.
Выросло поколение...
RPM5 древняя разработка мандрэйка/мандривы из далёких нулевых, у которой были свои плюшки (дельта архивы и прочие, бывшие очень актуальными при dial-up интернете). Но Красная Шапочка, пятую версию отказывалась в апстрим пускать - обещая свои ништяки запилить.
suse прекрасно справилась с дельта-архивами без необходимости патчить сам rpm, средствами мета-пакетменеджера. (А теперь вот - похоронила их в дальнем конце полигона, да, где-то там же где диалап-интернетчиков - затраты на их производство и мерж превосходят в десять раз выгоду от экономии траффика.)А rh решительно не понимала зачем им ломать свою систему ради чужих хотелок.
> suse прекрасно справиласьЭто не та SUSE, которой пользуются три с половиной калеки и у которой в репозиториях хоть шаром покати? Видимо формат пакетов оказался чересчур хорошим.
У них всю дорогу было принято подключать с десяток репозиториев, энтерпрайзненько же.
Именно из-за RPM люблю RHEL-дистрибутивы и им подобные.
Лучше deb ничего на данный момент не придумано.
Лучше pkg.tar.zst в Arch Linux человечество вообще вряд ли когда либо придумает.
Очень "удобное" расширение...
Концепция складывать расширения в стек для виндузятников конечно сложная.
> Концепция складывать расширения в стек для виндузятников конечно сложная.А причём тут "виндузятники"? Или это в привычках линуксоидов делать сложнее и страшнее просто потому что?
Ну почему у dpkg простой и понятный формат .deb (сразу понятно, что для Debian-based систем), .rpm - просто понятно, что пакет для RPM, а pkg.tar.zst... Зачем столько буков? Зачем мне знать, что это tar-архив со сжатием zstd... Для чего мне эта инфа при установке ПО?
> Лучше pkg.tar.zst в Arch Linux человечество вообще вряд ли когда либо придумает.Уже придумало - Ebuild и Port.
>> Лучше pkg.tar.zst в Arch Linux человечество вообще вряд ли когда либо придумает.
> Уже придумало - Ebuild и Port.При том настолько круто и удобно получилось что все носители этой культуры позагибались. И *bsd где-то там, но в общем не с нами, а теперь и гента - на ладан дышит. Софт стал жирный а косплеить билдферму в 1 рыло - дорого, шумно, долго, электричество жрет, комп использовать нормальными способами мешает.
> При том настолько круто и удобно получилось что все носители этой культуры
> позагибались. И *bsd где-то там, но в общем не с нами,
> а теперь и гента - на ладан дышит. Софт стал жирный
> а косплеить билдферму в 1 рыло - дорого, шумно, долго, электричество
> жрет, комп использовать нормальными способами мешает.Благодаря тому, что можно его пересобрать, проекты Gentoo и BSD живут, так как они оптимизируются под конкретную машину, что позволяет выжить максимум из ПК.
Тот же Хромиум на Gentoo жрет на 700 МБ меньше ОЗУ на вкладке с Ютубом, чем на Debian.
Как в твоём deb посмотреть список пакетов явно установленных пользователем без учёта тех которые были установлены во время установки дистрибутива? Можешь не гуглить — никак.
Причем тут deb? Это вопрос к пакетному менеджеру
Сами дистры так и продолжат строить из бинарников, а вот прикладное ПО - да. Это сильно упростит жизнь и разработчикам и пользователям.
apt-mark showmanual
> без учёта тех которые были установлены во время установки дистрибутива
> apt-mark showmanualНа стекоферфлоу у тeбя бы был уже бaн.
По причине?
По причине ответов которые отвечающий сам слышал звон да не знает где он.
Как в твоём rpm посмотреть перечень прямых/обратных зависимостей пакета, ограничив вывод только теми, что установлены в системе?
Во время установки какого дистрибутива? Debian 9, который уже пережил 3 апгрейда до 12? Ах, я же забыл. В redhat нельзя переехать на другую мажорную версию. Вот вы и придумываете странные задачи )))
Т.е. посмотреть какой софт стоит в системе это странная задача? Даже в винде это одним клинком делается. Не удивлен что у вас там в гноме регулировка чувствительности скролла не сделана за десятилетия.
А тебе одну команду для apt ввести сложно? тебя просто жалко.
apt-mark showmanual
> Как в твоём deb посмотреть список пакетов явно установленных пользователем без учёта
> тех которые были установлены во время установки дистрибутива? Можешь не гуглить
> — никак.Можно в apt log посмотреть.
В dnf history тоже можно посмотреть, но речь не об этом.Проблема в том, что APT очень плохо реализует получение информации о пакетах. Надо вытаскивать из чулана какие-то костыли на Perl, обмазываться awk и sed и всячески развлекаться там, где в DNF будет достаточно одной команды.
Невозможно посмотреть содержимое пакета, который не установлен в систему. Или устанавливай, или расчехляй веб-браузер. Если репозиторий неофициальный, качай пакет, смотри что там внутри, не обломишься.
> В dnf history тоже можно посмотреть, но речь не об этом.
> Проблема в том, что APT очень плохо реализует получение информации о пакетах.
> Надо вытаскивать из чулана какие-то костыли на Perl, обмазываться awk и
> sed и всячески развлекаться там, где в DNF будет достаточно одной
> команды.Ну значит не такие это важные команды. К тому же у apt есть биндинг в питону.
> Или устанавливай, или расчехляй веб-браузер
Можно скачать поле Contents с удаденного репозитория без браузера скриптом.
Можно установить apt-file и делать через него.
> Ну значит не такие это важные командыТут всё просто. Когда такие команды есть, ты ими пользуешься. Когда тебе нужно писать скрипты и потом таскать их с собой, ты идёшь на сайт дебиана.
> Можно скачать поле Contents с удаденного репозитория без браузера скриптом.
> Можно установить apt-file и делать через него.Ну да, ну да. Поэтому я выше и написал:
"Надо вытаскивать из чулана какие-то костыли на Perl, обмазываться awk и sed".
Ну или питоном. Во славу лучшего пакетного менеджера.
>> Ну значит не такие это важные команды
> Тут всё просто. Когда такие команды есть, ты ими пользуешься. Когда тебе
> нужно писать скрипты и потом таскать их с собой, ты идёшь
> на сайт дебиана.Пока что ты привел лишь пример одной команды и то сомнительный, чтобы хотеть ее постоянно запускать.
>> Можно скачать поле Contents с удаденного репозитория без браузера скриптом.
>> Можно установить apt-file и делать через него.
> Ну да, ну да. Поэтому я выше и написал:
> "Надо вытаскивать из чулана какие-то костыли на Perl, обмазываться awk и sed".Это не костыли, а отдельная программа для редкой задачи. Они, наверное, лучше знают, что тащить в базовую поставку.
Так и не надо хотеть её постоянно запускать. Нужно просто иметь возможность запустить её на любой машине когда она понадобится, а не приниматься танцевать вприсядку. Потому что это пакетный менеджер, и когда нужно выяснить в чём может быть проблема с пакетом, не время устанавливать перл в систему или вычурно парсить вывод курла.Ты строки в выводе команд тоже вряд ли ежедневно считаешь. Это не значит, что wc не нужна в системе. Хотя можно и питоновским скриптом считать, кто ж запретит.
> Так и не надо хотеть её постоянно запускать. Нужно просто иметь возможность
> запустить её на любой машине когда она понадобится, а не приниматься
> танцевать вприсядку. Потому что это пакетный менеджер, и когда нужно выяснить
> в чём может быть проблема с пакетом, не время устанавливать перл
> в систему или вычурно парсить вывод курла.Во-первых, если у тебя есть apt, то perl тоже есть.
> Ты строки в выводе команд тоже вряд ли ежедневно считаешь. Это не
> значит, что wc не нужна в системе. Хотя можно и питоновским
> скриптом считать, кто ж запретит.В чем проблема? Поставь apt-file. И wc, хотя считаю данное сравнение явным передергиванием, более частая задача, чем получить содержимое неустановленного пакета. А если для тебя она вдруг частая, то добавь скрипт или apt-file в базовый образ.
Есть еще какие-то проблемы кроме этой?)
> Во-первых, если у тебя есть apt, то perl тоже есть.Он там довольно опциональный, если что. В основном debconf'у нужен. Хотя так то есть и cdebconf.
> В чем проблема? Поставь apt-file. И wc, хотя считаю данное сравнение явным
А что, в какой-то системе wc по дефолту нет? Это что за система такая?!
> apt-file в базовый образ.Вот в дебиане это кстати довольно просто - (c)дебутстрапом можно набрать все что душе угодно.
Deb один из худших форматов. Сборка deb-пакета почти всегда боль и страдания. Rpm и pkg гораздо удобнее в плане создания и сборки пакета.
> Deb один из худших форматов. Сборка deb-пакета почти всегда боль и страдания.
> Rpm и pkg гораздо удобнее в плане создания и сборки пакета.Нет там никакой боли.
deb худший во всём
> deb худший во всёмЧтож там такого в .deb плохого от чего избавлен .rpm? В больших градациях.
Вот тебе упражнение. Берёшь исходники примерно любой программы, разумных размеров, с разумным количеством зависимостей. Тебе нужно её собрать и опакетить под Fedora, OpenSUSE и Debian/Ubuntu. И не забудь сделать репозитории для одного, другого и третьего.
> Вот тебе упражнение. Берёшь исходники примерно любой программы, разумных размеров, с разумным
> количеством зависимостей. Тебе нужно её собрать и опакетить под Fedora, OpenSUSE
> и Debian/Ubuntu. И не забудь сделать репозитории для одного, другого и
> третьего.Спасибо вы не из https://skillfactory.ru/ https://practicum.yandex.ru/ случайно?)
Первый раз вижу. Но ты попробуй чтобы почувствовать разницу.Видишь, я даже не предлагаю тебе делать разные репозитории для убунты и дебиана, потому что заранее сочувствую.
> Первый раз вижу. Но ты попробуй чтобы почувствовать разницу.
> Видишь, я даже не предлагаю тебе делать разные репозитории для убунты и
> дебиана, потому что заранее сочувствую.А в чем собссно проблема? Дебиановские репы по крайней мере не используют дикие извраты типа огромных XMLок и еще и бинарных кешей потом в скулайт. И пакеты билдить просто как раз.
А редхатчики развели у себя в пакетной системе дикую помойку. А росисты успешно подхватили знамя. Что они дальше с ними делали, тактично промолчим.
> Вот тебе упражнение. Берёшь исходники примерно любой программы, разумных размеров, с разумным
> количеством зависимостей. Тебе нужно её собрать и опакетить под Fedora, OpenSUSE
> и Debian/Ubuntu. И не забудь сделать репозитории для одного, другого и
> третьего.А зачем? Пусть мейнтейнеры это делают. Это же разделение обязанностей. Они лучше знают свои процессы.
Если же реально нужно, то есть генераторы из одного формата. Ну либо самому такой сделать.
Иногда тебе бывает нужно опакетить программу и сделать локальный репозиторий. Понятно, что потом этим будет заниматься CI. Но тебе придётся написать сборку.Для своего десктопа на один раз может сгодиться и alien, конечно.
> Иногда тебе бывает нужно опакетить программу и сделать локальный репозиторий. Понятно,
> что потом этим будет заниматься CI. Но тебе придётся написать сборку.Для всех дистров что ли? Странная задача. Обычно многие проекты пакуют из коробки по свой дистр.
Для того, который используется в инфраструктуре. Для RPM и создание пакета, и создание репозитория будут попроще.
> Для того, который используется в инфраструктуре. Для RPM и создание пакета, и
> создание репозитория будут попроще.Ну вот вернулись к оригинальному вопросу https://www.opennet.dev/openforum/vsluhforumID3/135028.html#119 Повторю его
> Чтож там такого в .deb плохого от чего избавлен .rpm? В больших градациях.
на что был ответ
> Вот тебе упражнение. Берёшь исходники примерно любой программы, разумных размеров, с разумным количеством зависимостей. Тебе нужно её собрать и опакетить под Fedora, OpenSUSE и Debian/Ubuntu. И не забудь сделать репозитории для одного, другого и третьего.
После чего я спросил, а "зачем так делать?". В итоге пришли опять к неподтврежденному, что rpm проще deb. Вот чем проще то? Что такого есть в rpm, что делает его проще?
> на что был ответ
>> deb худший во всём
> Чтож там такого в .deb плохого от чего избавлен .rpm? В больших
> градациях.
> на что был ответ
>> Вот тебе упражнение. Берёшь исходники примерно любой программы, разумных размеров, с разумным количеством зависимостей. Тебе нужно её собрать и опакетить под Fedora, OpenSUSE и Debian/Ubuntu. И не забудь сделать репозитории для одного, другого и третьего.Благодарю за развернутый ответ)
> Тебе нужно её собрать и опакетить под Fedora, OpenSUSE
> и Debian/Ubuntu. И не забудь сделать репозитории для одного, другого и
> третьего.И не забудь сделать репозитории для одного, другого и
> третьего.Ты мне так и не обьяснил зачем. Целесообразность.
Ну вот смотри, ты задаёшь вопрос> Чтож там такого в .deb плохого от чего избавлен .rpm?
По ссылкам ты всё равно не ходишь, так что просто опакеть, сделай репозитории для deb и rpm и закрой свой вопрос.
Эх. Я как-то пытался собрать пакет J-Link для Debian и ARMbian. Был неприятно удивлен, что пакеты с либами в разных архитектурах внезапно имеют разное название. Есть большой гайд почему это так.
RPM - главная причина почему не юзаю и не рассматриваю rpm-дистрибутивы.
Ну чего удалили мой коммент, про "главная причина это ты, а вторая все твои мечты". Все очень в тему.
на мой взгляд aptitude лучшее изобретение в истории человечества. а он есть только для deb-based и для альта
> на мой взгляд aptitude лучшее изобретение в истории человечества. а он есть
> только для deb-based и для альтаСогласен. Зачем создавать что то новое если предыдущщее выполняет функию.
Улучшать существующее другое.
Все это скоро заменят контейнера и прочие флэтпаки. И это наверное даже хорошо.
Все не заменят. Ибо есть системное ПО, тестируемое создателями дистрибутива, и есть сторонне, или которое можно вынести в сторонне.
То есть, для разных задач нужны разные подходы.Да и флатпаки и снапы пока не отвечают потребностям немногочисленных активных пользователей Linux, и точно будут вытеснены иными инструментами.
> Все не заменят. Ибо есть системное ПО, тестируемое создателями дистрибутиваоспадя... ты правда веришь что какие-то мистические Создатели хоть что-то тестируют, а не "собирается!" ?
Нет совершенно никакой надобности собирать это самое пео попакетиково, с ненужно-зависимостями-зависимостей и ломучей глючной базкой с тормознейшим в мире поиском.
Ничего не мешало бы применить тот же подход что у *bsd - make world и вся недолга. По частям не собирается (ну точнее ты еще можешь попытаться, но жаловаться бестолку - оно так не задумано и не обязано у тебя сработать)
Зачем какой-то корявоос какие-то rpm'ы если ее апгрейдят заменой образа исошника?
Но для "Создателей" и это, разумеется, оказалось слишком сложным, это ж надо свою автоматизацию сборки сразу всего написать. Диды-то наверное месяц ковырялись в первый раз, а наследникам одних митапов надо будет на пять лет вперед расписание составлять.
Поэтому нате вам на лопате rpm-ostree и прочую чушь. Совершенно бесполезную и вредную, дико усложняющую и замедляющую сборки, зато - из готовых кулечков, а не сами чего-то изобретать. Вот, впихоном подмазали чтоб не рассыпалось сразу же, ляп, ляп, и в продакшн!
> Версии RPM 5.x будут пропущены для исключения пересечений с проектом RPM5, который непосредственно не связан с RPM от Red Hat, развивался независимой командой разработчиков и не обновляется с 2016 года.Просто перешагнули. Уважения к сообществу — ноль.
Бедное общество, как оно переживет это...
> Бедное общество, как оно переживет это...Выпустит следующую версию rpm 7
вряд ли - дальше CoC.md и README во всяком случае.Тот дедушка помер или в маразме, новые не знают си.
> Уважения к сообществу — ноль.К кому-кому простите?
Неужели сообщество таки запилило рабочую пятую версию? Или как обычно?))
И за что их тогда уважать?
Если работа закончена, это не означает, что забросили.
Если "о, запускаетсо!" это не значит что работа закончена.
> архив в формате tar, сжатый при помощи gzipАктуальненько. Расскажите дидам про zstd, только сначала разбудите их от анабиоза.
Я до статуса дида ещё не дозрел, но попробую тебе кое-что объяснить.
Пакетный менеджер должен работать на голой свежеустановленной системе, где есть только базовый набор самого необходимого, включая архиваторы. Заменить gz на что-то более новое - это значит сломать всё, и ловить лучи поноса со всех сторон, где у кого-то что-то сломалось. Если же начать напихивать в установочный образ все модные и молодёжные альтернативы (и bz2, и xz, и lz4, и zstd, и что там ещё есть), то одними архиваторами этот процесс не ограничится, все любители обмазываться свеженьким (вроде тебя) начнут требовать добавления в базовый iso'шник своих любимых игрушек.
Кроме того - ничто не даётся бесплатно, в том числе скорость и эффективность архиваторов. Ты сравнивал потребление памяти у gzip и своего zstd? И ты предлагаешь держать два полных комплекта пакетов, для десктопа диванного игромана и для систем с ограниченным объёмом памяти и вычислительной мощности - ну, ок, оплати эти расходы из своего кармана.
> Пакетный менеджер должен работать на голой свежеустановленной системе, где есть только
> базовый набор самого необходимого, включая архиваторы.tar поддерживает zstd с версии около 1.30, минимум 6 лет уже. Это достаточно полежалый товар или нужно ещё лет 20 подождать?
> Заменить gz на что-то более новое - это значит сломать всё, и ловить лучи поноса со всех сторон
Речь о подтягивании архивов в систему. За подтягивание и распаковку отвечает один и тот же процесс. Сломать там что-то можно только перейдя на lossy-сжатие (*петроснян мод*) больше никак нельзя. Для системы никак не видно что там за формат передачи внутри rpm используется. Больше вероятность что-то сломать будет перейдя на актуальную версию TLS, но уж точно не на внутренний формат упаковки архивов.
> Ты сравнивал потребление памяти у gzip и своего zstd?потребление памяти у zstd так же, как и у deflate зависит от размера окна и может умещаться в 1 КБ при желании. Он оптимизирован для стримингово сжатия/разжатия, если что. Тут точно не к чему придраться.
https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_c...
О как, спасибо. Выходит они ещё 5 лет назад на zstd перешли. Припоминаю теперь, что читал что-то такое Fedora 31 https://www.opennet.dev/opennews/art.shtml?num=51771
> В пакетном менеджере RPM задействован алгоритм сжатия Zstd.Видимо просто новость написана так непонятно.
> SRC-пакет с Chromium близок к пределу и имеет размер 3.7 ГБНу может и нафик его, этот Chromium? Это ж трындец какой-то…
По размерам вполне себе дистрибутив
> Объявлен устаревшим синтаксис макросов %patchN (без пробела перед N),
> использование которого теперь будет приводить к ошибкепоэтому теперь ни один старый пакет вы не пересоберете не потрахавшись.
Ну ок.
(дайте угадаю - ашипка будет "ашипка", и выяснить что именно не так вы сможете только часовым чтением release notes...если они там вообще предусмотрены, а не git log)
Напоминаю экспертам, что бывший сотрудник Микрософт и создатель Стэковерфлоу Джоэль Спольски написал в своё время статью «Огонь и движение», где доступно объясняет, зачем RedHat так поступает с клонами. Советую почитать и попробовать заменить у себя в голове штамп "NIH-синдром" хоть чем-то похожим на мысль.
> Напоминаю экспертам, что бывший сотрудник Микрософт и создатель Стэковерфлоу Джоэль Спольски
> написал в своё время статью «Огонь и движение», где доступно объясняет,
> зачем RedHat так поступает с клонами. Советую почитать и попробовать заменитьА те кто не почитали?)
>> Напоминаю экспертам, что бывший сотрудник Микрософт и создатель Стэковерфлоу Джоэль Спольски
>> написал в своё время статью «Огонь и движение», где доступно объясняет,
>> зачем RedHat так поступает с клонами. Советую почитать и попробовать заменить
> А те кто не почитали?)Кто прочёл, но не почитает статью аналогичным "NIH-синдром" штампом противоположной полярности, очевидно, сохранил способность к высшей нервной деятельности, а не одни лишь машинальные реакции на внешний раздражитель, характерные для анонимной экспертизы.
Напоминаю местным зазнайкам, что уважаемый эксперт Аноним, создатель многочисленных комментариев на Опеннете, авторитетно написал статью «Движение ради движения, или как бег на месте помогает осваивать инвестиции олухов», где доступно объясняет, что иногда сигара -- это просто сигара. Все, кто не приобщился и не преисполнился, сразу получают -100 баллов к IQ. (Ссылку на статью я, разумеется, не дам, по причине "не заслужили".)
Упоминания в экспертизе "IQ" настолько достаточно для её оценки, что на последующей ляп "-100" можно закрыть глаза. Ссылку на то, что тесты Айзенка были изменены, поскольку результаты первого варианта очень сильно понравился феминисткам, я, разумеется, не дам - не заслужил даже попыткой объяснить, почему местные дистрибуторы при беге на месте ничего не производят, помимо тепла.
Интересно смогут ли они навязать RPM6 Debian и деривативам как это прокатило с Systemd?
было бы здорово (нет ничего омерзительней формата исходников и самого механизма сборки deb), но увы, они вряд ли захотят.Им как раз очень удобно, что бинарный пакет для rhel даже просто распаковать в другом дистрибутиве требует приседаний с подпрыгами.
> было бы здорово (нет ничего омерзительней формата исходников и самого механизма сборки
> deb), но увы, они вряд ли захотят.В чем омерзительность? не критикую .rpm, но не настолько сильна разница. .deb более распространен. Разве не целесообразней использовать то что более распространенно?.
Если осилишь языки программирования кроме markdown - узнаешь.Целесообразнее использовать то что не вызывает у тебя дополнительного геморроя. И это не отвратительно (считай - не) документированный неуклюжий расширенный make, подсунутый нам создателем дебиана.
Разница настолько сильна. Просто ты тоже, как все кексперты, ни разу в жизни не собрал ни одного пакета.
> Разница настолько сильна. Просто ты тоже, как все кексперты, ни разу в
> жизни не собрал ни одного пакета.Прям сильна сильна разница?) Я еще и notepad не разработал который в windows)
> Если осилишь языки программирования кроме markdown - узнаешь.А markdown это низшая каста?)
А markdown это язык разметки
Впечатлён NP-полнотой закидона по поводу полноты по Тьюрингу.
ты хоть когда-либо на прямо поставленный вопрос ответ-то выдавал осознанный?
каждый раз одна софистика без пруфов.
Нет конечно, для этого нужны знания за пределами вики/форумов.
> Если осилишь языки программированияВопрос целесообразности.
Ну если твоя цель просто написать что-то в комментариях на опеннете, то точно нецелесообразно
> Если осилишь языки программирования кроме markdown - узнаешь.
> Вопрос целесообразности.Вопрос в целесообразности.
Если ты про это> Разве не целесообразней использовать то что более распространенно?
то на этот вопрос ответа вообще быть не может пока ты не расскажешь о цели. Ну и не приведёшь какую-то авторитетную статистику о том что "более распространенно" и где.
Для "наиболее распространённых" хромобуков не имеет смысла использовать ни .deb, ни .rpm.
>> Если осилишь языки программирования
> Вопрос целесообразности.тогда тебе не нужен ответ на вопрос чем rpm лучше деб. Чем лучше датчик дроссельной заслонки ланоса чем у гнили? А какая потребителю разница, если они не взаимозаменяемы, он же на автомобиле едет, а не на датчике.
Вот механик в сервис-центре может иметь какие-то предпочтения, и не хотеть работать с гнили в принципе. Если ты не планируешь выучиться на механика или просто сам в сарае обслуживать свою технику - тебе и объяснять бестолку время терять, и знание это тебе совершенно бесполезно.
Да что ж они себе места не находят... Сколько можно переписывать одно и тоже по десять раз! Они там невменяемые все? Не знают чего хотят? Почему в Дебиане однажды написанное работает десятками лет и не требует переписывания? Ох не завидую я тем кто вынужден иметь дело с rpm-based дистрибутивами...
> Почему в Дебиане однажды написанное работает десятками лет и не требует переписыванияЗато требует Perl
Потому что то гуано что однажды по пьяни написано в дерьмияне - требует не переписывания, а захоронения на свалке особо опасных отходов. Вместе с автором...а, он и так уже.Дай угадаю - ты за всю жизнь самостоятельно ни одного .deb не собрал и тем более не пытался вносить изменения в существующий посложнее хеловрота?
Как и все остальные отметившиеся тут кексперты.
Странно. Как же так получилось, что при таком плохом формате пакетов у Дебиана и его ответвлений пакетная база больше, чем у всех остальных дистрибутивов вместе взятых? Что-то тут не сходится...
потому что эти миллионы хеловротов просто никому не нужны, например?P.S. судя по "аргументам", насчет твоего личного опыта сборки - я угадал.
Если уж у ваятелей "хеловротов" с .deb не возникает трудностей, то надо полагать что у более опытных разрабов их и подавно нет.
> Если уж у ваятелей "хеловротов" с .deb не возникает трудностей, то надо
> полагать что у более опытных разрабов их и подавно нет.Типа которые .deb вы которые .rpm вы их типа хейтите да?) Типа у вас типа клан .rpm а там клан .debiastow?)
> Странно. Как же так получилось, что при таком плохом формате пакетов у
> Дебиана и его ответвлений пакетная база больше, чем у всех остальных дистрибутивов вместе взятых? Что-то тут не сходится..."Логика" не сходится. По таким критериям самый луДьший формат пакетов - msi
Насчёт того, что у "всех остальных дистрибутивов вместе взятых" ты загнул, конечно.Во-первых, дебианщики любят нарезать программы на десяток пакетов.
Во-вторых, у них в репозиториях годами живут не поддерживаемые никем пакеты, у которых мантейнер просто куда-то пропал. Их просто собирают пока они собираются.
При этом случается, что у них не опакечено что-нибудь довольно очевидное, типа распространённых шрифтов.
> Насчёт того, что у "всех остальных дистрибутивов вместе взятых" ты загнул, конечно.
> Во-первых, дебианщики любят нарезать программы на десяток пакетов.
> Во-вторых, у них в репозиториях годами живут не поддерживаемые никем пакеты, у
> которых мантейнер просто куда-то пропал. Их просто собирают пока они собираются.А вдруг кому пригодится.
Это если оно работоспособное.У них там года три назад мантейнер клиента для телеги пропал. Клиент устанавливался и запускался, но сервер отказывался с ним работать из соображений безопасности.
И вот толку-то предоставлять пакеты с нерабочими программами. Зато, да, самые большие репозитории(tm). И такого добра у них в репозиториях навалом.
Поэтому
*Поэтому пакеты за которыми никто не следит не нужно предоставлять. Никто не знает рабочее оно или нет.
> Да что ж они себе места не находят... Сколько можно переписывать одно
> и тоже по десять раз! Они там невменяемые все? Не знают
> чего хотят? Почему в Дебиане однажды написанное работает десятками лет и
> не требует переписывания? Ох не завидую я тем кто вынужден иметь
> дело с rpm-based дистрибутивами...Согласен. В чем такая существенная разница что именно .rpm лучше .deb?.
https://en.wikipedia.org/wiki/Linux_Standard_Base
> https://en.wikipedia.org/wiki/Linux_Standard_Basehttps://ru.wikipedia.org/wiki/Бетон
Ну так в чем же УТП?
По моей ссылке хотя бы есть что-то про deb и rpm.> УТП
Проще собирать, проще распространять, относительно переносимы, соответствуют стандарту.
Но на своём десктопе ты, естественно, не почувствуешь никакой разницы между apt install и dnf install.
А может его пора уже закопать? Nix уже изобретён
>создавать пакеты размером более 4 ГБОни там в fat32 что ли хранят?
> В отличие от rpm2cpio новая утилита преобразует RPM-файл не в архив cpio, а в архив в формате tar, сжатый при помощи gzip.tar крайне плохо работает, когда нужно просто просмотреть индекс/извлечь один единственный файл. При этом у других форматов такой проблемы нет
>В новой ветке также намерены разрешить использование языка C++ для разработки RPMЕщё одно место, где будет портится память
> будет задействован новый формат архива, позволяющий в отличие от ныне используемого формата cpio создавать пакеты размером более 4 ГБчто за новый формат архива?