LINUX.ORG.RU

Multiple package instances -> a slot conflict

 , ,


0

1

Пытаюсь обновить генту командой emerge -auvDN @world, не получается.

При обновлении выдаётся сообщение:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

Десять лет назад была такая ветка:
https://forum.calculate-linux.org/t/emerge-e/6296

англы тоже страдают:
https://unix.stackexchange.com/questions/116001/emerge-on-gentoo-fails-with-multiple-package-instances-within-a-single-package

работающего решения, либо объяснения никто не предложил. Идёт 2023-ий год.

Чисто теоретически, вроде там были какие-то ключи командной строки, которые какие-то проверки отключали, но я не помню их на память.

Внимание вопрос: что мешает третьей строкой ниже добавить в вывод фразу «см. страницу … в Gentoo Wiki для исправления этой ошибки: https://...»?

UPD: в man emerge есть ключи:

--ignore-built-slot-operator-deps < y | n >
    Ignore the slot/sub-slot := operator parts of dependencies that have been recorded when packages where built. This option is intended only for debugging purposes, and it only affects built packages that specify slot/sub-slot := operator dependencies  which  are  supported beginning with EAPI 5.

и

--rebuild-if-new-slot [ y | n ]
    Automatically  rebuild  or  reinstall  packages when slot/sub-slot := operator dependencies can be satisfied by a newer slot, so that older packages slots will become eligible for removal by the --depclean action as soon as possible. This option only affects packages that specify slot/sub-slot := dependencies which are supported beginning with EAPI 5.  Since this option requires checking of reverse dependencies, it enables --complete-graph mode whenever a new slot is installed. This option is enabled by default.
    NOTE: If you want to skip all rebuilds involving slot-operator dependecies (including those that  involve  sub-slot  changes  alone), then --ignore-built-slot-operator-deps=y is the option that you are looking for, since --rebuild-if-new-slot does not affect rebuilds triggered by sub-slot changes alone.

UPD2:

--verbose-conflicts
    Make slot conflicts more verbose. Note that this may in some cases output hundreds of packages for slot conflicts.
★★★

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

Ответ на: комментарий от Shushundr

Идёт 2023 год, а ты до сих пор не можешь сообразить сразу написать, какую команду ты пытаешься выполнить , как давно в последний раз система полностью обновлялась и какой вывод в терминал у тебя.

Если как по ссылке emerge -e system, то не удивительно.

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

какую команду ты пытаешься выполнить

Это не имеет значения. Такая ошибка выдаётся при выполнении разных команд, в которых выполняется расчёт зависимостей.

emerge -auvDN @world

я пишу. Но это неважно.

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

как давно в последний раз система полностью обновлялась?

Я не помню. Какой командой это можно узнать?

Но это в принципе неважно. Если успешное обновление было N месяцев назад ( где N ∈ [10..300] ), это не повод переустанавливать систему с .iso-образа. У нас тут не Винда!

какой вывод в терминал у тебя?

Обрезанный!

оно пишет:

    ...
    (and 104 more with the same problem)
    ...

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

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

что последнее массово обновлялось из пакетов

Это вообще не показатель. Нужно чтобы:

  1. команда обновляла именно мир
  2. чтобы она завершилась удачно
  3. чтобы были исправлены все @revdep-rebuilds, удалены все masked packages, обновлены haskell-updater и что там ещё бывает…

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

Но это в принципе неважно

Важно.

Я думаю по-другому. Важно понять, что же именно происходит. Для этого надо понимать объектную модель зависимостей (и USE-флагов). А я с ней никогда не разбирался.

Вот даже баг похожий есть в багтрекере - https://bugs.gentoo.org/598503
«оно пугает пользователей»

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

Проблема возникает не только у меня, чему есть многочисленные свидетельства.

Поэтому правильным решением является написание туториала, а не фикс отдельной моей системы.

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

Какая разница? Вот человек потерял на этой проблеме трое суток - Затык ::Gentoo
«Долбусь уже 3й день, никак.»

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

Эти конкретные конфликты существует независимо от глубины пересчёта зависимостей. Они из-за того, как написаны тексты билдов. И увеличение backtrack не поможет мне (но надо, конечно, поэкспериментировать).

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

Я думаю по-другому. Важно понять, что же именно происходит

Происходит примерно следующее: гента не может обновить пакет, записав новые данные поверх старых.

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

Это гента, да.

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

