LINUX.ORG.RU

Fedora Linux 43

 

Fedora Linux 43

2

4

Представлен релиз дистрибутива Fedora Linux 43. Для загрузки подготовлены продукты Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Server, Fedora IoT, Fedora CoreOS, Fedora Cloud Base, Fedora IoT Edition, Fedora Silverblue, Fedora Kinoite и Live-сборки, поставляемые в форме спинов c пользовательскими окружениями Xfce, MATE, Cinnamon, LXDE, Phosh, Miracle, LXQt, Budgie, Sway и Cosmic. Сборки сформированы для архитектур x86_64, Power64 и ARM64 (AArch64).

Наиболее значимые изменения в Fedora Linux 43:

  • Рабочий стол в Fedora Workstation обновлён до ветки GNOME 49, а в Fedora KDE Plasma Desktop Edition до KDE Plasma 6.4 и KDE Gear 25.08. Обновлены версии пользовательских окружений Sway 1.11, Budgie 10.9.3, COSMIC-beta.
  • Из репозиториев удалены пакеты, используемые для работы GNOME поверх X-сервера. Все пользователи GNOME, использовавшие X11, будут принудительно переключены на сеанс GNOME на базе Wayland. Возможность запуска X11-приложений при помощи XWayland остаётся без изменений.
  • На системах с архитектурой x86 оставлена только возможность использования таблиц разделов GPT (GUID Partition Table) во всех установках Fedora, использующих UEFI. Поддержка установки Fedora в режиме UEFI на диски с таблицами разделом MBR (Master Boot Record) прекращена на системах x86, но оставлена на системах ARM и RISC-V. Размер раздела /boot увеличен с 1 до 2 ГБ.
  • Осуществлён переход на пакетный менеджер RPM 6, примечательный поддержкой нового формата, позволяющего создавать пакеты размером более 4 ГБ. Включение по умолчанию появившихся в RPM6 средств проверки подлинности пакетов с использованием цифровой подписи отложено до выпуска Fedora 44.
  • Все spin-сборки и Fedora KDE Plasma Desktop Edition переведены на новый вариант инсталлятора Anaconda, в котором вместо интерфейса на основе библиотеки GTK используется web-интерфейс, допускающий взаимодействие через web-браузер для удалённого управления установкой. В прошлом выпуске новый инсталлятор был задействован в Fedora Workstation. Вместо главного экрана с перечнем действий в новом интерфейсе работа организована в форме мастера (Wizard), подразумевающего последовательное выполнение определённых шагов без возвращения к основному экрану. В качестве базового предлагается автоматизированный (guided) режим разбивки диска, при котором инсталлятор сам выбирает параметры создания или изменения разделов на основе настроек, выбранных пользователем. Имеются опции для переустановки дистрибутива и установки в режиме двойной загрузки на системах с несколькими ОС.
  • Инсталлятор переведён на использование пакетного менеджера DNF5 при установке RPM-пакетов (в системе DNF5 используется начиная с Fedora 41). Базовая функциональность управления пакетами в DNF5 вынесена в отдельную библиотеку libdnf5, вместо привязок к PackageKit задействован DNF Daemon, а компоненты на Python переписаны на С++.
  • Из инсталлятора удалена поддержка отдельно обновляемых модулей, жизненный цикл которых не привязан к основной начинке дистрибутива, а сопровождение осуществляется независимо от релизов дистрибутива, что позволяло обеспечить сосуществование пакетов с разными версиями одного и того же приложения.
  • В Fedora Kinoite, атомарно обновляемом варианте Fedora c KDE, включено по умолчанию автообновление системы. Обновления теперь загружаются без спроса пользователя в фоне и применяются после перезагрузки. В настройках имеются опции для отключения автообновления и изменения интервала проверки наличия обновлений.
  • В разряд устаревших переведён ассемблер YASM, последнее обновление для которого было выпущено в 2019 году. Пакеты, в которых YASM использовался для сборки (включая Firefox) переведены на сборку при помощи NASM.
  • Разделена на несколько пакетов поставка GnuPG - программа gpg, вспомогательные утилиты и сервисы GnuPG теперь распространяются в отдельных пакетах (gnupg2, gnupg2-dirmngr, gnupg2-g13, gnupg2-gpgconf, gnupg2-gpg-agent, gnupg2-keyboxd, gnupg2-scdaemon, gnupg2-smime, gnupg2-wks, gnupg2-utils и gnupg2-verify).
  • Реализована возможность использования механизма Intel TDX (Trusted Domain Extensions) для шифрования оперативной памяти гостевых систем (AMD SEV поддерживается с Fedora 41).
  • Добавлены пакеты с инструментарием для языка программирования Hare, развиваемого автором пользовательского окружения Sway. Язык оптимизирован для решения низкоуровневых задач, таких как разработка операционных систем, компиляторов, сетевых приложений и системных утилит, для которых требуется достижение максимальной производительности и полный контроль над выполнением. В языке применяется ручное управление памятью и статическая система типов, при которой каждой переменной явно должен быть присвоен определённый тип.
  • При сборке пакетов на языке Go задействован инструментарий Go Vendor Tools, при котором копии используемых библиотек включаются в состав src-пакета, а не применяются отдельно поставляемые пакеты с зависимостями (т.е. не используются общие для всей системы версии библиотек).
  • Выполнен переход на использование шрифтов Noto Color Emoji в векторном формате COLRv1 вместо растрового представления. Использование COLRv1 позволило добиться повышения качества отрисовки и уменьшения размера файлов со шрифтами.
  • Для сжатия образов начального RAM-диска (initrd) задействован алгоритм Zstd при сборке с использованием Dracut. Переход с xz на zstd позволил сократить на несколько мегабайт размер initrd и ускорить загрузку.
  • Задействован вариант инструментария Greenboot, переписанный на языке Rust (старая версия была написана на bash). Greenboot применяется в атомарно обновляемых вариантах Fedora для проверки состояния системы при загрузке и отката на прошлую версию при обнаружении проблем.
  • Обновлены версии: LLVM 21, GCC 15.2, binutils 2.45, glibc 2.42, gdb 17.1, Go 1.25, Python 3.14, Java 25, Maven 4, Perl 5.42, Haskell GHC 9.8, Apache Tomcat 10.1.x, Ruby on Rails 8.0, PostgreSQL 18, MySQL 8.4, Dovecot 2.4.

