Bug 37092 - С пакетом gcc8 приезжает нерабочий /usr/bin/gcc
Summary: С пакетом gcc8 приезжает нерабочий /usr/bin/gcc
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: gcc-common (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
: 43436 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-08-09 12:14 MSK by Ivan A. Melnikov
Modified: 2022-08-04 15:35 MSK (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan A. Melnikov 2019-08-09 12:14:29 MSK
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.
Comment 1 Dmitry V. Levin 2019-08-09 12:23:46 MSK
(In reply to comment #0)
> Steps to reproduce:
> 
> - установите свежий ALT, не содержащий инструменты разработки (например,
> какую-нибудь regular-jeos)
> - решите покомпилировать какой-нибудь код на C
> - установите пакет gcc8

Мне кажется, что более естественным действием в такой ситуации было бы установить пакет gcc.  Чтобы догадаться установить gccN вместо gcc, надо обладать бОльшим знанием.

> Ожидание: /usr/bin/gcc либо не будет, либо оно будет работать.

Как этого добиться без циклических зависимостей?
Comment 2 Ivan A. Melnikov 2019-08-09 12:36:34 MSK
(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 либо не будет, либо оно будет работать.
> 
> Как этого добиться без циклических зависимостей?

Я пока только решил, что это проблема, так что пусть повисит. Над решением я ещё не думал.
Comment 3 Ivan A. Melnikov 2020-11-17 13:09:38 MSK
(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? Они же выставляются по порядку и тогда последний победит.
Comment 4 Dmitry V. Levin 2020-11-29 17:48:15 MSK
(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 перестанут использоваться,
хорошо ли это?
Comment 5 Gleb F-Malinovskiy 2022-08-03 14:18:22 MSK
*** Bug 43436 has been marked as a duplicate of this bug. ***
Comment 6 Iakunin Andrei 2022-08-04 07:33:50 MSK
Появление нерабочих ссылок из пакетов вида gcc-common, gcc-fortran-common однозначная бага.

Если в них лежит ссылка на, например,  gcc-12|gcc-12-fortran, а без этого пакета ссылка остаётся не рабочей, то надо убрать эти ссылки из пакета *-common.
Пусть common остаётся пустым метапакетом, а ссылки на gcc&gcc-fortran тащит с собой текущая версия компилятора.

Можно оставить один из пакетов gcc - gcc{current_version} пустым метапакетом и положить в зависимости другой из них.

Главное исключить ситуацию появления в системе нерабочих ссылок при штатной установке пакетов.


Есть много причин почему люди ставят конкретную версию, а не "версию по-умолчанию". Примеры:
1) Софт требует конкретной версии.
2) Хотят зафискировать конкретную версию для сборки пользовательских приложений. Чтоб при смене выбранного разработчиками компилятора не менялась сборка нужных пакетов. Это часто бывает в среде с присутствием регулятора, когда нужно сохранить поведение. Важно и для научных расчётов, когда изменение оптимизаций меняет и сходимость(да, программа не должна быть такой, но реальный мир суров).

А что там лежит в *-common, никто не знает, но ставят для гарантии.
Comment 7 Dmitry V. Levin 2022-08-04 12:40:37 MSK
(In reply to Iakunin Andrei from comment #6)
> Появление нерабочих ссылок из пакетов вида gcc-common, gcc-fortran-common
> однозначная бага.

Уточните, пожалуйста, что вы называете ссылками.
Comment 8 Iakunin Andrei 2022-08-04 15:07:53 MSK
> Уточните, пожалуйста, что вы называете ссылками.

Если пользователь устанавливает пакеты 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.
Comment 9 Dmitry V. Levin 2022-08-04 15:35:54 MSK
(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 явно.

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