Простейшее решение - снести пакет

Во-первых, пакетов которые нужно снести - слишком много. Во-вторых, это она должна делать сама-сама, в третьих там бывают такие пакеты, которые нельзя удалять, иначе система превратится в тыкву (их надо перемёрживать через oneshot опцию «-1»).

Я замучаюсь сносить 104 пакета вручную, это при том, что я ещё не нашел опцию, которая выводит полный список их имён.

При этом я совершенно точно знаю, что все эти проверки можно отключить, но не помню как.

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

Мало ли, что пишут, ещё надо мне понять написанное. Например мне непонятно, что такое «package instance», я-то считал что установленный экземпляр пакета - это как раз то, что SLOT и описывает. А оказывается нет, это что-то другое, «устанавливаемый экземпляр пакета»…

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

Не я один. Например здесь - https://wiki.gentoo.org/wiki/User:Kentnl/Tips/Fixing_slot_conflicts

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

А вот официальное руководство по борьбе - https://wiki.gentoo.org/wiki/Troubleshooting#Dependency_graph_slot_conflicts

При этом там нет ссылок на определения терминов, описание проблемы и т.д. и нет решения (всё вручную).

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

Решение в генте для этой проблемы простое:

1) регулярные обновы;
2) не смешивать ветки(stable/unstable);

Если не выполняется хотя бы один из пунктов - систему надо чинить руками. Это плата за гибкость. Кто не готов платить или кому такая гибкость нафиг не нужна - если 100500 других более подходящих их задачам дистрибутивов.

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

систему надо чинить руками. Это плата за гибкость.

Это всё да, но нет. Просто никто не хочет именно эту конкретную проблему признать.

Вот например ты много хейтил за то, что жаловались на кросс-компиляцию, потом прошло несколько лет и появился EAPI-7, в котором «появилась первая поддержка кросс-компиляции». Кто был неправ? Ты, потому что тебе просто было лень разбираться.

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

появилась первая поддержка кросс-компиляции
EAPI 7

На лицо непонимание того что тебе пишут в тексте анонса. Поддержка не появилась, она улучшилась. Кросс-компилировал я еще во времена когда EAPI 4 был модным и молодежным.

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

Лицензия на венду дорогая, и кроме того, мне, как жителю диктаторской страны, не продадут, скажут, что я недостоин.

# genlop -e  -i sys-libs/glibc
 * sys-libs/glibc

     Tue May  5 14:05:17 2020 >>> sys-libs/glibc-2.29-r7
     Wed May 13 07:07:47 2020 >>> sys-libs/glibc-2.30-r8
     Sun May 17 10:31:23 2020 >>> sys-libs/glibc-2.30-r8
     Wed Sep  9 01:05:17 2020 >>> sys-libs/glibc-2.31-r6
     Thu Nov  5 10:52:01 2020 >>> sys-libs/glibc-2.32-r2
     Thu Dec 17 13:59:14 2020 >>> sys-libs/glibc-2.32-r3
     Sun Jan 31 08:13:57 2021 >>> sys-libs/glibc-2.32-r7
     Tue Apr 20 17:09:02 2021 >>> sys-libs/glibc-2.32-r7
     Thu Apr 22 06:02:55 2021 >>> sys-libs/glibc-2.32-r7
     Mon Jun  7 21:09:20 2021 >>> sys-libs/glibc-2.33
     Thu Jul 15 06:01:44 2021 >>> sys-libs/glibc-2.33-r1
     Tue Aug 31 10:51:44 2021 >>> sys-libs/glibc-2.33-r1
     Sat Dec 11 09:51:26 2021 >>> sys-libs/glibc-2.33-r1
     Sat Dec 11 09:52:21 2021 >>> sys-libs/glibc-2.33-r1
     Sat Dec 11 09:59:05 2021 >>> sys-libs/glibc-2.33-r1
     Sat Dec 11 11:02:58 2021 >>> sys-libs/glibc-2.33-r7
     Sun Mar 13 15:19:16 2022 >>> sys-libs/glibc-2.33-r13
     Sun Apr 10 10:47:37 2022 >>> sys-libs/glibc-2.34-r10
     Mon Apr 18 14:25:52 2022 >>> sys-libs/glibc-2.34-r10
     Mon Apr 18 15:55:39 2022 >>> sys-libs/glibc-2.35-r2
     Mon Jun  6 05:02:49 2022 >>> sys-libs/glibc-2.35-r5
     Wed Jun 15 23:11:11 2022 >>> sys-libs/glibc-2.35-r7
     Thu Oct 20 14:15:54 2022 >>> sys-libs/glibc-2.35-r11
     Mon Nov 28 00:46:19 2022 >>> sys-libs/glibc-2.36-r5
     Tue Dec  6 11:44:40 2022 >>> sys-libs/glibc-2.36-r5
     Wed Jan  4 11:37:41 2023 >>> sys-libs/glibc-2.36-r5
     Wed Jan  4 13:15:06 2023 >>> sys-libs/glibc-2.36-r5
     Sun Mar 19 07:16:26 2023 >>> sys-libs/glibc-2.36-r7
     Thu May 18 21:17:50 2023 >>> sys-libs/glibc-2.36-r8
     Wed Oct  4 14:53:56 2023 >>> sys-libs/glibc-2.37-r3

   Total builds: 30
   Global build time: 10 hours, 11 minutes and 25 seconds.
   Average merge time: 20 minutes and 22 seconds.

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