Для Fedora 43 введены в строй репозитории «free» и «nonfree» от проекта RPM Fusion, в которых доступны пакеты с дополнительными мультимедиа приложениями (MPlayer, VLC, Xine), видео/аудио кодеками, поддержкой DVD, проприетарными драйверами AMD и NVIDIA, игровыми программами и эмуляторами.

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

★★★★★

Проверено: CrX ()
Ответ на: комментарий от PcheloBiaka

есть некоторый процент пакетов м библиотек активно развивающихся и мутирующих сильно. Для них в зависимостях (разработчик дистрибутива) ставит явные зависимости от версий таких-то. Проблема решена

Разница между часто и редко обновляющимися библиотеками лишь в частоте появления таких проблем, но сами проблемы фундаментально одни и те же, поэтому это ничего не решает. Значит, нужно указывать такие зависимости от версии для всех библиотек, независимо от частоты их обновления. А если для каждой библиотеки указывать зависимости от версии, то приходим… к подходу deb и rpm.

В Арче обновляя пакет foo я не могу проигнорировать то, что библиотека от которой он зависит осталась бы не обновлённой, если она тоже обновляется.

Если обновлять только пакет foo, то сможете.

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

И в Федоре, Дебьяне, Убунте, РедХате и везде тебе бы сказали ровно то же самое, если бы ты сказал, что обновил то-то, но это не обновлял и теперь у тебя не работает

Нет, в таком случае это означало бы неправильно прописанные зависимости, не обеспечивающие работу пакета, и это считалось бы багом.

Итого, проблемы сонейм, как бы, и не существует

Она существует фундаментально, и от её отрицания она не исчезнет.

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

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

Если же обновлять всё разом, то всё равно возможны случаи вроде этого Если бы ты сам почитал то обсуждение… error: failed to prepare transaction (could not satisfy dependencies) :: installing libdisplay-info (0.2.0-1) breaks dependency ‘libdisplay-info.so=1-64’ required by gamescope :: installing libdisplay-info (0.2.0-1) breaks dependency ‘libdisplay-info.so=1-64’ required by wlroots Что это, если не подтверждение моих слов? В Арче МОЖНО иметь такие зависимости. Но! Всё это происходит в тестовой ветке, идёт абочее окружение. Тебе принести обсуждения Дебьяна и Федоры в разработке?

Во вторых Щет хапенится иногда. Везде. Я доведённый вымороженными багами Дебьяна сбежал на Арч (вообще даже Манджару) и, внезапно, забыл как в консоль лазить! Я не маскирую пакеты, а не колдую пытаясь заставить работать то, что, казалось бы, после тщательного тестирования не должно было пройти в дистры, всё тупо работает.

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

Извините я вас не понимаю.

Реп как реп, ничем не отличается от обычных репов.

вот к примеру откуда то у меня валяется такой файл:

cat /etc/yum.repos.d/_copr\:copr.fedorainfracloud.org\:phracek\:PyCharm.repo

[copr:copr.fedorainfracloud.org:phracek:PyCharm]
name=Copr repo for PyCharm owned by phracek
baseurl=https://download.copr.fedorainfracloud.org/results/phracek/PyCharm/fedora-$releasever-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://download.copr.fedorainfracloud.org/results/phracek/PyCharm/pubkey.gpg
repo_gpgcheck=0
enabled=0
enabled_metadata=1

Какой то чел phracek собирает под федору PyCharm, правда этот реп у меня по умолчанию вырублен.

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

Если бы ты сам почитал то обсуждение

…то увидел бы кучу людей, у кого сломалось.

В Арче МОЖНО иметь такие зависимости

Никто и не утверждал, что нельзя. Однако нет общей политики использования таких зависимостей, поэтому каждый пляшет, как хочет. Сопровождающий wlroots вот указал soname, а сопровождающие KDE и GNOME нет.

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

Всё это происходит в тестовой ветке

С чего вы взяли? Насколько понимаю, всё это происходило в extra, а не в extra-testing.

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

Рядом с кнопкой «Поместить», отправляющей сообщение, есть кнопка «Предпросмотр» — советую, помогает.

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

Увидеть ты увидел, а то, что починили увидел? А блокирующие и не блокирующие релиз ошибки других дистрибутивов почитаем? (мне лень)

Вообще… Ты настолько неправильно смотришь на эту проблему, что ты просто не даёшь мне шансов выйти на реальную проблему в Арчеподобных, но ладно, хватит уже.

