Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for MCUs 1.5, opennews (??), 29-Окт-20, (0) [смотреть все] Хорошая новость, обожаю QT , Аноним (1), 13:09 , 29-Окт-20, (1) +2 // комментарий про QuickTime , Аноним (3), 13:24 , 29-Окт-20, (3) +27 // Оно уже умерло Начиная с каталины, даже на родной ему макоси , Анонимленьлогиниться (?), 00:20 , 30-Окт-20, (65) –1 Ага, хохма уже десятилетия живет, но народ по-прежнему неаккуратен в заявлениях , Аноним (77), 09:13 , 30-Окт-20, (77) чувак, t маленькая, m.makhno (ok), 13:39 , 29-Окт-20, (11) +4 // Может он регистронезависимый , bergentroll (ok), 18:42 , 29-Окт-20, (44) +5 // Регистро-диссидент , Аноним (48), 19:10 , 29-Окт-20, (48) +7 Тяжёлый, раздутый, тормозной Qt , Аноним (-), 21:51 , 29-Окт-20, (55) –8 // для микроконтроллеров и маломощных устройств , Bdfybec (?), 23:27 , 29-Окт-20, (63) +1 Поясните для неразбирающихся Это нечто на манер склоняемого тут на тему дыр и з, ryoken (ok), 13:19 , 29-Окт-20, (2) +2 // Вы ничего не понимаете В НПМ дыры неправильные, а в кутях будут - правильные и , Lex (??), 13:28 , 29-Окт-20, (4) +8 // Фрактал не одобрит, так что мимо, Аноним (26), 15:20 , 29-Окт-20, (26) +1 // что такое фрактал че за мальденброт , Myyx (?), 16:04 , 02-Ноя-20, (105) В пакетном менеджере Qt будут правильные одобренные сишные дыры, Аноним (41), 18:26 , 29-Окт-20, (41) +2 // сиплюшплюшные, Аноним (42), 18:34 , 29-Окт-20, (42) +3 сплюснутые дыры, Аноним (98), 16:08 , 31-Окт-20, (98) +1 Нет, это что-то вроде pip для путхона, ИмяХ (?), 14:06 , 29-Окт-20, (15) +2 // Это в котором дырки для питона , Аноним (16), 14:09 , 29-Окт-20, (16) +3 // Да, как в cargo для растишки , Аноним (19), 14:29 , 29-Окт-20, (19) Скрыто модератором, Аноним (-), 18:04 , 29-Окт-20, (37) –5 // Скрыто модератором, Аноним (67), 00:53 , 30-Окт-20, (67) // Скрыто модератором, Аноним (72), 06:30 , 30-Окт-20, (72) Нет, к conan можно подключать репозитории, но в официальный абы кого не пускают , bergentroll (ok), 18:44 , 29-Окт-20, (45) Ты не понял Это - другое , liberal (?), 02:05 , 31-Окт-20, (92) С это такой удобный язык, что даже пакетный менеджер conan для него написан н, Аноним (5), 13:32 , 29-Окт-20, (5) +6 // Скажи спасибо, что не на Расте , Няшная Сишечка (?), 13:36 , 29-Окт-20, (7) –3 // Скорее обидно, что не на хорошем языке Расте , а на каком-то там пистоне, Аноним (58), 22:51 , 29-Окт-20, (58) –1 нынче просто ленивые все, пакетный менеджер им подавай, James Bond (?), 13:36 , 29-Окт-20, (8) // Нынче только ленивые не делают свой пакетный менеджер , Аноним (28), 15:22 , 29-Окт-20, (28) +5 Ваш комментарий ни о чём Сайты тоже можно писать на С Wt , но пишут на PHP , Аноним (10), 13:39 , 29-Окт-20, (10) +1 Я вообще о его существовании слышу в первый раз И даже для питона не испльзую э, Аноним (17), 14:20 , 29-Окт-20, (17) –4 // для разработки же, не для эндюзера , Аноним (25), 14:56 , 29-Окт-20, (25) А, так вот чем достигаются рекордные числа пакетов у разных дистрибутивов - они , НяшМяш (ok), 15:57 , 29-Окт-20, (31) Который из Их, наверное, с десяток как минимум , Аноним (29), 15:51 , 29-Окт-20, (29) Conan не для С , он для Qt, ИмяХ (?), 16:43 , 29-Окт-20, (35) –3 // Для C , bergentroll (ok), 18:46 , 29-Окт-20, (46) +1 Перечитайте новость и пройдите по ссылке на Conan Conan - для плюсов, а то чт, Аноним (77), 09:17 , 30-Окт-20, (78) почти как ВИЧ для онкобольных , Аноним (6), 13:32 , 29-Окт-20, (6) –7 // О Между прочим, первый в истории человек, излечившийся от ВИЧ, излечился как ра, Armagor (??), 14:05 , 29-Окт-20, (14) +2 // Мораль используйте Gay Tool Kit Так , Аноним (17), 14:30 , 29-Окт-20, (20) +2 Мораль проста врачепорцы, антипрививочники и прочий генетический мусор должны у, Аноним (19), 14:30 , 29-Окт-20, (21) // Врачепорцы это кто такие , Аноним (28), 15:20 , 29-Окт-20, (27) +1 Муж дамы-врача , Аноним (47), 18:57 , 29-Окт-20, (47) +1 муж целомудренной дамы-врача, Lex (??), 21:13 , 29-Окт-20, (53) –1 вот именно, умер от того, чем лечили , Аноним (98), 14:47 , 29-Окт-20, (23) +1 Скрыто модератором, Аноним (-), 18:15 , 29-Окт-20, (39) +4 // Скрыто модератором, Аноним (61), 23:13 , 29-Окт-20, (61) Скрыто модератором, Ordu (ok), 06:38 , 30-Окт-20, (73) Скрыто модератором, 486SX25 (?), 07:00 , 30-Окт-20, (76) Вчера был ВИЧ спид https www linux org ru forum talks 2529338https www linux, Аноним (72), 06:41 , 30-Окт-20, (74) // Методы проведения геноцида поменяли, с негуманных фашиских концлагерей и газовых, Аноним (72), 06:44 , 30-Окт-20, (75) +2 // Добавь сюда асфиксию от ношения намордников, смертоносные протоколы лечения и , xESKOBARx (?), 00:57 , 31-Окт-20, (91) нет курение вредит а вот совершенно неттак то , Myyx (?), 16:10 , 02-Ноя-20, (106) Всем свой пакетный менеджер , pda (?), 13:37 , 29-Окт-20, (9) // Заверните парочку для asm , ryoken (ok), 13:44 , 29-Окт-20, (13) +2 // асм использует хардварный, bootforce (?), 20:23 , 31-Окт-20, (101) Рак плюсов, то свои дебильные системы сборки пропихнут, то убогий conan когда ес, Аноним (12), 13:44 , 29-Окт-20, (12) –4 // Правильно, собирать надо только компилятором а пакеты устанавливать исключительн, Аноним (17), 14:27 , 29-Окт-20, (18) +1 // Как же хочецца , Аноним (29), 15:55 , 29-Окт-20, (30) vcpkg конечно же неплох, но в отличии от Conan он принципиально не поддерживает , vcpkg (?), 17:52 , 29-Окт-20, (36) // поддерживает https github com microsoft vcpkg blob master docs specifications , fsb4000 (?), 18:15 , 29-Окт-20, (38) +1 Ну вот зачем он нежен, да ещё и на пихоне rpm их чем не устраивает , Ilya Indigo (ok), 14:40 , 29-Окт-20, (22) // сделано не ими с , Аноним (98), 14:48 , 29-Окт-20, (24) –1 Мсье желает по жестче Как на счет вставить_очередную_шутку_про_раст , Аноним (29), 15:59 , 29-Окт-20, (32) –1 RPM нежный , m.makhno (ok), 16:04 , 29-Окт-20, (33) –4 // очень, особенно когда база блокируется и потом сыпется тебе нежно потом намекаю, анонимуслинус (?), 20:36 , 29-Окт-20, (52) –1 C разработчики тоже люди и хотят нежности , Аноним (34), 16:32 , 29-Окт-20, (34) // Тогда пора переходить на Раст Плюсы после него - неудобный мусор Уже и не гово, Аноним (58), 22:54 , 29-Окт-20, (59) +2 // Хорошая попытка, анон , Аноним (99), 17:45 , 31-Окт-20, (99) –1 Я тоже за нежный пихон А рпм слишком груб , Аноним (-), 18:19 , 29-Окт-20, (40) Системные пакетные манагеры неудобны для разработки Если я пользуюсь библиотеко, Ordu (ok), 23:25 , 29-Окт-20, (62) +3 // Благодарю за разъяснение Из текста новостей про Qt6 не понятно было что именно э, Ilya Indigo (ok), 23:36 , 29-Окт-20, (64) –1 вам к source-based, портежи умеют в это о, вы только что оттуда Ну так-то да, н, Котофалк (?), 12:31 , 30-Окт-20, (83)   // Ты пробовал это применять на практике Я тебя заверяю, гораздо проще жить, имея , Ordu (ok), 17:39 , 30-Окт-20, (90)   ДаИ да, смена номера коммита приводит к редактированию одной строки Либо в ебил, Котофалк (?), 15:04 , 23-Дек-20, (107)   А это не проблемы разработчика Разработчик может собрать appimage какой-нибудь,, Ordu (ok), 15:55 , 23-Дек-20, (108)   желаю его осуществления, в виде игл тебе под ногти , Аноним (68), 01:33 , 30-Окт-20, (68) +1 Пакетный менеджер в языки и фреймворки тянут для несчастных и убогих виндузятник, niger (??), 16:52 , 30-Окт-20, (88) +2 // Использование пакетного менеджера не даёт выбрать версию зависимости Вы хоть уб, банан (?), 08:48 , 01-Ноя-20, (102) Лучше бы рассказали как будет происходить модерация этой помойки Пример того же, Аноним (41), 18:37 , 29-Окт-20, (43) –1 // И тем не менее под яблоко и вирусов и ломалок более чем немало, Lex (??), 22:03 , 29-Окт-20, (57) –2 // в аппсторе пример в студию, Аноним (68), 01:34 , 30-Окт-20, (69) // С разморозкой Дык и на винде в сторах вирусов едва ли найти и на андройде я ни, Lex (??), 12:35 , 30-Окт-20, (84) Нет ни одной С разморозкой, а вот в Гугл плее полно там никакой модерации нет, Аноним (80), 09:58 , 30-Окт-20, (80) –3 // Выше ответил про модерацию, аппстор и прочую чушь , Lex (??), 12:35 , 30-Окт-20, (85) Я не понимаю - зачем для С библиотеки тащить целый питон Им делать нечего Ес, Урри (?), 19:19 , 29-Окт-20, (49) –3 // И придется тащить шелл , Аноним (58), 22:56 , 29-Окт-20, (60) –1 // Шелл стоит везде, даже там где нет с Его не надо тащить , Аноним (82), 10:34 , 30-Окт-20, (82) +1 // Особенно на винде, Аноним (58), 13:42 , 30-Окт-20, (86) –1 Серьезно Позорище , Аноним (-), 14:09 , 31-Окт-20, (94) Не волнуйтесь, скоро на Винде будет bash , Аноним (103), 14:35 , 01-Ноя-20, (103) +1 Скрыто модератором, Аноним (51), 20:27 , 29-Окт-20, (51) // Скрыто модератором, Аноним (-), 09:20 , 30-Окт-20, (79) –2 Так 2C вспомнил Perl чегот 0A, user90 (?), 21:51 , 29-Окт-20, (56) Gdb уже с шитоном, пакетный менеджер с шитоном, позже NodeJS прикрутят как майкр, Аноним (66), 00:51 , 30-Окт-20, (66) +2 Зделают рассадник вирей Сомневаюсь что все скачанные пакеты буду сертифицирован, Аноним (72), 06:24 , 30-Окт-20, (71) +1 // Маркетологи это называют больше возможностей При том так оно и есть, возможност, Аноним (80), 10:01 , 30-Окт-20, (81) // Гнать их с ИТ , Аноним (87), 15:17 , 30-Окт-20, (87) Вместе с бесом предложения регулирует свободный рынок , Аноньимъс (?), 11:16 , 31-Окт-20, (93) // Нет никакого рынка, и уж тем более свободного , Аноним (-), 14:11 , 31-Окт-20, (95) +1 Так не качайте те, которые без подписи Соответственно, и приложухи от Васянов, , Аноним (103), 14:41 , 01-Ноя-20, (104) –1 1,2,5,6,9,12,22,43,49,56,66,71

