А маинтейнеры openSUSE выбирают только что-то одно, а остальное заносят в свой чёрный список. В т.ч., например, у них и systemd-resolve в дистрибутиве нет.
Как по мне, решение так себе. С другой стороны, в Windows или MacOS есть зоопарк загрузчиков, инитов, DNS-резолверов, звуковых серверов, WM/DE? На возможность накатить дистрибутив и начать работать подобные решения не влияют. Поддерживать меньшую пакетную базу проще. Допилить до работоспособного состояния – тоже.
Тем не менее, файл libcurses.so есть и там. А исключения везде можно найти потому, что дистрибутивов сотни.
Тем не менее, в таких дистрибутивах как LFS, Slackware, Mageia, Arch, Debian, Ubuntu, Gentoo,... и т.д. реализовано именно через симлинки.
А метод с «INPUT(-lncurses)» упоминался маинтейнером при обсуждении багрепорта, но он и его забраковал. Потому, что у него есть ещё пакет termcap с .so'шниками libcurses.<цифры>.so и он боится как бы введение libcurses.so не зацепило их.
Маинтейнеры остальных дистрибутивов спокойно вводят файл libcurses.so в том или ином виде. И "-lcurses" в них прекрасно работает из коробки.
А выводы я делал не только по своим багрепортам, я и чужие тоже читал. И в итоге я просто перестал доверять этим людям. Потому и внёс их дистрибутив в чёрный список.
Одно дело когда просто твои багрепорты отфутболивают, а совсем другой этот самый элитизм, когда работающее в других дистрах называют «грязными хаками».
Ну а в дебиане вот есть пакет в 10ке с плагинами для firefox. Но ни не работают с лисой из реп, внезапно.
Как мне тут объяснили, потому что лиса не разрешает не подписанные дополнения.
Но пакет зачем-то оставили. Везде есть «мелочи», просто если долго пользуешься - знаешь и обходишь
Дескать, маинтейнеры остальных дистрибутивов ничего не понимают и делают дистрибутивы на «грязных хаках», которые в их элитном дистрибутиве просто недопустимы.
А маинтейнеры openSUSE выбирают только что-то одно, а остальное заносят в свой чёрный список. В т.ч., например, у них и systemd-resolve в дистрибутиве нет.
Что сделал SUSE/OpenSUSE (куча компаний его разрабатывающих) для мира Linux? Вот серьёзно. Даже Ubuntu-разработчики и то весомый вклад имеют. А эти? Даже вывести KDE в enterprise-лигу не смогли.
Насчёт hostname надо смотреть что за баги у них были. Следовало привести примеры проблемных софтин с твоей стороны именно в opensuse, а не в произвольном дистрибутиве. Ты этого не сделал, поэтому жалоба выглядит неубедительной.
Насчёт
libcurses.so must be symlink to libncurses.so
крайне сомнительно, что должен. Скорее ты должен при сборке подправить список линкующихся библиотек и спросить у автора той софтины, почему и откуда он взял libcurses.
Что сделал SUSE/OpenSUSE (куча компаний его разрабатывающих) для мира Linux?
Интересно услышать что сделал Debian кроме своей системы пакетов не входящей в LSB. Авторам дистрибутивов вроде бы вообще не положено что-то своё делать, только собирать разные чужие пакеты в одно целое.
Novell не один год был одним из крупных контрибьюторов, крупнее Canonical. Когда наблюдал за этим, первые места всегда были за красношапкой, новеллом и айбиэмом или интелом.
Возможно, но в самом hostname в /etc/hosts нет ничего страшного, в то время как маинтейнеры в один голос заявляют, что, дескать, его в любом случае никогда там не должно быть. Что уже весьма подозрительно.
ты должен при сборке подправить список линкующихся библиотек
Нет, не должен. "-lcurses" - это стандарт. Выучил его по манам и книгам и пользуюсь в новом софте с 2006-го года. И он просто работает. Везде. Кроме openSUSE.
По мнению маинтейнера это вообще не должно работать:
This does not work with shared ELF libraries due to the soname used. The linker does not accept libraries over symlinks with wrong soname. That is if a program is linked against the original libcurses a symbolic link point to libncurses as replacment for libcurses will not work
В то время как оно работает в остальных дистрибутивах и на ЛОРе уже раскрывали принцип работы: линковщик идёт по симлинкам и линкует уже конкретно с /lib64/libncurses.so.x.
Ссылку на стандарт. Мало ли что было в книгах 2006 года.
Бывают и неофициальные стандарты сложившиеся по историческим причинам.
Если сама библиотека по сборке не поставляет файл с таким именем, то с чего бы его создавать?
Для обратной совместимости нарушение которой можно рассматривать как нарушение исторических стандартов.
линковщик идёт по симлинкам и линкует уже конкретно с /lib64/libncurses.so.x.
А они считают, что это не очень хороший подход.
обратной совместимости
Обратной совместимости с чем? Если ты что-то сам собираешь, то подправить, не обломишься. Ещё раз - исходная библиотека не предоставляет файла с таким именем и его делать никто 6е обязан.
Я не психотерапевт и не могу помочь тебе с твоими проблемами.
Вот когда маинтейнеры большинства дистрибутивов повыпиливают - тогда и будет о чём говорить. А пока что выделяется чуть ли не одна openSUSE (другие примеры пока что не обнаружены).
Обратная совместимость - важная вещь. Хотя, понятное дело, в том мире, где возможны всякие Python'ы (сам язык весьма неплох, да, речь о том, как его готовят), ломающие обратную совместимость между мажорными версиями, её, к сожалению, перестают ценить...
Важная но обратная совместимость действует только на публичные интерфейсы. Наличие libcurses.so к таковым не относится. Можете взять исходники libcurses.so, собрать и установить.
Суть в том, что библиотека ncurses изначально разработана совместимой с curses. Если бы между ними была бы такая же разница как между иксами и вейландом, то никто и никогда бы не делал libcurses.so симлинком на libncurses.so. Но его потому и делают, что прежние программы, делающие "-lcurses", не замечают разницы. Соответственно, если новый софт использует тоже самое, что и было в curses, то он может быть написан как для curses и собираться как в системах только с curses, так и в системах с ncurses. Это и есть настоящая обратная совместимость.
Зачем тогда выдумали название libncurses.so? Почему при сборке самого ncurses не создаётся символьной ссылки? Это выглядит как проблема в ncurses а не в дистрибутиве.
PS: ncurses и аналоги естественно не нужны ибо псевдографика в консоли - это костыль.
Смотри, ты же можешь сделать чтобы везде работало.
И в Xenix и в новой OpenSuse.
Рассказываю тайные знания.
Берешь пишешь hello world в пару строчек, и пробуешь его скомпилировать с pkg-config --libs ncurses и смотришь код возврата, если скомпилировалось, то запоминаешь это. Если не собралось, то пробуешь собрать с -lcurses, если собралось, то запоминаешь это, если нет выводишь сообщение об ошибке.
Да я был готов и на "-lncurses" переписать. Но это если бы объяснения были бы адекватными, а не «не будет такое работать и вообще это грязные хаки» (в то время как оно вполне работает и с точки зрения маинтейнеров большинства дистрибутивов это вполне норма). Людям, которые так объясняют, я доверять не могу. И их дистрибутиву, соответственно, тоже.
В Wine (альтернативная реализация Win32) почему-то библиотеки тоже называются kernel32.dll, user32.dll и т.д.. Почему авторы ncurses не могли поступить также? Сами ломают обратную совместимость на пустом месте.