Я пошёл отдыхать, завтра опять спасать вселенную. Хорошего дня всех святых у католиков и дня усопших у них же.

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

Увидеть ты увидел, а то, что починили увидел?

Ясное дело что починили, однако сначала же сломали.

В том же Debian unstable подобные рассинхронизации тоже не редкость, однако там apt успешно предотвращает подобные проблемы, потому что версия ABI закодирована в имени пакета библиотеки, и поэтому soname bump приводит к появлению нового пакета, а не новой версии того же самого пакета. (Это ещё и в подавляющем большинстве случаев позволяет одновременно установить и libfoo2, и libfoo3, что позволяет и обновить систему, и не ломать пакеты, которые всё ещё зависят от прошлой версии библиотеки.)

А блокирующие и не блокирующие релиз ошибки других дистрибутивов почитаем?

См. выше.

Кроме того, ещё раз, в случае Arch речь шла не о тестовой ветке, а о вполне даже основной.

Ты настолько неправильно смотришь на эту проблему, что ты просто не даёшь мне шансов выйти на реальную проблему в Арчеподобных

Я обсуждал конкретную проблему; любые другие, в арчеподобных или нет, — это уже совсем другой разговор.

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

См. выше. Я уже насмотрелся на Дебьян. Я так насмортелся и на Стэйбл и на Тестинг и на Сид и писал багрепорты и всякое. Не решает это проблемы, а создаёт её. Из-за потенциального «а вдруг не работает, мы же не знаем» ломались зависимости, обновление (по мануалу) с релиза на релиз приводило в состояние тыквы и мой комп и мою голову. dpkg-reconfigure -a и apt-get –fix-broken и прочие до сих пор шрамом на мозгу лежат. Да что там, в прошлом месяце мой Дебьян на работе грохнул одну программу, не досмотрел, обновился, а она пропала. Вручную ставил обратно, но поскольку проглазел почему удалило, не могу конкретнее сказать.

А ты меня спроси какой командой Арч чинить? А я не знаю. Я НЕ ПОМНЮ уже команды обновления из консоли, потому что не ломалось ничего. Это показатель? По крайней мере в рамках моего опыта - явный. Ярчайший.

Есть разные подходы, и это хорошо, взгляд на проблему с разных сторон нужен. Но пользоваться в конечном итоге надо лучшим (Манджарой) Точка :))

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

А что теперь в профиле нельзя по умолчанию поставить разметку?

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

Да осильте ж вы разметку наконец, чуть не пропустил ответ внутри цитаты.


в прошлом месяце мой Дебьян на работе грохнул одну программу, не досмотрел, обновился, а она пропала

apt upgrade даже теоретически не может удалить программу, потому что ему запрещено удалять пакеты.

Если же использовали apt full-upgrade (или устаревший синоним apt dist-upgrade), то ССЗБ же, что не читаете список, тем более что в APT 3 он отображается уж нагляднее некуда.

А ты меня спроси какой командой Арч чинить? А я не знаю. Я НЕ ПОМНЮ уже команды обновления из консоли, потому что не ломалось ничего. Это показатель? По крайней мере в рамках моего опыта - явный. Ярчайший.

Ну а я на Debian уже 15 с хвостиком лет, и ни разу не возникало описываемых вами проблем ни с обновлением внутри выпуска, ни с обновлением с выпуска на выпуск. Всё настолько просто работает, что от скуки поставил unstable на подвернувшийся под руку ноутбук.

Понимаете, да? — личный опыт вообще не показатель, потому что на каждый ваш личный опыт найдётся ровно противоположный. Я рад за вас, что у вас всё так хорошо работает, — пользуйтесь на здоровье! — но лучше приводить техническую аргументацию, а не эмпирическую.

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

Если же использовали apt full-upgrade (или устаревший синоним apt dist-upgrade), то ССЗБ же, что не читаете список, тем более что в APT 3 он отображается уж нагляднее некуда.

С одной стороны согласен, а с другой стороны… А как это получается? Один и тот же пакет (вообще не важно который) из системных репозиториев при обновлении удаляется (действительно глупо, просмотрел почему), а потом легко и непринуждённо устанавливается вручную из тех же репозиториев? Такое в принципе не должно быть! Или пакет не соответствует и мы его ужаляем, или он соответствует и тогда «Позвольте, Господа! Какого хрена?»

Ну а я на Debian уже 15 с хвостиком лет

Хорошо, у тебя консистентный опыт на одной системе. Очень узкая протоптаная дорожка и успех. А у меня широкие интересы. И приложения стоят самые разные и на разных туллкитах иногда по два-три приложения на одну задачу. Например, смотрелки PDF, или рисовалки, или текстовые редакторы. Или музыкальные программы. И рассчётных всяких в ассортименте. Мне постоянно что-то интересно, как это сделано у других, пробую, удаляю, устанавливаю ещё. Живое всё. На всех системах. И дистрибутивов перебрал много и на опыте оценил чужие заявления. На багтрекерах видел ошибки, разбираясь в очередной проблеме. Мне есть с чем сравнивать.

Единственное чего я избегал - плотного исследования Федоры. rpm-дистры я тоже прошёл, Росу, Альт, Опензюзю и даже Оракл (очень недолго). И как-то я не заметил плюсов rpm перед deb. Всё как-то по горизонтали. Я Арч выбрал не потому, что кто-то сказал и рассказал про soname ужасы, а потому что в работе это самый беспроблемный дистр из всех, что я видел. По опыту, а не по чьим-то рассказам. Если хочешь аргументировано меня забороть, поставь Манджару и расскажи как в ней ужасно :)

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

