Компания Qt Company намерена включить в состав Qt Online Installer пакетный менеджер, который поможет упростить установку дополнительных библиотек в Qt 6. В качестве основы будет использован пакетный менеджер Сonan, рассчитанный на распространение библиотек на C/C++ и имеющий децентрализованную архитектуру, позволяющую распространять библиотеки со своего собственного сервера...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53989
Хорошая новость, обожаю QT
[комментарий про QuickTime]
Оно уже умерло. Начиная с каталины, даже на родной ему макоси.
Ага, хохма уже десятилетия живет, но народ по-прежнему неаккуратен в заявлениях.
чувак, t маленькая
Может он регистронезависимый.
Регистро-диссидент.
Тяжёлый, раздутый, тормозной. Qt.
... для микроконтроллеров и маломощных устройств.
Поясните для неразбирающихся. Это нечто на манер склоняемого тут на тему дыр и засылов всякой бяки NPM?
Вы ничего не понимаете. В НПМ дыры неправильные, а в кутях будут - правильные и одобренные
> правильные и одобренныеФрактал не одобрит, так что мимо
что такое фрактал? че за мальденброт?
В пакетном менеджере Qt будут правильные одобренные сишные дыры
> В пакетном менеджере Qt будут правильные одобренные сишные дырысиплюшплюшные
сплюснутые дыры
Нет, это что-то вроде pip для путхона
Это в котором дырки для питона?
Да, как в cargo для растишки.
> Это нечто на манер склоняемого тут на тему дыр и засылов всякой бяки NPMТа не, это просто капздец кутям пришел. Пятерка будет жить вечно.
Помню как про тройку так говорили.
Qt3 forever!
Нет, к conan можно подключать репозитории, но в официальный абы кого не пускают.
> Это нечто на манер склоняемого тут на тему дыр и засылов всякой бяки NPM?Ты не понял! Это - другое!
С++ это такой удобный язык, что даже пакетный менеджер(conan) для него написан на питоне.
Скажи спасибо, что не на Расте.
Скорее обидно, что не на хорошем языке (Расте), а на каком-то там пистоне
нынче просто ленивые все, пакетный менеджер им подавай
Нынче только ленивые не делают свой пакетный менеджер.
Ваш комментарий ни о чём. Сайты тоже можно писать на С++ (Wt), но пишут на PHP. И что?
Я вообще о его существовании слышу в первый раз. И даже для питона не испльзую этот... Как его там. Есть же репозитории у нормальных операционных систем - все остальные могут идти лесом пока своё дерьмо не сделают по человечески а не сайтами с варёзом и вируснёй.
для разработки же, не для эндюзера.
> Есть же репозитории у нормальных операционных системА, так вот чем достигаются рекордные числа пакетов у разных дистрибутивов - они просто из pip и npm всякое тянут )
Который из? Их, наверное, с десяток как минимум.
Conan не для С++, он для Qt
Для C++.
Перечитайте новость и пройдите по ссылке (на Conan). Conan - для плюсов, а то что для Qt - на основе Conan'а.
>Qt for MCUsпочти как "ВИЧ для онкобольных"
О! Между прочим, первый в истории человек, излечившийся от ВИЧ, излечился как раз в ходе лечения от онкологии, благодаря химиотерапии и пересадке костного мозга от очень удачного донора. Потом, правда, все равно умер.
Тут должна была бы быть какая-то мораль, но нет.
Мораль: используйте Gay Tool Kit. Так?
Мораль проста: врачепорцы, антипрививочники и прочий генетический мусор должны умереть.
Врачепорцы это кто такие?
Муж дамы-врача?
> Муж дамы-врача?*муж целомудренной дамы-врача
> Потом, правда, всё равно умер.вот именно, умер от того, чем лечили.
> и пересадке костного мозга от очень удачного донора.НУ да, мистер счастливчик просто. Он потом тоже умер . А затем прилетели марсиане и сказали что харе уже царапать небесную твердь и по эфирам свой бред пропускать, у них дети начинают тупеть от этого. И прислали масковича, элончик читал лекции на всякие никому ненужные темы 7 дней в неделю и параллельно написал десять линуксов и тридцать ракет собрал из консервных банок. Потом человечество сказало что это фигня и надо возвращаться к дино-тяге, это когда динозавр тянет тележку. Это очень эффективно но динозавра надо кормить и столько мяса не вырастить, потому и сделали динозавра невидимым, а жертвы для него якобы заболевали от неведомого вируса и приходя в "пункт" отдавали бабло за тесты и скарливались невидимому динозавру. Пункты были какбы заправками такими. но люди догадывались что что-то не так ..
поделитесь веществами, пожалуйста
> Пункты были какбы заправками такими. но люди догадывались что что-то не так ..Поэтому люди прекратили приходить на заправки, и из-за этого динозавры вымерли. Люди начали строить египетские пирамиды, чтобы передать инопланетянам сигнал о том, что им нужны новые динозавры. Но Клеопатра поняла, что пирамиды не работают, и она родила Гая Юлия Цезаря. Гай Юлий Цезарь родил Тиберия. Тиберий родил Фому Аквинского. Фома Аквинский родил Ивана Грозного. Иван Грозный родил Ньютона. Ньютон родил Руссо. Руссо родил Ленина. Ленин родил Хайдеггера. Хайдеггер родил Путина. Путин родил Трампа. А Трамп излечил первого человека от ВИЧ.
Евангелие от Ordu.
Вчера был ВИЧ/спид:https://www.linux.org.ru/forum/talks/2529338
https://www.linux.org.ru/forum/talks/2801803
Сегодня в моде маскировка облучения СВЧ под "коронавирус".
Неизменным остается только геноцид.
> Неизменным остается только геноцид.Методы проведения геноцида поменяли, с негуманных фашиских концлагерей и газовых камер на более гуманные и демократичные - больнички с ИВЛ.
>Методы проведения геноцида поменяли, с негуманных фашиских концлагерей и газовых камер на более гуманные и демократичные - больнички с ИВЛДобавь сюда асфиксию от ношения намордников, смертоносные протоколы "лечения" и тотальный информационный террор, от которого многие сходят с ума.
Билл Гейтс со своими чипами нервно курит в сторонке.
нет курение вредит ...
а вот ...
совершенно неттак то!
Всем свой пакетный менеджер!
> Всем свой пакетный менеджер!Заверните парочку для asm.
асм использует хардварный
Рак плюсов, то свои дебильные системы сборки пропихнут, то убогий conan когда есть vcpkg.
Правильно, собирать надо только компилятором а пакеты устанавливать исключительно из Cargo! Так победим!
Как же хочецца...
vcpkg конечно же неплох, но в отличии от Conan он принципиально не поддерживает версирование пакетов. Архитектурно он напоминает систему портов в FreeBSD.
поддерживает https://github.com/microsoft/vcpkg/blob/master/docs/specific...
Ну вот зачем он нежен, да ещё и на пихоне!
rpm их чем не устраивает?
> rpm их чем не устраивает?"сделано не ими" (с)
>Ну вот зачем он нежен, да ещё и на пихоне!Мсье желает по жестче? Как на счет %вставить_очередную_шутку_про_раст%?
RPM нежный?)
очень, особенно когда база блокируется и потом сыпется. тебе нежно потом намекают, что кабздец полный и ты волен заниматься make install вечно постигая дзен.))
C++ разработчики тоже люди и хотят нежности.
Тогда пора переходить на Раст. Плюсы после него - неудобный мусор. Уже и не говорю и си, который на фоне плюсов - беспомощный тонущий щеночек.
Хорошая попытка, анон.
Я тоже за нежный пихон. А рпм слишком груб.
> rpm их чем не устраивает?Системные пакетные манагеры неудобны для разработки. Если я пользуюсь библиотекой, я хочу иметь возможность легко посмотреть как мой код с разными версиями библиотеки работает, я хочу иметь возможность использовать даже не версию библиотеки, а конкретный git-commit, потому что там исправлен баг о который я спотыкаюсь, или добавлена фича, которую я хочу попробовать. Я хочу иметь возможность легко наложить патчик на библиотеку, чтобы добавить отладочную печать, которая бы мне выдавала бы информацию о происходящем в недрах этой библиотеки.
И я не буду каждый раз, когда мне хочется добавить printf в недра библиотеки собирать новый rpm-пакет. Я даже не вижу смысла общесистемно ставить эту библиотеку: я её проще так подключу, модифицировав LD_LIBRARY_PATH. Или даже прилинкую статически к своему проекту, чтобы не возиться с переменными окружения.
Я не буду всего этого делать, и уж тем более я не буду ждать, когда мейнтейнеры дистра пошевелятся и занесут в репы интересную мне версию библиотеки. Или хотя бы хоть какую-нибудь версию библиотеки занесут в репы. Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например, точно использовал, но на это я тоже забил, потому как эти оверлеи имеют тенденцию забывать обновляться на полгода или даже на пару лет, и из-за этого становится бесполезными.
> Ну вот зачем он нежен, да ещё и на пихоне!
А на чём его писать? На bash что ли? На bash довольно неудобно парсить конфиги, их конечно можно писать в синтаксисе bash, но нафиг надо, если конфиги можно писать в toml или в json, и парсить из python'а двумя строчками, одна из которых начинается со слова import. То есть, можно конечно написать и на bash, но видимо это не надо никому, кроме тебя.
Благодарю за разъяснение.
Из текста новостей про Qt6 не понятно было что именно это такое и зачем это нужно.
> А на чём его писать? На bash что ли?На C++.
> я хочу иметь возможность использовать даже не версию библиотеки, а конкретный git-commitвам к source-based, портежи умеют в это.
> Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например
о, вы только что оттуда.
Ну так-то да, но от схемы с оверлеями "собственный пакетный менеджер Qt" отличается только тем, что какие-то базовые репы там будут тянуть силами разрабов Qt и есть шанс что их не бросят. Или есть ещё отличия?
>> я хочу иметь возможность использовать даже не версию библиотеки, а конкретный git-commit
> вам к source-based, портежи умеют в это.Ты пробовал это применять на практике? Я тебя заверяю, гораздо проще жить, имея в дереве проекта файлик toml, в котором депенданс описывается тремя строками, и смена номера версии на коммит git'а сводится к редактированию одной строки. Чтобы в оверлей добавить описание ещё одной версии пакета, надо создать копию ebuild'а (или даже создать с нуля его, потому что нечего копировать), подредактировать ebuild, подписать ebuild, собрать ebuild. При этом, собираться он будет в /var/tmp, даже если мне было бы удобно собирать в ~/home, после сборки дерево сорцов будет удалено. Он будет поставлен общесистемно -- и если у меня уже стоит такая библиотека в системе, то либо она будет заменена, либо мне придётся в ебилде возиться с multilib. При этом всегда остаётся риск, что что-то пойдёт не так, и я, устанавливая ещё одну версию qt, запорю установленную, и у меня половина софта прекратит запускаться, в результате чего, я ещё полдня проведу не за разработкой, а за восстановлением системы.
Да, если повозиться с emerge/ebuild, то всё же можно сделать, но хорошо не получится из-за того, что придётся возиться с emerge/ebuild. Серьёзно так возиться, с каждым ebuild'ом, и с каждым прецедентом пересборки моего проекта. С учётом того, что альтернатива -- это вписать пару строк в .toml и всё заработает, отказ от ebuild однозначно полезная вещь.
>> Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например
> о, вы только что оттуда.
> Ну так-то да, но от схемы с оверлеями "собственный пакетный менеджер Qt"
> отличается только тем, что какие-то базовые репы там будут тянуть силами
> разрабов Qt и есть шанс что их не бросят. Или есть
> ещё отличия?Отличия есть де факто. Глянь на npm, pip, gem, cargo, quicklisp: они работают, в отличие от тематических оверлеев gentoo. Вот что это за различия, которые позволяют получить работоспособность -- это более сложный вопрос. Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.
> Ты пробовал это применять на практике?Да
И да, смена номера коммита приводит к редактированию одной строки. Либо в ебилде библиотеки, либо в ебилде. "Создать ебилд" конечно посложнее.
> после сборки дерево сорцов будет удалено.
нет. после сборки - нет. после установки в систему (ebuild ... merge)
> Он будет поставлен общесистемно
нет. ebuild ... install ставит в песочницу.
Ещё замечание: часть проблем ты описываешь которые суть "смешивание рабочей и сборочной среды". если подразумевать, что сборочная среда (даже в минимальном chroot-воплощении) от рабочей отделена, проблем нет.
> лянь на npm, pip, gem, cargo, quicklisp: они работают, в отличие от тематических оверлеев gentoo.
это вопрос дискуссионный. я видел всякое, например рекурсивные ошибки в gem.
> Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.
всё верно. но зачастую результатом gem/pip/cargo etc является то, что сборочная среда называется рабочей и отправляется пользователю в продакшен. это как раз то, что как пользователю мне не нравится.
обобщу. ebuild как таковой естественно не даёт законченной среды разработки для разработчика. но подразумевает что "в продакшене" никакой сборочной среды не будет, и эта функция возложена частично на разработчика, частично - на мейнтейнера. в абсолютном выигрыше - конечный пользователь. npm (обобщённо, как символ подхода) даёт разработчику среду разработки и либо среду разработки вкачивает пользователю в качестве дополнительной рабочей, либо полностью обязывает мейнтейнера обеспечить интеграцию в систему.
интересно, что ничего нового в таком подходе нет. каталог /opt для проприетарщиков, которые ничего про систему знать не хотят и валят туда все свои "библиотеки с конкретными коммитами" существует давно. с одной стороны "пакетный менеджер" конечно похвальное усовершенствование провального подхода, но мне лично кажется, что данные усилия достойны лучшего применения.
Хорошим решением я бы назвал такую систему управления исходниками и бинарями, которая бы позволяла решать задачи разработчика и пользователя легко и универсально. Т.е. нечто, что оперировало бы универсальной терминологией, включающей понятия сред разработки, рабочей среды использовало бы разные типы зависимости и при этом было полностью подконтрольно операционной системе вообще и её пакетному менеджеру в частности.
Чехарда с "пакетными менеджерами для каждого языка" даёт тактический выигрыш, но это совершеннейший стратегический тупик. Ну или как вариант - отказ от концепции операционной системы вообще, что-то типа предельного развития концепции qubernetes
>> Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.
> всё верно. но зачастую результатом gem/pip/cargo etc является то, что сборочная среда
> называется рабочей и отправляется пользователю в продакшен. это как раз то,
> что как пользователю мне не нравится.А это не проблемы разработчика. Разработчик может собрать appimage какой-нибудь, и дать пользователю бинарь. Это ок, и этот бинарь никак не зависит от сборочной среды. Либо разработчик может дать пользователю всё вместе со сборочной средой -- бери и собирай вручную. Но думать о том, как правильно интегрировать софтину в тот или иной дистр -- это не проблема разработчика. Это проблема мейнтейнера. Не, если мейнтейнер ко мне обратится, и объяснит свои проблемы, я, скорее всего, совершу какие-нибудь телодвижения, которые сделают его задачу проще. Но по своей инициативе я не полезу разбираться с тем, как в разных дистрах обустроена установка софта.
Я к тому, что мне как разработчику, нужны инструменты для разработки. Мне удобен git для разработки? Я использую git. Мне удобен cargo, я использую cargo. Я не собираюсь отказываться от удобных инструментов, в пользу тех костылей, которые "продакшн" использует для сборки.
> Хорошим решением я бы назвал такую систему управления исходниками и бинарями, которая бы позволяла решать задачи разработчика и пользователя легко и универсально.
Я бы тоже называл такую систему хорошим решением, но я очень сомневаюсь, что такая система в принципе возможна. Задачи разработчика и пользователя очень различны.
Пользователь хочет сказать что-то типа "возьми версию софтины x.y.z, скачай её, посчитай депендансы, докачай чего не хватает, обнови что надо обновить, собери и поставь. И чтоб всё работало".
Разработчик же часто жонглирует сырыми кусками кода, ему совершенно не нужно ставить софт в систему -- ещё не хватало, чтобы каждый раз когда я скачиваю библиотеку, чтобы посмотреть что она из себя представляет, у меня бы пересобиралась половина системы и потом ещё и не работало бы. Мне нужно _чёткое_ разделение системного пакетного менагера, и рабочего. Если рабочий мне собирает всё в build директории проекта, включая и депендансы тоже -- то это очень удобно, я потом сделаю rm -rf на этом build'е, и удалю всё к чертям. Если рабочий пакетный манагер выкачивает мне зависимости только под этот проект, не оглядываясь на системно-установленный у меня софт -- это удобно, это даёт мне рабочее окружение, которое минимально отличается от рабочих окружений других разработчиков, которые могут сидеть на других дистрибутивах, и при этом может они последние три года забывали обновлять софт.
Более того, для разных языков программирования нужны разные пакетные менагеры, потому как в них по-разному всё происходит. Если начать пихать в один пакетный менагер всё, что может понадобиться любому, то получится такая хрень, что через неё не продерёшься. Ты не читал историю языка программирования PL/1? В него попытались напихать всё-всё-всё. Кончилось это провалом. В Common Lisp'е довольно часто наблюдается попытка напихать в библиотеку все-все-все возможности, в результате получается ТАКОЕ, что сам чёрт ногу сломит. Это общий инженерный принцип: надо всегда решать конкретную задачу. Чем более конкретную, тем лучше. Неконкретная попытка "сделать хорошо всем" кончается кучей навоза.
> Чехарда с "пакетными менеджерами для каждого языка" даёт тактический выигрыш, но это совершеннейший стратегический тупик. Ну или как вариант - отказ от концепции операционной системы вообще, что-то типа предельного развития концепции qubernetes
Ты путаешь пакетные менагеры и пакетные менагеры. Есть системный пакетный менагер, есть пакетный менагер разработчика. Они разные и для разных целей созданы. Пакетный менагер разработчика, между прочим, делает жизнь мейнтейнера дистрибутива проще: глянь на те же autotools. ebuild в gentoo отлично пользуется autotools, делигируя им собственно сборку, но забирая себе такие задачи как копирование файлов в систему. Ничто не запрещает разработчикам ebuild'а связаться с разработчиками cargo, и объяснить свои нужды: в какие задачи выполняемые cargo им надо вмешаться, и что сделать иначе. А потом написать eclass, и может пачку скриптов, которые взаимодействуя с cargo напишут заготовку ebuild'а. Но, ты ж понимаешь, это не задача разработчиков cargo решать как лучше будет для мейнтейнеров gentoo? Скажем, надо ли в ebuild'е для растовой программы выписывать растовые депендансы? Или не надо? Может только C'шных депендансов хватит, которые как dll используются?
Разработчики gentoo в состоянии свой ebuild заточить под разные компиляторы? Почему они не могут заточить его под разные системы сборки?
> пихонежелаю его осуществления, в виде игл тебе под ногти
Пакетный менеджер в языки и фреймворки тянут для несчастных и убогих виндузятников у которых ничего нет. И у них да, проблема лишнюю библиотеку поставить. Убиться можно.А в нормальных дистрах да, есть пакетные менеджеры, есть порты и т.д.
Всёравно ни в одной серьёзной компании делающей серьёзный софт служба безопасности не пропустит эти пакетные менеджеры. Иш ты, ещё дай возможность девелоперам все подряд тянуть.
> А в нормальных дистрах да, есть пакетные менеджеры, есть порты и т.д.Использование пакетного менеджера не даёт выбрать версию зависимости. Вы хоть убейтесь, вы не сможете положить в пакет дистрибутива такую версию ангуляра (к примеру), которая устроит всех. И вы не заставите гугл поставлять тот же самый ангуляр во все дистрибутивы правильно.
А если у вас пять версий приложения, каждую из которых необходимо собирать со своей совокупностью версий зависимостей?
Возможно это говорит о том, что динамика поставки библиотек (пакетов, зависимостей, крейтов, нугетов) со временем меняется в худшую сторону.
Вот и появляются флетпаки, пакетные менеджеры и прочее.
Лучше бы рассказали как будет происходить модерация этой помойки. Пример того же Эпл стор с платой 100 долларов в год с разработчика и жесткая модерация хороший пример трешхолдера от всяких вирусописак
И тем не менее под яблоко и вирусов и ломалок более чем немало
в аппсторе? пример в студию
> в аппсторе? пример в студиюС разморозкой.
Дык и на винде в сторах вирусов едва ли найти.. и на андройде я ни разу за многие годы пользования андройдофонами вирусы не ловил, качая популярные приложения из плеймаркета.
"Внезапно" многое на яблоке устанавливается НЕ ЧЕРЕЗ АППСТОР( там много требований и нюансов помимо того, что само право пытаться выгрузить что-то в аппстор стоит денег ).
Ты ведь в курсе, что на яблоко можно устанавливать ПО не только через аппстор, не так ли ?Многое ПО распространяется обычными локальными установочниками.
Той же криты, гимпа и проч в аппсторе нет, но для яблока они есть( как и многое другое ), можно скачать установочник и "внезапно" установить без какого-либо аппстора.
Или хочешь, к примеру, добавить поддержку какой-нибудь железки на яблоко - скорее всего потребуется яблочное подобие драйверов, которые "внезапно" через аппстор не распространяются.
И кто знает, что конкретно делает установочник после запроса доступа к некоторым изменениям системных каталогов ? Особенно на ОСи, у которой по умолчанию в системе имеются и рубин и питон.
Нет ни одной. С разморозкой, а вот в Гугл плее полно там никакой модерации нет
> Нет ни одной. С разморозкой, а вот в Гугл плее полно там
> никакой модерации нетВыше ответил про модерацию, аппстор и прочую чушь.
Я не понимаю - зачем для С++ библиотеки тащить целый питон?? Им делать нечего?Есть, например, kiss (https://github.com/kisslinux/kiss) - пакетный менеджер на шелле. Тоже децентрализованный. Умеет все, что надо и не надо тащить с собой всякое говно.
Но нет, ребята не ищут легких путей. Решили повторить историю со сборочным инструментарием.
> пакетный менеджер на шеллеИ придется тащить шелл...
Шелл стоит везде, даже там где нет с++. Его не надо тащить.
Особенно на винде
> Особенно на виндеСерьезно ? Позорище.
Не волнуйтесь, скоро на Винде будет bash.
>В качестве основы будет использован пакетный менеджер СonanДа это варварство какое-то. Это говно на питоне написано. Только питона в составе Qt нам не хватало. На Meson перейти не планируют, а то переход на CMake ещё не завершился?
> Это говнопричем тут твоя мамаша?
Так%2C вспомнил Perl чегот..%0A
Gdb уже с шитоном, пакетный менеджер с шитоном, позже NodeJS прикрутят как майкрософт в visual studio, потом кубернетес и десяток девопсов, чтобы всем этим зоопарком управлять. И все это, чтобы красиво нарисовать hello world для MCU. Все больше обезьян выходят из леса в программирование :)
> пакетный менеджер также сможет использоваться для получения библиотек от сторонних производителей.Зделают рассадник вирей? Сомневаюсь что все скачанные пакеты буду сертифицированы по подписи PGP.
Маркетологи это называют больше возможностей. При том так оно и есть, возможность отсылать бес спроса данные на хакерский сервер бесценна.
> МаркетологиГнать их с ИТ!
>бес спросаВместе с бесом предложения регулирует свободный рынок.
> предложения регулирует свободный рынок.Нет никакого рынка, и уж тем более свободного.
>Сомневаюсь что все скачанные пакеты буду сертифицированы по подписи PGP.Так не качайте те, которые без подписи. Соответственно, и приложухи от Васянов, которые будут таковые использовать.