LINUX.ORG.RU
Форум — Talks  

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

 , ,


0

3

Решил домой поставить gcc посвежее. Зашёл в репы убунты - 11 версия. Ну ок, куда ни шло. Но может есть что посвежее? Зашёл на сайт gcc - там пусто и ветер гуляет, кроме как собрать из исходников других вариантов не предлагается. Ну ок, но у нас же 2024, куча стильных-модных-молодёжных установщиков, дай думаю попробую.

  1. Итак, nix. Это трындец, граждане. Во-первых, он не умеет сам себя апгрейдить и юнисталировать. А знаете как там выполняется поиск пакетов? А вот так:

nix search nixpkgs gcc –extra-experimental-features nix-command –extra-experimental-features flakes

Да-да, вот такой вот портянкой. Но хуже того, у них в 2024 поиск пакетов (судя по флагам) до сих пор экспериментальная фича.

И увы, nix быстро продемонстрировал, почему: запуск поиска наглухо повесил мне линукс.

  1. Следующим идёт snap

snap search gcc

Результат
Name              Version     Publisher      Notes    Summary
orangecalc        1.5.8       gcclinux       -        Orange Calculator Lite is a Simple Java Calculator!
smalltextpad      1.4.1       gcclinux       -        SmallTextPad is a Simple Java Text Editor with Encryption!

Забавно. Следующий.

  1. Flatpak

flatpak search gcc

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

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

Весело. Шёл 2024 год, а у аналогов apt поиск по пакетам до сих пор не «летает», у nix - даже не ползает. В общем, поставил свежий gcc из ppa.

Update: nix при установке мне ещё и кучу пользователей насоздавал, которые видны при логине в систему.

★★★★★

Последнее исправление: next_time (всего исправлений: 1)

 ← 1 2 3 →
Ответ на: комментарий от Andrew-R

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

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

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

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

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

hateyoufeel ★★★★★
()

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

(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

две страницы? похоже, ты даже им пользоваться не умеешь, что не отменяет всратость поиска в 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

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

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

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

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

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

arkhnchul ★★
()

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

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

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

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

Windows 11 ждет тебя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

s-warus ★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sanyo1234 ☆
()

Самый лучший пакетный менеджер - это 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.
doctor_rodik
()
Ответ на: комментарий от doctor_rodik

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ага, щаз. По факту, зависимости дублируются по 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 скопирована множество раз.

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

Я давно не тыкал 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 проверяет зависимости

grim ★★☆☆
()
Последнее исправление: grim (всего исправлений: 1)

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

avas1
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)
 ← 1 2 3 →
Talks