Блин. Не могу редактировать. Ещё хотел заметить - сидя на Арче и прочих дистрибутивах со свежим софтом пользователь может принимать активное участие в разработке софта, отсылая отчёты об ошибках и предлагая свои улучшения. На Дебьяне это бессмысленно. Это так, заметочка о том, кто вкладывается в развитие.

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

Один и тот же пакет (вообще не важно который) из системных репозиториев при обновлении удаляется (действительно глупо, просмотрел почему), а потом легко и непринуждённо устанавливается вручную из тех же репозиториев? Такое в принципе не должно быть! Или пакет не соответствует и мы его ужаляем, или он соответствует и тогда «Позвольте, Господа! Какого хрена?»

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

Хорошо, у тебя консистентный опыт на одной системе. Очень узкая протоптаная дорожка и успех. А у меня широкие интересы

Из того, что я на Debian много лет, не следует, что у меня не было других систем на другом моём железе. Нельзя замыкаться в своём тесном мирке. Поэтому и Fedora была, и openSUSE, и Arch побывал. Manjaro вот не пробовал, и нет желания.

сидя на Арче и прочих дистрибутивах со свежим софтом пользователь может принимать активное участие в разработке софта, отсылая отчёты об ошибках и предлагая свои улучшения. На Дебьяне это бессмысленно

Так Debian stable и аналогичные дистрибутивы как раз и задуманы для тех, кто хочет не «принимать активное участие в разработке софта», а просто использовать компьютер как инструмент для решения своих задач. Поэтому у меня Debian stable был и остаётся основной системой для личных и рабочих задач. С тем же успехом я мог бы использовать и условный RHEL — никаких проблем.

А если кому-то хочется «вкладываться в развитие», для тех есть роллинги. Как я уже говорил, у меня вот Debian unstable сейчас установлен, а до него там был Arch и openSUSE TW. Но это не системы, в которых я могу быть уверен, что сегодня они будут работать точно так же, как вчера, а завтра — как сегодня, поэтому круг выполняемых на них задач довольно узок.

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

Ты знаешь свой инструмент, рукоятка слилась с рукой, это всё понятно. И я не агитирую конкретно за Манджару. И то, что ты посматриваешь по сторонам тоже хорошо, но кроме тго, что ты в них не уверен должны бы были последовать доводы с примерами. Совершенно необязательно детальными. Мы же не в адвокатской конторе, я тебе поверю, если ты скажешь, что вот, пол года назад ловил баг с сонеймами, или что-то подобное. Я про тот пакет из Дебьяна не говорю конкретно потому, что сам сглупил, не прочитал причину удаления, но это в данной ситуации не важно, это прецедент. Это нечто неправильное, что не из древних воспоминаний о Потате и переходом на Сардж.

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

Ну вот, теперь я точно не могу написать «Honey! I’m hoome!» :))) опередил

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

Обновляешь систему? Обновляй разом. Иначе твои ошибки это твои проблемы.

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

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

И да и нет. Прочти полностью мой тезис. Если ты принесёшь им баг такого плана, тебя попросят обновиться полностью. Именно это и имеют в виду разработчики Арча. Ты МОЖЕШЬ на Арче обновить систему частично. И будет работать, но возможны проблемы. Ровно как и везде.

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

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

Я просто не считаю такой личный опыт чем-то существенным.

Ну хорошо, где-то полгода назад yay сломался, потому что pacman обновился, и его библиотека, которую yay использует, получила soname bump. Пришлось заново его клонить и собирать руками. Это при том, что обновлялся я через yay, а не pacman. Как по мне, такие ситуации менеджер пакетов обязан отлавливать.

Но в Arch и деривативах меня больше раздражает связанная с этой проблемой русская рулетка с частичным обновлением: вот есть в новой версии программы баг, и вместо того чтобы запинить конкретно эту программу на рабочей версии, пока тот баг не починят в апстриме и не соберут новую версию в Arch, я по-правильному должен заморозить всю систему. И казалось бы, хрен бы с ней, но если баг починят только через несколько месяцев, мне эти несколько месяцев без обновлений безопасности сидеть? Или прокрутить барабан на свой страх и риск таки добавить пакет в игнор и надеяться, что пронесёт?

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

Я лично юзаю Федору так как хочу заранее поюзать и привыкнуть к тому что через некоторое время будет во всех дистрибутах линукса.

А потом?

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

Ну хорошо, где-то полгода назад yay сломался, потому что pacman обновился Очень хороший пример. С программой из аура. (Программа Изаура, надо такой сериал снять) И тут как раз причина почему лично я сижу на Манджаро. Это как раз проблема арча,о которой я сначалане мог ввернуть из-за неправильного направления :))

Итак. Ты установил систему и стороннее приложение не заблокировало его. Это полностью противоположно тому что происходило у меня в Опензюзе и почему я с опаской смотрю на Copr. Арч в этом выигрывает. Дальше следовало бы пересобрать ауровские пакеты, но тебе снесло именно программу работающую с ауровскими пакетами.

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

В Манджаре же решили эту проблему. Они используют штатный, свой, внутренний Pamac и вокруг него построили всё остальное. Ты не окажешься в ситуации, когданечем ставить пакеты (в том числи и из аура). Это то из-за чего я с Манджарыещё долго неслезу. А то, что у Pamac есть ещё и графический интерфейс удобный - оставляет его вообще без конкуренции (для меня лично).

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

Я не раз блокировалконкретный пакет у себя в Манджаре и держал месяцами. Ждал апстримовскмх исправлений. Система обновлялась и всё работало. Ни разу не столкнулся с поломаной системой в результате. И вообще, за эти годы я переустанавливал Арч не потому что он сломался, а потому что я должен был быть в курсе чего там сделали нового, или от того, что так загадил сисиему лишними пакетами, что быстрее было бы наново всё поставить, а не вычищать ошмётки докеров, флатпаков и искать какие пакеты неиспользуемые. (Кстати, ко спискам неиспользуемых пакетов ВО ВСЕХ дистрибутивах и пакетных менеджерах у меня претензии. Они дезинформируют. Они вредительские)

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

Да что за хрень… Блин… Нафига до и после комментария оставлять пусстую строку? И отредактировать не могу. @Rootlexx, там опять в цитату попал мой ответ

PcheloBiaka
()

Вах шайтанама... вот буквально сейчас в федуру 43 завезли кеды 6.5.1.

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

С программой из аура. (Программа Изаура, надо такой сериал снять)

А мне какая разница, откуда программа? Я хочу использовать программу, а она сломана — всё, точка. И меня в данной ситуации совершенно не интересует, из AUR она была установлена или нет.

Ты установил систему и стороннее приложение не заблокировало его. Это полностью противоположно тому что происходило у меня в Опензюзе и почему я с опаской смотрю на Copr. Арч в этом выигрывает

Ещё разок спрошу: разве в zypper нельзя обновить те пакеты, которые можно обновить, пропустив оные со сломанными зависимостями? Когда что-то таким образом «ломается» в Debian unstable, то apt спасает меня от проблем, просто пропуская такие пакеты.

Я не раз блокировалконкретный пакет у себя в Манджаре и держал месяцами. Ждал апстримовскмх исправлений. Система обновлялась и всё работало

Это ошибка выжившего из разряда «Я постоянно перехожу дорогу на красный свет и всё ещё жив → переходить дорогу на красный свет безопасно». Вы сыграли в русскую рулетку и пока ещё не застрелились. Поздравляю. Но есть чисто технические причины, почему такая схема абсолютно ненадёжна, зависит от случая и обязательно рано или поздно сломается, поэтому «я всё ещё живой» не сходит за аргумент, уж извините.

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

А мне какая разница, откуда программа?

Ты себ со стороны не слышишь. У тебя предубеждение и… шифтинг… как это по русски…. Вобщем ты когда про Дебьян говорят бросаешься разбирать каждую проблемочку говоря «тут всё от деталей зависит», а как Арч, то «какая мне разница, я топором рублю и мне пофигу!». А дело именно в деталях. Когда я писал о проблемах при переходе с релиза на релиз ты, среди прочих, утверждал мне, что «при обновлении сначала удали всё стороннее! Дебьян так не работает!!!». Помнишь? Мы с тобой не в первый раз спорим по этому поводу. И вот на Аре ты имеешь дело не просто со сторонним приложением, а с приложением которое должно тебе рулить системой! И тебе пофигу… Обалдеть.

Я бы сказал, что авторы этой утилиты должны были бы позаботиться о правильной последовательности обновления, потому что они сидят вовне. Это как в Минте жаловаться на пакет foo из убунтовских репозиториев. А чего Минт сделает? они присоски! Так и сторонняя утилита в Арче - это присоска. Если ты ей пользуешься, то ТЫ должен учитывать это делая обновления. Всё очень просто. А тут давай всё же обсуждать то, что происходит с пакетами ВНУТРИ Арча, Дебьяна, Федоры.

Я потому боюсь сторонние репы всегда подключать. Потому федоровский Фьюжн меня напрягает и потому OBS и Copr мне не выглядят надёжными. А ведь там просто левый софт, который может сломать обновление. А ты СамоЁ, Корень всей твоей системы ломаешь и говоришь «а мне пофигу!»… Я понимаю, у тебя отрицание, это значит мы идём в правильную сторону :) Манджара ещё долго будет существовать, я не тороплсь :)))

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

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

Не помню. И сам так не делаю, и не помню, чтобы кому-то советовал. В отдельных конкретных случаях это может быть нужно, например в случае конфликтов, но в общем случае это излишне. Ссылку дайте.

И вот на Аре ты имеешь дело не просто со сторонним приложением, а с приложением которое должно тебе рулить системой!

Сторонние репозитории в Debian имеют намного меньшее отношение к Debian, чем AUR к Arch. У последнего даже ссылка есть прямо на главной странице.

А вообще, удобно выходит: как надо похвастаться количеством ПО, так AUR неотделим от Arch и является одним из основных его преимуществ, а как заходит речь о проблемах, так это сразу левый репозиторий, проблемы с которым нельзя переносить на Arch…

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

Не помню.

Не удивлён. :)

В отдельных конкретных случаях это может быть нужно, например в случае конфликтов

А речь и была о том, что конфликты ломают всё. Это давненько уже было. И про обновление системы с дебьяновскими бэкпортами мне тоже говорили «дурак! сначала отключи бэкпорты!!!». Но не помню кто это был. Да и не важно. Этакий дух дебьяносторонников. (просто наблюдение)

Сторонние репозитории в Debian имеют намного меньшее отношение к Debian, чем AUR к Arch. Я понимаю, что поднимаю очень старые темы, но когда-то это было с дебьяновскими мультимедиарепами, которые они не могли включить в основной репозиторий по причине лицензии. А не так давно были проблемы именно с обновлением системы с бэкпортами. И не переход на следующую версию Дебьяна, а так, среди релиза устанавливая обновления. Не помню уже подробностей, да и не важно. Я хотел обратить твоё внимание - В Дебьянах сторонние (совершенно необязательные теоретически) пакеты ломали мне обновление и ты говорил, что надо разобраться, А тут ты ломаешь ГЛАВНУЮ программу которой ставишь пакеты не потому что арч такой тупой, а потому что она в стороннем ауре (где как и в obs и copr просто предоставляется площадка) и разработчики этой программы явно должны были предупреждать у себя на сайте о таком, но ты проигнорировал всё потому что аур принадлежит арчу, значит они и должны вместо тебя решать то как ты обновляешь систему.

Я отказываюсь серьёзно рассматривать поломку стороннего пакетного менеджера когда ты проигнорировал условия его использования и предупреждения. Дай другой пример и не из аура, а из репозитория Арча, который сломался у тебя потому что пакман такой ужасный. Про Аур я и говорил, что возможны поломки, что надо пересобирать всё в ауре, это часть обновления. Единственное что я признаю тут, что ты стал заложником ситуации, что пакетный менеджер которым ты пользуешься сторонний. Но представь я в Дебьяне поставил бы какойнить yet-another-apt и ругался бы на дебьянщиков. Какая была бы твоя реакция?

А вообще, удобно выходит: как надо похвастаться количеством ПО, так AUR неотделим от Arch и является одним из основных его преимуществ, а как заходит речь о проблемах, так это сразу левый репозиторий, проблемы с которым нельзя переносить на Arch…

Где я заявлял про неделимость? Были бы Арч и Аур неделимыми, средства управления пакетами из аура лежали бы прямо в основном репоитории. И тут я всё равно нахожусь ы более выгодном положении по сравнению с оригинальным арчем, потому что на Манджаре эта проблема решена основательно. Это действительно круто.

И очень жаль, что ты отказываешься слышать доводы. Но я увезу тебя в лес, привяжу к дереву и дооолго долго буду расказывать про Манджару. :))))

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

Вот они, новые технологии, пришли в другие дистрибутивы, что дальше? Ведь надо теперь осваивать новые, которые завтра будут везде. Зачем этот процесс, если технологию можно понять потом, когда она придёт туда, где находишься ты?

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

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

а то завтра примут что то типа такого: https://www.cnews.ru/news/top/2025-10-29_chastnomu_biznesu_prigotovitsya

И я без проблем смогу перейти на Астру или РедОс. А если я к примеру буду изучать и привыкать к АРЧу то мне это зачем? Чтобы когда нибудь купить стеамдек? У меня даже мыслей нет как сделать локальный реп АРЧа …

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

Не удивлён. :)

Так ссылка будет или нет? А то окажется, что и не говорил, и не я, и вообще речь о погоде шла.

И про обновление системы с дебьяновскими бэкпортами мне тоже говорили «дурак! сначала отключи бэкпорты!!!».

Эээ, бэкпорты специально собираются из testing, чтобы когда тот стал следующим stable, всё обновилось без проблем.

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

Других личных примеров конкретно этой проблемы за где-то полгода использования не встретилось, однако это неважно: суть в том, что проблема может произойти, она уже неоднократно происходила у других (см. пример с display-info), и есть технические предпосылки для её проявления и в будущем. Для меня этого достаточно, чтобы не доверять тому, что простое обновление штатными средствами не превратит мне какую-нибудь программу или всю систему в тыкву.

Если вас этот риск устраивает — ради бога, пользуйтесь на здоровье. Меня — нет.

Но представь я в Дебьяне поставил бы какойнить yet-another-apt и ругался бы на дебьянщиков. Какая была бы твоя реакция?

yay ведь не зря сломался, а потому что он использует libalpm. Т.е. это не совершенно левый менеджер пакетов, а просто другой интерфейс над арчевским менеджером пакетов. Как, например, aptitude и nala — это другие интерфейсы над libapt-pkg.

Так что в проблеме виноваты таки pacman с его libalpm и политика Arch, не обеспечившие проверку soname до установки пакетов. Точно так же как в аналогичной ситуации был бы виноват apt и его libapt-pkg.

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

И это тоже лично меня отталкивает: зачем мне иметь зоопарк менеджеров пакетов в системе? И если уж AUR управляется отдельным менеджером пакетов, то почему не добавить его в основной репозиторий?

То, что в Manjaro с этим лучше, — это плюс. Ну, когда они не ддосят AUR, конечно. 😉

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

yay ведь не зря сломался, а потому что он использует libalpm

Нет. Потому что он небыл пересобран людьми разбирающимися в том, что они делают. Ты пользуешься СТОРОННИМ приложением. Что ещё написать, чтобы ты понял суть проблемы? https://wiki.archlinux.org/title/AUR_helpers

AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.

Красным по белому написано. Если бы все эти обёртки находились ВНУТРИ арчевского репозитория я бы согласился это обсуждать и сиюминутно признал бы свою неправоту. Но ты не поймёшь никак. Поэтому я напишу ещё раз. Я терпеливый.