Сообщения

[Сортировка по времени | RSS]

	83. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."	+/–
	Сообщение от Котофалк (?), 30-Окт-20, 12:31
	> я хочу иметь возможность использовать даже не версию библиотеки, а конкретный git-commit вам к source-based, портежи умеют в это. > Когда-то я пробовал пользовать тематические оверлеи для gentoo, под common-lisp например о, вы только что оттуда. Ну так-то да, но от схемы с оверлеями "собственный пакетный менеджер Qt" отличается только тем, что какие-то базовые репы там будут тянуть силами разрабов Qt и есть шанс что их не бросят. Или есть ещё отличия?
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	90. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."	+/–
	Сообщение от Ordu (ok), 30-Окт-20, 17:39
	>> я хочу иметь возможность использовать даже не версию библиотеки, а конкретный 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. Вот что это за различия, которые позволяют получить работоспособность -- это более сложный вопрос. Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."	+/–
	Сообщение от Котофалк (?), 23-Дек-20, 15:04
	> Ты пробовал это применять на практике? Да И да, смена номера коммита приводит к редактированию одной строки. Либо в ебилде библиотеки, либо в ебилде. "Создать ебилд" конечно посложнее. > после сборки дерево сорцов будет удалено. нет. после сборки - нет. после установки в систему (ebuild ... merge) > Он будет поставлен общесистемно нет. ebuild ... install ставит в песочницу. Ещё замечание: часть проблем ты описываешь которые суть "смешивание рабочей и сборочной среды". если подразумевать, что сборочная среда (даже в минимальном chroot-воплощении) от рабочей отделена, проблем нет. > лянь на npm, pip, gem, cargo, quicklisp: они работают, в отличие от тематических оверлеев gentoo. это вопрос дискуссионный. я видел всякое, например рекурсивные ошибки в gem. > Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран. всё верно. но зачастую результатом gem/pip/cargo etc является то, что сборочная среда называется рабочей и отправляется пользователю в продакшен. это как раз то, что как пользователю мне не нравится. обобщу. ebuild как таковой естественно не даёт законченной среды разработки для разработчика. но подразумевает что "в продакшене" никакой сборочной среды не будет, и эта функция возложена частично на разработчика, частично - на мейнтейнера. в абсолютном выигрыше - конечный пользователь. npm (обобщённо, как символ подхода) даёт разработчику среду разработки и либо среду разработки вкачивает пользователю в качестве дополнительной рабочей, либо полностью обязывает мейнтейнера обеспечить интеграцию в систему. интересно, что ничего нового в таком подходе нет. каталог /opt для проприетарщиков, которые ничего про систему знать не хотят и валят туда все свои "библиотеки с конкретными коммитами" существует давно. с одной стороны "пакетный менеджер" конечно похвальное усовершенствование провального подхода, но мне лично кажется, что данные усилия достойны лучшего применения. Хорошим решением я бы назвал такую систему управления исходниками и бинарями, которая бы позволяла решать задачи разработчика и пользователя легко и универсально. Т.е. нечто, что оперировало бы универсальной терминологией, включающей понятия сред разработки, рабочей среды использовало бы разные типы зависимости и при этом было полностью подконтрольно операционной системе вообще и её пакетному менеджеру в частности. Чехарда с "пакетными менеджерами для каждого языка" даёт тактический выигрыш, но это совершеннейший стратегический тупик. Ну или как вариант - отказ от концепции операционной системы вообще, что-то типа предельного развития концепции  qubernetes
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Для Qt 6 развивается пакетный менеджер. Выпуск Выпуск Qt for..."	+/–
	Сообщение от Ordu (ok), 23-Дек-20, 15:55
	>> Я полагаю дело в том, что разработчику проекта максимально упрощается задача создания "пакета", который может быть автоматически скачан вместе со всеми депендансами и собран. > всё верно. но зачастую результатом 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 заточить под разные компиляторы? Почему они не могут заточить его под разные системы сборки?
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема