Почему в 2024 году apt до сих пор самый лучший пакетный менеджер на примере gcc

Картина тушью: лежит дракон под горой, и ковыряет себе в зубах с помощью карьерного экскаватора ….

А рядом экскаваторщик забивает гвозди микроскопом.

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

Внимание вопрос: как в NixOS обновить НЕ ВСЕ пакеты? Я вот уже шестой год пользуюсь, а до сих пор не знаю. Ну кроме как тащить две разных версии nixpkgs себе в конфиг, либо долбиться с nix-env.

на серверах софт ставится через Docker

А в докерах Святой Дух?

Результат - миллион ошибок вида:

(flatpak search:14284): GLib-CRITICAL **: 01:42:13.284: g_once_init_leave: assertion ‘g_atomic_pointer_get (value_location) == 0’ failed

Кривой дистр?

[whbex@wbx-desktop ~]$ flatpak search gcc
Имя   Описание              ID Приложения    Версия Ветвь  Удаленные репозитории
TheI… IDE for cross-platfo… …timatepp.TheIDE 2023.2 stable flathub
STM3… Integrated Developme… …st.STM32CubeIDE 1.12.0 stable flathub

Хотя ставить гцц из флатпака это ещё тот мазохизм.

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

Он не пошёл. Он самоудалился с ЛОР 16 лет назад и с тех пор его посещения проходят по одному и тому же алгоритму: сам набросил, сам придумал ответ, сам обиделся.

на серверах софт ставится через Docker

А в докерах Святой Дух?

А в докерах что угодно, часто вообще npm install.

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

А зиппер апту😀. Зиппер реально очень тормозной по сравнению с ним.

Внимание вопрос: как в NixOS обновить НЕ ВСЕ пакеты?

Насколько я знаю, никак, это такой trade-off в дизайне. В Nix вообще нет версий пакетов, есть только конкретная версия nixpkgs, зато она всегда условно-рабочая и не имеет никаких конфликтов в версиях.

Ну кроме как тащить две разных версии nixpkgs себе в конфиг

Это основной способ. Ну или если у тебя есть конкретный проект где это надо, то в nix-shell.

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

Насколько я знаю, никак, это такой trade-off в дизайне. В Nix вообще нет версий пакетов, есть только конкретная версия nixpkgs, зато она всегда условно-рабочая и не имеет никаких конфликтов в версиях.

Я в курсе, на самом деле :)

Просто это очень частый юзкейс у типичного юзера компа. Типа, вот вышел новый emacs и я не хочу ради него тащить 100500 гигабайт апдейтов и обновлять KDE.

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

Ага, щаз. По факту, зависимости дублируются по 100500 раз.

Description: Ubuntu 22.04.4 LTS

Системные пакеты обычно через apk (потому как Alpine), а для конкретной прилаги — через пакетный менеджер соответствующего ЯП.

две страницы? похоже, ты даже им пользоваться не умеешь, что не отменяет всратость поиска в apt-e:

это Ubuntu 20.04.6 LTS:

sudo apt-cache search '^gcc-[0-9]+$'
gcc-9 - GNU C compiler
gcc-10 - GNU C compiler
gcc-7 - GNU C compiler
gcc-8 - GNU C compiler

это openSUSE Leap 15.5:

zypper se -s -r 8 /^gcc[0-9]+$/
Загрузка данных о репозиториях...
Чтение установленных пакетов...

S | Name  | Type  | Version                      | Arch   | Repository
--+-------+-------+------------------------------+--------+-----------------------
v | gcc7  | пакет | 7.5.0+r278197-4.30.1         | x86_64 | openSUSE-${releasever}
  | gcc8  | пакет | 8.2.1+r264010-150000.1.6.4   | x86_64 | openSUSE-${releasever}
  | gcc9  | пакет | 9.3.1+git1296-1.6.1          | x86_64 | openSUSE-${releasever}
  | gcc10 | пакет | 10.4.0+git2794-150000.1.9.1  | x86_64 | openSUSE-${releasever}
  | gcc11 | пакет | 11.3.0+git1637-150000.1.11.2 | x86_64 | openSUSE-${releasever}
  | gcc12 | пакет | 12.2.1+git416-150000.1.7.1   | x86_64 | openSUSE-${releasever}

это только с основной репой, без апдейтов из SLE - где есть 13, и тем более без devel:gcc - в которой есть от 3.3 до 14

А сколько страниц в инете на тему «the following packages have been kept back»

ситуация насамделе довольно редкая, и обычно у апта таки есть довольно веские причины не обновлять вот эти самые пакеты, которые held back. Хотя сообщение могло бы быть и поинформативнее, да.

А ещё можно поржать на тему того, что apt умудряется ставить пакеты так, что они потом не работают:

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

Решил домой поставить gcc посвежее. Зашёл в репы убунты - 11 версия.

Я всегда говорю, что LTS не надо использовать, надо использовать всегда саму свежую убунту, тогда таких проблем не будет.

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

Windows 11 ждет тебя.

как в NixOS обновить НЕ ВСЕ пакеты? Я вот уже шестой год пользуюсь, а до сих пор не знаю. Ну кроме как тащить две разных версии nixpkgs

Тащить две вручную написанные дефиниции.

как в NixOS обновить НЕ ВСЕ пакеты? Я вот уже шестой год пользуюсь, а до сих пор не знаю. Ну кроме как тащить две разных версии nixpkgs

Тащить две вручную написанные дефиниции.

Ну начинается. Остальные дистры могут, nixos не может. Ясно-понятно!

16 лет человека продолжает сюда что-то тянуть. Это уже похоже на зависимость.

Я всегда говорю, что LTS не надо использовать, надо использовать всегда саму свежую убунту,

Тогда уж Арчик? :)

тогда таких проблем не будет.

Ещё меньше проблем, когда на хостах нет Бауинты, а для запуска сборок используются контейнеры.

какие остальные? арч не может например

https://wiki.archlinux.org/title/system_maintenance#Partial_upgrades_are_unsupported

Рач – днищедистр. Даже rpm может лол!

pkgsrc уже советовали?

Не надо, они полноэкранное меню убрали, ханурики пакистанские

У арча пакетная база шире убунтовской, если AUR учитывать.

и свежее, я если что дебиановец, но что есть, то есть

Ровно наоборот.

Причём тут флатпак? Флатпак для GUI приложений, компиляторам там нет места.

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

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

Беды начинаются, когда нужны менее тривиальные вещи. Типа свежие кеды, свежая меса, запуск сторонних бинарников, смена конфигурации «на лету» и т.п. Тут юзер сталкивается с философией дистрибутива - его разработчики решают не проблемы пользователя, а занимаются развитием функционального подхода к управлению пакетами/дистрибутивом, где на первом месте стоит повторяемость результата и чистота. Если задача в рамках концепта nix не имеет эффективного решения, то это проблема твоей проблемы.

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

Думаю, не взлетит эта игрушка в ОС. Нельзя программистам философствовать на работе – только в свободное время и за свой счёт.

Скоро пакеты на сайте ставить начнут.

Уже. Расширения для Гнома ставятся на сайте через браузерное расширение.

ситуация насамделе довольно редкая

В дебиане. В убунте эта ситуация довольно частая, потому что в убунте есть механизм PhasedUpdates.

Идея этого механизма в том, что, чтобы не убивать всех пользователей сразу новыми пакетами, в которых могут быть регрессии. Убунту-разработчики могут пометить некоторые пакеты как частично готовые, и такие пакеты будут распространяться не сразу, а кусочками по 10% аудитории через каждые 6 часов.

Беда в том, что apt изначально не рассчитан на такую работу. Поэтому часть пользователей получит новые пакеты, а все остальные получат «packages have been kept back». Именно поэтому 90% запросов в интернете от пользователей Ubuntu — в Debian этого механизма просто нет.

Это штатная работа apt-get. Никакой сломанной системы пользователи не получают. Через пару дней пакеты обновятся у всех, либо, если в них найдут регрессии, через большее количество дней. Но если очень хочется, в интернете есть рецепты, как сломать себе систему, исправляя эту ошибку.

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

Тут юзер сталкивается с философией дистрибутива - его разработчики решают не проблемы пользователя, а занимаются развитием функционального подхода к управлению пакетами/дистрибутивом, где на первом месте стоит повторяемость результата и чистота. Если задача в рамках концепта nix не имеет эффективного решения, то это проблема твоей проблемы.

IMHO NixOS хорошо подходит для контейнеров и как доп опция частично для DevOps. Для юзеров есть дистры попроще.

Самый лучший пакетный менеджер - это guix