YAY находится не в составе официальных инструментов Арча. Его обновление является чисто твоей заботой. Чтобы работало хорошо в Арче ты должен это обеспечить. Если хочешь, чтобы всё поддерживалось хорошо, поставь CachyOS, там он входит в основной репозиторий. Они тоже позаботились, чтобы не сломалось при обновлении. Или ты должен понимать что ты делаешь, или разработчики должны. Разработчики Арча не рассматривают ни одной обёртки над их пакетным менеджером как официальной. Они просто рассказывают о том, что они есть.

Как, например, aptitude и nala — это другие интерфейсы над libapt-pkg.

Ты понимаешь, что они находятся ВНУТРИ твоего Дебьяновского репозитори? Ты понимаешь, что они собираются каждый раз со всеми пакетами вместе на серверах Дебьяна? Это отличает их от стороннего yay? А теперь представь, я скомпиляю aptitude тупо из исходников сам, потом обновлю систему, но не обновлю свою сборку и пойдут ошибки. Кто виноват? (Я точно также буду тоять задрав нос и говоря, что «ничегонезнаюонисамидолжныработатьправильно!!!»)

И это тоже лично меня отталкивает: зачем мне иметь зоопарк менеджеров пакетов в системе? И если уж AUR управляется отдельным менеджером пакетов, то почему не добавить его в основной репозиторий?

Мешает то, что ты игнорируешь очевидное. Это тот шаг, который каждый пользователь решает для себя. Есть много (мноооого!!!) разных вариантов, на твоём yay свет клином не сошёлся. Ты его поставил просто потому что нашёл в чьём-то совете. Но их больше. И они разные. И может даже лучше решают проблемы.

То, что в Manjaro с этим лучше, — это плюс. Ну, когда они не ддосят AUR, конечно. Не хотели, чтобы Манджара ддосила, теперь их другие ддосят, да так крепко, что прям не радостно. А ту проблему уже давно решили. Идея, на самом деле, была классная. Я набирал текст и незамедлительно появлялись варианты. Было просто здорово. Просто надо было реализовать это как-то по другому. Может создавать локальный кэш и из него тащить. Но вот, в CachyOS, оказывается, даже твой любимый нелюбимый yay есть искаропки.

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

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

Нет. © Потому что у него нет ни явной, ни неявной зависимости от версии ABI библиотеки, которую он использует. Так же как и у значительного числа пакетов в самом Arch.

Если хочешь, чтобы всё поддерживалось хорошо, поставь CachyOS, там он входит в основной репозиторий. Они тоже позаботились, чтобы не сломалось при обновлении

Ха три раза. Сколько там раз KDE ломалось за последние месяцы? Ситуация, когда Qt обновилась из репозитория Arch, и поэтому KWin из репозитория CachyOS превратился в тыкву и встречает пользователя чёрным экраном, повторялась больше одного раза за последние несколько месяцев.

Так что спасибо, но я как-нибудь обойдусь. Тем более что роллинги в принципе не обеспечивают тот же уровень предсказуемости, что дают релизные дистрибутивы.

А теперь представь, я скомпиляю aptitude тупо из исходников сам, потом обновлю систему, но не обновлю свою сборку и пойдут ошибки. Кто виноват? (Я точно также буду тоять задрав нос и говоря, что «ничегонезнаюонисамидолжныработатьправильно!!!»)

Так в том и суть, что если вы корректно соберёте aptitude в пакет (как делают AUR-helper’ы), то ничего не сломается! Потому что aptitude получит зависимость от определённой версии ABI libapt-pkg, и поэтому или apt откажется обновлять библиотеку, чтобы не сломать aptitude, или же установит новую версию библиотеки рядышком со старой, и aptitude продолжит работать.

Это тот шаг, который каждый пользователь решает для себя. Есть много (мноооого!!!) разных вариантов, на твоём yay свет клином не сошёлся.

В чём проблема добавить разные? Никто ж не говорил про установку по умолчанию. DE же тоже каждый пользователь выбирает для себя, однако ж это не мешает иметь их разные в репозитории.

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

Потому что у него нет ни явной, ни неявной зависимости от версии ABI библиотеки, которую он использует. Так же как и у значительного числа пакетов в самом Arch.

А кто не даёт внести правильную зависимость? Ты мог бы принести реальную помощь yayюзерам вместо нытья. Я иногда сообщаю об ошибках проектам, которыми не собираюсь пользоваться. Потому что порядок должен быть в библиотеке.

Сколько там раз KDE ломалось за последние месяцы? Ситуация, когда Qt обновилась из репозитория Arch, и поэтому KWin из репозитория CachyOS превратился в тыкву и встречает пользователя чёрным экраном, повторялась больше одного раза за последние несколько месяцев.

Не слышал об этом. Трэшак. Ну, значит не зря я на Манджаре. Спасибо, что предупредил.

Так в том и суть, что если вы корректно соберёте aptitude в пакет (как делают AUR-helper’ы), то ничего не сломается!

И что на планете Земля тебе не дало собрать Yay правильно? А раз такую важную программу ты ставишь сам, то за ней должен следить ктоооо? Тот, кто живёт в озере.

В чём проблема добавить разные?