Shushundr ★★★
() автор топика

Я думаю, что могла бы существовать команда,
которая выводит предполагаемое время окончания процесса сборки (ETA = The Estimated Time of Arrival)

Для этого нужно:

  1. посмотреть, какой был первый аргумент в текущей команде работающего процесса сборки
    (чтобы определить, какой пакет собирается)
  2. рассчитать зависимости,
    (чтобы понять, сколько и каких пакетов будет собрано)
  3. путём анализа лога предыдущих сборок посчитать, сколько времени займёт вся сборка

Я такую написать не могу, потому что не понимаю, как считаются зависимости. Но может уже есть готовая?

genlop
  -p  estimate build time from a piped "emerge -p" output

она не учитывает сколько времени уже прошло́ от начала сборки.

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 3)
Ответ на: комментарий от t184256

могли бы эту проблему как-нибудь решить уже.

Написали Nautilus. Он сначала файлы показывает, и только после позволяет их удалять. Поэтому никаких «not found». Осталось дело за малым - убрать эмуляторы терминалов. Всё равно сами терминалы как физические устройства уже не производят, это теперь смартфоны.

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

Есть частичные обновления, есть обновления безопасности.
Сейчас portage так устроен, что уже давно можно не пересобирать мир постоянно, а где-нибудь раз в полгода, уделяя по часу на проверку и правку конфигурации, а чаще обновлять только что-то прям необходимое, например когда свежее решето всплыло
У меня под маской компиляторы, boost, qt, но ничто не мешает и glibc под маской держать.
Но если ты не хочешь следить за конфигурацией и исправлять возможные временные косяки, возможно gentoo не для тебя. А обновления без проблем - вообще миф, но максимально близко к ним винда. которая старается делать так, чтобы эти обновления не были заметны пользователю вообще (правда пока с отрицательным успехом)

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

Лучше бы их не было.
Я дебиан более-менее только на сервере могу юзать, но даже туда он плохо подходит из-за отсутствия конфигураций без графики (бесит, когда у тебя ffmpeg тащит все драйвера mesa)
На десткопе проблемы везде от ядра до совсем уж прикладных вещей, всё-таки на LTS жизни нет.
Обычно тем, кто всё-таки использует дебиан на десктопе с ядром повезло, что ничего не сломалось, а прикладное всё сидит во флетапках и каким боком дебиан тут вообще не понятно.
Зачем тебе релизы генты? Генту ставят когда то, что есть в других дистрах тебе плохо подходит.
Вот банально например, сейчас на рабочей машине (она слишком медленная для компиляции + не хотел тратить время) арч, на нём нет libGLESv1_CM, просто мейнтейнеры решили что оно никому не нужно (на убунтах кстати тоже его нет)
При этом лишнего на этом арче до ужаса. В итоге она играет роль какого-то тонкого клиента для систем с гентой, при этом очень неэффективного т.к сюда напихали всё что можно и нельзя, при этом всё равно не докидав каких-то нужных вещей

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

Хорошо написано. Сам сейчас сижу на раче. Очень много мусора, но это поймут разве что гентушники.

Дебиан на минималках тащит меньше зависимостей, чем рач. Но с дебианом у меня любовь не получается. Он разваливается.

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

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

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

у меня он даже не то что бы разваливается

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

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

utanho ★★★★★
()