Ищем имеющиеся версии guix search gcc-toolchain

Запускаем shell с выбранной версией guix shell gcc-toolchain@13.2.0

И готово

user:~ $ gcc --version
gcc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Ищем имеющиеся версии guix search gcc-toolchain

А почему для GUIX такой ужасный веб поисковик пакетов? И даже нет mono v6.latest ?

Просто это очень частый юзкейс у типичного юзера компа. Типа, вот вышел новый emacs и я не хочу ради него тащить 100500 гигабайт апдейтов и обновлять KDE.

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

В традиционных дистрах это не всегда прокатит, вот вышел новый emacs, он зависит от PyPoo1.3, а оказывается что KDE 5.1.3 зависит от PyPoo-1.2 и они между собой не совместимы. Если честно я давно перевел почти всё приложения для продуктивности на флатпак, кроме IDE, из-за такой лажи.

Ага, щаз. По факту, зависимости дублируются по 100500 раз.

Я верю но все равно хотелось бы пример.

Для юзеров есть дистры попроще.

Если честно декларативность иногда намного лучше траха с типичными гайдами по линуксу. Я после перехода на NixOS на десктопе стал намного меньше красноглазить (парадокс). Если задача решена в nixpkgs, то её решение сводится к прописыванию нужной опции. Нет возможности безвозвратно испоганить систему всякими make install, обновления практически беспроблемные.

Правда когда задача выходит за рамки Nix то да начинается кошмар :)

IMHO NixOS хорошо подходит для контейнеров и как доп опция частично для DevOps. Для юзеров есть дистры попроще.

По идее, подход должен хорошо работать для ситуаций, которые вписываются в порядок работы «описал окружение (желательно без гуи)» -> «собрал окружение» -> «загрузился в окружение» -> «вместо внесения изменений в окружение начинаешь с первого пункта». Типа сделать лайвсиди или запустить какой-нибудь сервис из заранее подготовленного конфига. Ну, еще развернуть окружение для сборки ПО, хотя это можно сделать просто с никсом (без ОС).

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

А с zfs rollback есть на любом другом дистре (включая любую другую ось с поддержкой хотя бы diskless via NFS/iSCSI)?

Ага, щаз. По факту, зависимости дублируются по 100500 раз.

Я верю но все равно хотелось бы пример.

 ▲ /nix/store ls|grep -E "[a-z0-9]{32}-glibc-2.38-..$"
0f2n754l0l826ald06j7230wvsxj7ibb-glibc-2.38-27
7jiqcrg061xi5clniy7z5pvkc4jiaqav-glibc-2.38-27
7rkf77imj7c7q9b5rgg8m2w3rjq05pkq-glibc-2.38-44
8mc30d49ghc8m5z96yz39srlhg5s9sjj-glibc-2.38-44
9y8pmvk8gdwwznmkzxa6pwyah52xy3nk-glibc-2.38-27
cyrrf49i2hm1w7vn2j945ic3rrzgxbqs-glibc-2.38-44
gqghjch4p1s69sv4mcjksb2kb65rwqjy-glibc-2.38-23
p3jshbwxiwifm1py0yq544fmdyy98j8a-glibc-2.38-27
qcssalnxr02k3fyr3n6lvrb4p842k8n2-glibc-2.38-27
x999l88j5rw8rfx9c16ba5jfrrw4l24k-glibc-2.38-44

Одна только glibc скопирована множество раз.

Я давно не тыкал dpkg, но когда тыкал, зависимости он проверял.

Вы точно уверены?

Я погуглили и вот вам результат

https://linuxsimply.com/linux-basics/package-management/dependencies/dpkg-install-dependencies/

The output shows that a package named libminizip1 is the dependency and it is not installed.

But as dpkg can’t install dependencies automatically, it will show a dependency error like this.

Т.е. dpkg проверяет зависимости

Зашёл в репы убунты - 11 версия. Ну ок, куда ни шло. Но может есть что посвежее?

Как бы:

• https://wiki.ubuntu.com/ToolChain
• https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa

Ну и один из лучших инструментов для сборки свежим gcc приложений со свежими зависимостями: https://easybuild.io/ хоть и заточен для HPC

easybuild всё еще зависит от distutils, который выпилили в Python 3.12. Поэтому conan - наше всё.

не лучший, лучшая система управления пакетами это Portage