Во первых консенсуса нет. Был момент, приняли одну прогу, тут же полезли со всех сторон калеки с требованиями убрать. И с тех пор это принципиально. Да и ответственности за Аур они не берут. Хотя, видишь? Сколько сил прилагают, чтобы вирусню искать и отбиваться от ддосов. Но это только площадка для добросовестных пользователей. И по моему глубокомму убеждению, человек не заботящийся о своём пакетном менеджере, не входящем в основной состав дистрибутива - сам себе злобный буратин. Я вон, на Pamac репорты иногда пишу, помогаю, учайствую кое как. А ты, Валентин - халявщик!

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

А кто не даёт внести правильную зависимость?

Тот же, кто и остальным 100500 проектам, спустя рукава опакеченным в Arch+AUR. Во-первых, нет общей технической политики, обязывающей делать правильно. Во-вторых, в отличие от систем, в которых зависимости от разделяемых библиотек прописываются при сборке автоматически, в Arch это ручная работа, со всеми негативными следствиями ручной работы ленивых кожаных мешков.

Ты мог бы принести реальную помощь yayюзерам вместо нытья

И почему же вы не принесли реальную помощь пользователям того же openSUSE и не исправили те проблемы, о которых ныли тут ранее?

А раз такую важную программу ты ставишь сам, то за ней должен следить ктоооо?

Очевидно, что если она собрана в виде пакета, то следить за соблюдением зависимостей пакета должен менеджер пакетов. Удивительное — рядом, да.

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

нет общей технической политики, обязывающей делать правильно

Нет. Делают они в целом всё правильно. Потому что ты так и не смог привести примера кроме этого надуманного.

Нет, привёл, но про CachyOS, разработчики которого должны были отладить процесс. Не всё сразу, научатся. Но это опять сторонние проблемы.

Очевидно, что если она собрана в виде пакета, то следить за соблюдением зависимостей пакета должен менеджер пакетов. Удивительное — рядом, да.

У тебя претензии к пакетному менеджеру yay, а виноват Арч. Так и запишем, устойчивое когнитивное искажение.

Где кишки кровь и трагедии разрушившие жизнь? Где вентилятор раскидывающий бедных пользователей Арча лопастями сонейма, я вас спрашиваю?

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

Нет. Делают они в целом всё правильно. Потому что ты так и не смог привести примера кроме этого надуманного.

А это что?

After updating libdisplay-info to version 0.2.0-1 and restarting, Arch booted into a black screen

I was unable to login because GNOME shell started with a crash screen on boot.

Расскажите этим и остальным, что это им привиделось.

У тебя претензии к пакетному менеджеру yay, а виноват Арч. Так и запишем, устойчивое когнитивное искажение.

Так и запишем: неумение читать и воспринимать прочитанное.

yay ведь не зря сломался, а потому что он использует libalpm. Т.е. это не совершенно левый менеджер пакетов, а просто другой интерфейс над арчевским менеджером пакетов. […] Так что в проблеме виноваты таки pacman с его libalpm и политика Arch, не обеспечившие проверку soname до установки пакетов

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

А это что?

Это случайность. Намного меньшая, чем, например, выкинутые из Дебиана пакеты, посреди жизненного цикла релиза(!!!), у которых не осталось сопровождающего и он не пересобрал его под обновления безопасности и теперь не устанавливается потому что бла-бла-сонейм. Щет хаппенс.

Я, кстати, не нарвался на эту проблему, хотя у меня квин. Знаешь почему? (а обновляюсь я всегда, нарвался бы на эту проблему)

Повторю. К Yay претензии у тебя должны быть вообще не связанные с дистрибутивом, любым. Его работа неправильная. Точка. Они не должны вести себя как короли вселенной сидя на обочине.

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

Это случайность

Называйте, как душе угодно. Меня интересуют лишь надёжность и предсказуемость моей основной рабочей системы, и если такие «случайности» нет-нет да случаются, то мне с такой системой не по пути. Тем более что есть фактические технические предпосылки для продолжения таких «случайностей».

Я, кстати, не нарвался на эту проблему, хотя у меня квин. Знаешь почему?

Очевидно, потому что у вас не Arch?

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

«Этот фиговый полурабочий форк mutter работает как умерший гулаговец, в общем, не работает, следовательно mutter фигня», ты щас буквально это сказал. Если ты будешь в своих убеждениях об x нести тейк, что xy фигня, проблема может быть не в x а в y, не подумал?

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

Конкретно проблема с soname не в yay, ибо тот использует для разрешения зависимостей libalpm. Кроме того, ровно та же проблема есть и с «родными» пакетами Arch.

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

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

если такие «случайности» нет-нет да случаются, то мне с такой системой не по пути.

Пофиксил.

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

Пофиксил, прямо как в Manjaro протухший сертификат.

Удаление из репозитория¹ какого-то непопулярного пакета, для которого стало невозможно осуществлять поддержку безопасности, это совсем не то же самое, что «я обновил систему, и теперь у меня чёрный экран». Искренне ваш, К.О.

¹ И только из репозитория. Этот пакет останется у тех, кто его уже установил, т.е. простое выполнение обновления ничего не сломает. А поскольку обновления в стабильном выпуске не ломают ABI, то пакет продолжит работать, как работал, если пользователя устраивает окончание его поддержки.

Разумеется, было бы лучше, если бы такого не происходило, и это, конечно, всё равно косяк. Вопрос лишь в сравнительной оценке рисков и последствий.

Rootlexx ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.