$ sudo apt-get install freeglut-devel Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: freeglut-devel 0 upgraded, 1 newly installed, 0 removed and 1 not upgraded. Need to get 0B/8817B of archives. After unpacking 30.0kB of additional disk space will be used. Committing changes... Preparing... ################################################################################################### [100%] file /usr/include/GL/glut.h from install of freeglut-devel-2.4.0-alt1 conflicts with file from package libmesa-devel-7.1-alt1.pre E: Error while running transaction
(In reply to comment #0) > file /usr/include/GL/glut.h from install of freeglut-devel-2.4.0-alt1 conflicts with file from package libmesa-devel-7.1-alt1.pre > E: Error while running transaction Совершенно верно, эти devel-пакеты нельзя ставить одновременно по совершенно очевидной причине. В чём состоит багрепорт да еще и с серьезностью major?
(In reply to comment #1) > Совершенно верно, эти devel-пакеты нельзя ставить одновременно по совершенно > очевидной причине. В чём состоит багрепорт да еще и с серьезностью major? Мдаа. Очевидно, в том, что файловые конфликты не оформлены пакетными конфликтами.
(In reply to comment #2) > (In reply to comment #1) > > Совершенно верно, эти devel-пакеты нельзя ставить одновременно по совершенно > > очевидной причине. В чём состоит багрепорт да еще и с серьезностью major? > > Мдаа. ?? > Очевидно, в том, что файловые конфликты не оформлены пакетными конфликтами. Это по сути косметический вопрос. Программист и так должен понимать, что это альтернативные реализации библиотеки и файлы заголовков у них будут пересекаться по именам. Что же касается пакетного оформления, то я не нашел ни в документах ни по факту устоявшегося у нас стандарта для таких ситуаций. Оформлять можно по разному: взаимный конфликт двух пакетов, взаимный obsolete...
(In reply to comment #3) > > > Совершенно верно, эти devel-пакеты нельзя ставить одновременно по совершенно > > > очевидной причине. В чём состоит багрепорт да еще и с серьезностью major? > > Мдаа. > ?? Я не думал, что достаточно опытному майнтейнеру это придётся объяснять. > > Очевидно, в том, что файловые конфликты не оформлены пакетными конфликтами. > Это по сути косметический вопрос. Это вопрос, когда отвалится произвольная транзакция. > Что же касается пакетного оформления, то я не нашел ни в документах ни по > факту устоявшегося у нас стандарта для таких ситуаций. Это плохо.
(In reply to comment #4) > (In reply to comment #3) > > > > Совершенно верно, эти devel-пакеты нельзя ставить одновременно по совершенно > > > > очевидной причине. В чём состоит багрепорт да еще и с серьезностью major? > > > Мдаа. > > ?? > Я не думал, что достаточно опытному майнтейнеру это придётся объяснять. Андрей, что именно Вы считаете необходимым мне объяснять? Что указанный конфликт заголовочных файлов - это major bug? > > > Очевидно, в том, что файловые конфликты не оформлены пакетными конфликтами. > > Это по сути косметический вопрос. > Это вопрос, когда отвалится произвольная транзакция. Произвольная - не отвалится. Фразу же о том, что пользователь намеренно ставящий два _альтернативных_ devel-пакета должен как минимум понимать зачем он это делает, Вы почему то пропустили. Это devel-пакеты, они по библиотечным зависимостям программ не вытягиваются... > > Что же касается пакетного оформления, то я не нашел ни в документах ни по > > факту устоявшегося у нас стандарта для таких ситуаций. > Это плохо. Да.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > > > Совершенно верно, эти devel-пакеты нельзя ставить одновременно по совершенно > > > > > очевидной причине. В чём состоит багрепорт да еще и с серьезностью major? > > > > Мдаа. > > > ?? > > Я не думал, что достаточно опытному майнтейнеру это придётся объяснять. > > Андрей, что именно Вы считаете необходимым мне объяснять? Что указанный > конфликт заголовочных файлов - это major bug? > > > > > Очевидно, в том, что файловые конфликты не оформлены пакетными конфликтами. > > > Это по сути косметический вопрос. > > Это вопрос, когда отвалится произвольная транзакция. > > Произвольная - не отвалится. Фразу же о том, что пользователь намеренно > ставящий два _альтернативных_ devel-пакета должен как минимум понимать зачем > он это делает, Вы почему то пропустили. Это devel-пакеты, они по библиотечным > зависимостям программ не вытягиваются... Была попытка локально собрать lablGL, у которой в спеке указано: # Automatically added by buildreq on Fri Apr 04 2008 BuildRequires: camlp4 freeglut-devel labltk libmesa-devel tcl-togl-devel tk-devel Один пакет был установлен в контейнере, второго - не было. В таком случае, исходя из вашей дискуссии, lablGL нужно исправить. PS. На текущих версиях пакетов, я указанной проблемы не наблюдаю. > > > > Что же касается пакетного оформления, то я не нашел ни в документах ни по > > > факту устоявшегося у нас стандарта для таких ситуаций. > > Это плохо. > > Да. >
> > > Это вопрос, когда отвалится произвольная транзакция. > > > > Произвольная - не отвалится. Фразу же о том, что пользователь намеренно > > ставящий два _альтернативных_ devel-пакета должен как минимум понимать зачем > > он это делает, Вы почему то пропустили. Это devel-пакеты, они по библиотечным > > зависимостям программ не вытягиваются... > Была попытка локально собрать lablGL, у которой в спеке указано: > # Automatically added by buildreq on Fri Apr 04 2008 > BuildRequires: camlp4 freeglut-devel labltk libmesa-devel tcl-togl-devel tk-devel > Один пакет был установлен в контейнере, второго - не было. > В таком случае, исходя из вашей дискуссии, lablGL нужно исправить. Да, обновить BuildRequires. Подумайте сами, если в сборочных зависимостях некоего пакета оказались конфликтующие (неважно, пакетно оформленные или просто фактически, файлово) на тот момент пакеты, как в принципе он может собраться? > PS. На текущих версиях пакетов, я указанной проблемы не наблюдаю. Ага. На самом деле https://bugzilla.altlinux.org/show_bug.cgi?id=15570 Да, а еще я внимательнее посмотрел в багрепорт и заметил там пакет libmesa-devel-7.1-alt1.pre. В ченжлоге Mesa нет сборки 7.1-alt1.pre, есть просто 7.1-alt1. Это была Ваша локальная сборка?
(In reply to comment #7) > Да, обновить BuildRequires. Подумайте сами, если в сборочных зависимостях некоего > пакета оказались конфликтующие (неважно, пакетно оформленные или просто > фактически, файлово) на тот момент пакеты, как в принципе он может собраться? Моя ошибка, не заметил :-( Поторопился ... > > > PS. На текущих версиях пакетов, я указанной проблемы не наблюдаю. > > Ага. На самом деле https://bugzilla.altlinux.org/show_bug.cgi?id=15570 > > Да, а еще я внимательнее посмотрел в багрепорт и заметил там пакет > libmesa-devel-7.1-alt1.pre. В ченжлоге Mesa нет сборки 7.1-alt1.pre, есть просто 7.1-alt1. Это была > Ваша локальная сборка? Нет. Я далёк от всего, что связано с графикой. Видимо на тот момент в сизифе была именно эта версия пакета. Хотя отсутствие такой сборки в changelog-е мне непонятно.
(In reply to comment #8) > > > PS. На текущих версиях пакетов, я указанной проблемы не наблюдаю. > > > > Ага. На самом деле https://bugzilla.altlinux.org/show_bug.cgi?id=15570 > > > > Да, а еще я внимательнее посмотрел в багрепорт и заметил там пакет > > libmesa-devel-7.1-alt1.pre. В ченжлоге Mesa нет сборки 7.1-alt1.pre, есть просто 7.1-alt1. Это была > > Ваша локальная сборка? > Нет. Я далёк от всего, что связано с графикой. > Видимо на тот момент в сизифе была именно эта версия пакета. > Хотя отсутствие такой сборки в changelog-е мне непонятно. Сизифовская это сборка или левая можно определить, взглянув на поле BuildHost в хедере пакета (запустив rpm -qi), если этот пакет у Вас еще сохранился... Но согласно коментарию ментейнера в багрепорте #15570 фактичекий конфликт по файлам с freeglut-devel он устранил еще в сборке 7.0.3-alt7 пакета libmesa-devel. И на текущий момент конфликта тоже нет. Поэтому я крайне сомневаюсь, что у Вас стояла не левая сборка... Так что данный багрепорт я закрываю как NOTABUG.
