Steps to reproduce: - установите свежий ALT, не содержащий инструменты разработки (например, какую-нибудь regular-jeos) - решите покомпилировать какой-нибудь код на C - установите пакет gcc8 Ожидание: /usr/bin/gcc либо не будет, либо оно будет работать. Реальность: $ gcc test.c /usr/bin/x86_64-alt-linux-gcc: No such file or directory Я что-то помню, что это известное поведение и где-то уже обсуждалось. Очевидно, что опытный альтовод догадается поставить пакет gcc. Но всё-таки такое поведение выглядит как минимум странно, особенно для пользователей, мало знакомых с ALT.
(In reply to comment #0) > Steps to reproduce: > > - установите свежий ALT, не содержащий инструменты разработки (например, > какую-нибудь regular-jeos) > - решите покомпилировать какой-нибудь код на C > - установите пакет gcc8 Мне кажется, что более естественным действием в такой ситуации было бы установить пакет gcc. Чтобы догадаться установить gccN вместо gcc, надо обладать бОльшим знанием. > Ожидание: /usr/bin/gcc либо не будет, либо оно будет работать. Как этого добиться без циклических зависимостей?
(In reply to comment #1) > (In reply to comment #0) > > Steps to reproduce: > > > > - установите свежий ALT, не содержащий инструменты разработки (например, > > какую-нибудь regular-jeos) > > - решите покомпилировать какой-нибудь код на C > > - установите пакет gcc8 > > Мне кажется, что более естественным действием в такой ситуации было бы > установить пакет gcc. Чтобы догадаться установить gccN вместо gcc, надо > обладать бОльшим знанием. Да, люди знают, что хотят восьмой gcc, но не уверены, как это правильно в ALT. Вопросы мне задают. > > Ожидание: /usr/bin/gcc либо не будет, либо оно будет работать. > > Как этого добиться без циклических зависимостей? Я пока только решил, что это проблема, так что пусть повисит. Над решением я ещё не думал.
(In reply to Dmitry V. Levin from comment #1) > Мне кажется, что более естественным действием в такой ситуации было бы > установить пакет gcc. Чтобы догадаться установить gccN вместо gcc, надо > обладать бОльшим знанием. Сегодня наткнулся на ещё один сценарий: можно в систему без gcc поставить kernel-headers-modules-<flavor>. $ rpm -qR kernel-headers-modules-un-def | grep gcc gcc9 > > Ожидание: /usr/bin/gcc либо не будет, либо оно будет работать. > > Как этого добиться без циклических зависимостей? В этой ситуации, кстати, /usr/bin/gcc работает если явно выставить GCC_VERSION. Может быть, паковать в gccN какой-нибуть /etc/profile.d/gcc-00N-is-default.sh с выставлением GCC_VERSION в N? Они же выставляются по порядку и тогда последний победит.
(In reply to Ivan A. Melnikov from comment #3) > (In reply to Dmitry V. Levin from comment #1) > > Мне кажется, что более естественным действием в такой ситуации было бы > > установить пакет gcc. Чтобы догадаться установить gccN вместо gcc, надо > > обладать бОльшим знанием. > > Сегодня наткнулся на ещё один сценарий: можно в систему без gcc поставить > kernel-headers-modules-<flavor>. > > $ rpm -qR kernel-headers-modules-un-def | grep gcc > gcc9 > > > > Ожидание: /usr/bin/gcc либо не будет, либо оно будет работать. > > > > Как этого добиться без циклических зависимостей? > > В этой ситуации, кстати, /usr/bin/gcc работает если явно выставить > GCC_VERSION. Может быть, паковать в gccN какой-нибуть > /etc/profile.d/gcc-00N-is-default.sh с выставлением GCC_VERSION в N? Они же > выставляются по порядку и тогда последний победит. Конечно, но тогда все ссылки /usr/bin/* из пакета gcc перестанут использоваться, хорошо ли это?
*** Bug 43436 has been marked as a duplicate of this bug. ***
Появление нерабочих ссылок из пакетов вида gcc-common, gcc-fortran-common однозначная бага. Если в них лежит ссылка на, например, gcc-12|gcc-12-fortran, а без этого пакета ссылка остаётся не рабочей, то надо убрать эти ссылки из пакета *-common. Пусть common остаётся пустым метапакетом, а ссылки на gcc&gcc-fortran тащит с собой текущая версия компилятора. Можно оставить один из пакетов gcc - gcc{current_version} пустым метапакетом и положить в зависимости другой из них. Главное исключить ситуацию появления в системе нерабочих ссылок при штатной установке пакетов. Есть много причин почему люди ставят конкретную версию, а не "версию по-умолчанию". Примеры: 1) Софт требует конкретной версии. 2) Хотят зафискировать конкретную версию для сборки пользовательских приложений. Чтоб при смене выбранного разработчиками компилятора не менялась сборка нужных пакетов. Это часто бывает в среде с присутствием регулятора, когда нужно сохранить поведение. Важно и для научных расчётов, когда изменение оптимизаций меняет и сходимость(да, программа не должна быть такой, но реальный мир суров). А что там лежит в *-common, никто не знает, но ставят для гарантии.
(In reply to Iakunin Andrei from comment #6) > Появление нерабочих ссылок из пакетов вида gcc-common, gcc-fortran-common > однозначная бага. Уточните, пожалуйста, что вы называете ссылками.
> Уточните, пожалуйста, что вы называете ссылками. Если пользователь устанавливает пакеты gcc10-fortran и gcc-fortran-common Но не ставит(!) пакет gcc12-fortran Тогда появляется symlink: usr/bin/gfortran -> gcc Но этот synlink не работает, поскольку gfortran через gcc вызывает $ gfortran /usr/bin/x86_64-alt-linux-gfortran: No such file or directory Т.е. gcc-fortran-common создаёт ссылки, которые выдают ошибку. $ rpm -ql gcc-fortran-common /usr/bin/f77 /usr/bin/f95 /usr/bin/g77 /usr/bin/gfortran Я попробовал это описать в смежной баге https://bugzilla.altlinux.org/43436 Как я понимаю, похожая проблема с gcc-common.
(In reply to Iakunin Andrei from comment #8) > > Уточните, пожалуйста, что вы называете ссылками. > > Если пользователь устанавливает пакеты gcc10-fortran и gcc-fortran-common > Но не ставит(!) пакет gcc12-fortran > > Тогда появляется symlink: usr/bin/gfortran -> gcc > > Но этот synlink не работает, поскольку gfortran через gcc вызывает > $ gfortran > /usr/bin/x86_64-alt-linux-gfortran: No such file or directory > > > Т.е. gcc-fortran-common создаёт ссылки, которые выдают ошибку. Но это не битые ссылки, а вполне рабочие, с вменяемой диагностикой. Схема gcc - gccN - gcc-common была реализована для того, чтобы - можно было установить несколько версий gcc одновременно; - при этом была версия gcc по умолчанию; - при этом при каждом запуске gcc можно было выбрать желаемую версию. Да, если не установить пакет gcc, то gcc без явного выбора версии не сможет запустить никакой версии gcc, но это неудобство легко обойти, либо установив пакет gcc, либо выбрав версию gcc явно. По-видимому, реализованная схема - лучшая из возможных для решения поставленной задачи, но вы, конечно, можете попробовать придумать что-то ещё лучшее.
*** Bug 45800 has been marked as a duplicate of this bug. ***
