Sigil и его зависимости

emerge -GK sigil

пересобери пакет без этих ключей

Не интересно, это не исправит кривой .ebuild.

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

https://all-mems.ru/wp-content/uploads/2019/05/udivlennyy-pikachu-mem-758x567...

Нет никакого несоответствия. Пакет просит qtcore в слоте 5, в системе установлен пакет qtcore в слоте 5. Всё отлично?

Я даже процитирую:

RDEPEND="
	${PYTHON_DEPS}
	app-text/hunspell:=
	dev-libs/libpcre:3=[pcre16]
	$(python_gen_cond_dep \
		'dev-python/css-parser[${PYTHON_USEDEP}]
		dev-python/lxml[${PYTHON_USEDEP}]
		dev-python/six[${PYTHON_USEDEP}]')
	>=dev-qt/qtconcurrent-5.12:5
	>=dev-qt/qtcore-5.12:5

Вот вам всем - https://bugs.gentoo.org/721208

Ну так, не находишь, что такой предметный разговор гораздо более интереснее абстрактного «кривой ебилд».

Отсутствие здесь сабслота - однозначно баг. Твой багрепорт я поправил и назначил на мэйнтэйнеров

1. Я неправильно там версию написал. Это в app-text/sigil-0.9.16-r1

2. сабслот не нужен. Код требует 5.14, значит и в ebuild должна быть 5.14, а не 5.12

Код требует 5.14

Ты уверен? Sigil 0.9.16 вышел в июле 2019, Qt 5.14 начали разрабатывать в конце августа.

Не, я конечно допускаю что автор sigil мог хреначить линковку прямо с master-веткой qt, но что-то мне кажется что это больше похоже на твою ошибку с установкой бинарного пакета, слинкованного с Qt 5.14 в систему, где стояла предыдущая версия. А так как сабслот отсутствовал - никто не помешал тебе этого сделать. Мой комментарий насчет игнорирования зависимостей признаю ошибочным - мне показалось что ты использовал ключ -O вместо ключа -G.

абстрактного «кривой ебилд»

я не уверен, что именно криво в этой ситуации.

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

Верно. Но неправильная проверка версий это не моя ошибка, а пакетного менеджера.

так как сабслот отсутствовал - никто не помешал тебе этого сделать.

Но там и не должно быть зависимости от сабслота. Потому что если бы на билд сервере собрано было с qtcore 5.12 всё бы установилось.

Т.е. проблема не в зависимости, а в том, что portage «не помешал». А должен был!

Т.е. проблема не в зависимости, а в том, что portage «не помешал»

Кажется ты не понимаешь как работают сабслоты в бинарных пакетах. Как раз именно из-за отсутствия сабслот-оператора ':=' в ебилде, сабслот(будь-то 5/5.12 или 5/5.14) явно не прописался в бинарный пакет на этапе сборки, отсюда - portage не помешал тебе поставить бинарный пакет при наличии установленного Qt с другим сабслотом.

Данное поведение описано в PMS, секция '8.3.3 Slot dependencies'

Почему так вышло? Почему portage записывает сабслот в бинарный пакет, только если он явно указан в ebuild?

Я думаю, что сабслоты не указаны в очень многих билдах. По-крайней мере, мне мысль прописывать их туда никогда не приходила в голову. Здесь ясно в билде сказано - неважно какая версия, если она больше 5.12. И тут вдруг внезапно бац, и оказывается, что нужно зафиксировать слот 5.12.

Почему так вышло? Почему portage записывает сабслот в бинарный пакет, только если он явно указан в ebuild?
Я думаю, что сабслоты не указаны в очень многих билдах. По-крайней мере, мне мысль прописывать их туда никогда не приходила в голову.

Все еще хуже, ты не понимаешь зачем были созданы сабслоты... Тэкс, ну давай тогда по порядку, читни-ка вот это для начала, секция «Real-world examples». Потом я думаю стоит заглянцевать документацией по autotools в части версионирования библиотек.

Как сможешь ответить на вопрос вида: «есть dev-util/boost. У него есть сабслоты. В каких случаях не будут прописаны сабслоты для boost в зависимостях у другого пакета, и это будет оправдано, так как прописывание сабслота вызовет лишнюю пересборку, в результате которой ничего не поменяется?», приходи, поговорим дальше. Хотя, сдаётся мне, что как только ты сможешь ответить на этот вопрос тебе разговор и не понадобится - ты сам всё поймешь.

есть dev-util/boost. У него есть сабслоты.

это решительно другой случай, не такой как в этом топике.

в приведённой тобой статье предлагается делать одинаковый SLOT=«0» и разные сабслоты, соответствующие мажорным версиям симлинков библиотеки.

Но в случае с qtcore мажорным версиям симлинков соответствует номер слота! (это моя непроверенная гипотеза) То есть, оба ебилда qtcore-5.12 и qtcore-5.14 устанавливают одну и ту же библиотеку libqtcore.so.5 (и поэтому у них слот №5)

А в статье на wiki, которую ты предлагаешь читать, там библиотека dev-libs/libfoo-1.0 устанавливает libfoo.so.1 а библиотека dev-libs/libfoo-2.0 устанавливает libfoo.so.2

В этом случае мне понятно, чем отличается прикладная программа - она ссылается на разные so.N

В случае же с sigil - libqtcore.so.5 не меняется.

# equery files qtcore | grep '\.so'
/usr/lib64/libQt5Core.so
/usr/lib64/libQt5Core.so.5
/usr/lib64/libQt5Core.so.5.14
/usr/lib64/libQt5Core.so.5.14.1

думаю стоит заглянцевать документацией по autotools в части версионирования библиотек.

Как это сделать (что именно прочитать)?

Но в случае с qtcore мажорным версиям симлинков соответствует номер слота! (это моя непроверенная гипотеза)

Номер слота(не сабслота, а именно слота) никак не связан с версиями .so-файлов. А вот сабслоты - связаны.

В случае же с sigil - libqtcore.so.5 не меняется.

Угу. А еще есть /usr/lib64/libQt5Core.so. Видимо вообще можно саблоты не менять - будет тишь, да благодать.

Как это сделать (что именно прочитать)?

https://autotools.io/libtool/version.html

Номер слота(не сабслота, а именно слота) никак не связан с версиями .so-файлов.

Это значит, что номер слота не нужен. Ничего бы не поменялось, если бы вместо «5» там был «0». И обусловлен номер 5 только «историческими причинами», то есть, упёртым нежеланием разработчиков использовать «0» для понятности, специально чтобы вводить других людей в заблуждение.

Видимо вообще можно саблоты не менять - будет тишь, да благодать.

Так и есть. Твой сарказм мешает ТЕБЕ увидеть очевидное: в данном конкретном случае вместо сабслотов можно использовать слоты. Есть неудобство - синтаксис слотов не поддерживает формат отличный от ‘[0-9]+’. Но можно было бы закостылить слоты 512, 514 и тогда «вообще можно сабслоты не менять».

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

Итак, зачем же нужны сабслоты в данном случае? Они нужны только для «красоты» и для «исторической преемственности». То есть это заморочка portage ради самобытности. Т.е. portage - кривой, длина обучения пользователей необосновано увеличена введением ненужных концепций, а гентушники - вредители и замедляют всемирный прогресс по заказу Билла Гейтса.

https://devmanual.gentoo.org/general-concepts/slotting/index.html

Current versions of portage accept slot and sub-slot names that begin with an alphanumeric character or _, and contain alphanumerics and _, -, ., and + characters.

Ну тем более. Значит в качестве имени слота даже 5.14 писать можно.

https://autotools.io/libtool/version.html

Причитал, ничего не понял.

На странице https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots написано:

Qt libraries are considered ABI-stable for each major release, and therefore the slot is used to represent public ABI version. Subslots are used to expose ABI changes in private ABI and normally should not be used by revdeps.

Из этого следует, что ошибка в Sigil. Не должен он зависеть от private ABI без уважительной причины (которая пока не известна). Поэтому нельзя просто взять и затребовать конкретный subslot, надо сначала выяснить, не нужно ли пропатчить Sigil.

Я написал большую простыню в попытке объяснить тебе где ты не прав, но потом дочитал твое второе сообщение, а именно:

Прочитал, ничего не понял.

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

Сил моих больше нет. И лицо у меня уже сильно болит, прости.

У разработчика билда тоже возникли непонятки, о которых он написал в баге. А проблема есть - использование portage привело к возникновению неработающего сетапа. И её надо как-то решить.

Так и запишем - бинарная установка в генте неработоспособна.

Так и запишем - Einstok_Fair долбоеб.