sys-apps/portage-2.2.0

Сейчас тестируется все вручную, стабилизируется по запросу пользователей.

Тестируют - когда как. Иногда вручную, иногда скриптами. Вручную чаще всего надежнее, потому что факт сборки пакета - еще не факт его работы. И если сборку можно автоматизировать, то проверку работоспособности - далеко не всегда.

Далее - запросы делают как разработчики, так и пользователи. В идеале - за стабилизацией следит maintainer

Что ты подразумеваешь под упрощением стабилизации?

С одной стороны, udisks-2 в стабильной, а стабильный wine тянет udisks-1

Не является багом - udisks слотирован

С другой стороны, стабильный asymptote требует нестабильного TeX Live 2013, трагичность ситуации в том, что версия asymptote под стабильный TeX Live 2012 уже выпилена из дерева.

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

Ссылку на багрепорт, пожалста.

Извини, не посчитал это серьезным багом, поскольку далеко не на всех файлах проявляется. Вот он в явном виде: https://bugs.archlinux.org/task/32685 Трабла в том, что шустрые разработчики включили туда фичи, зависящие от TeX Live 2013, который не стабилизирован. Методом тыка выявил, что в стабильной ветке должен быть asymptote-2.16, где этого бага нет, у меня в оверлее. Этот баг должен быть исправлен?

Та же ситуация что и везде - 'lack of manpower'. Наш «бог стабилизации»(за ним числится где-то 80-90% устабилизированных пакетов на некоторых архитектурах) - Agostino Sarubbo один за всем не успевает.

О, не знал об этом. Так что, стабильная ветка еле шевелится, и лучше таки переходить на unstable?

стабильная ветка еле шевелится, и лучше таки переходить на unstable?

Переходить можно, но факапов на unstable может быть больше и нужно быть к этому готовым(неслучайно я люблю повторять - «enjoy your unstable»). Если готов писать багрепорты и пинать народ в IRC(для ускорения процесса исправления багов :-)) - welcome. А если не готов и будешь ныть потом «всё сломали, всё пропало», как некоторые(и такое бывает, unstable же) - лучше не стоит.

За сломаный unstable в среде разработчиков могут сказать «oops, shit happens», за сломаный stable могут и яйца прищемить, ну ты понел.

Почитал багрепорт... Честно, не побоюсь признаться - ничего не понял. Я с техом знаком ээээ... никак :-). Если не затруднит - отправь багрепорт с описанием проблемы на bugs.gentoo.org, ссылку - сюда, я переназначу кому надо - пусть думают

А переход на git всё затягивается :-(

если не трудно — озвучт последние (инсайдерские) новости с того фронта

Последних новостей не знаю, вроде как «major blockers for git migration are resolved» (c) Rich Freeman(вроде бы). Но у Gentoo Infrastructure по прежнему есть какие-то трудности. А вообще следить за https://bugs.gentoo.org/show_bug.cgi?id=333531 - самый верный вариант ;-)

https://bugs.gentoo.org/show_bug.cgi?id=481076

А когда portage перейдёт на гит взамен rsync?

Вручную чаще всего надежнее, потому что факт сборки пакета - еще не факт его работы. И если сборку можно автоматизировать, то проверку работоспособности - далеко не всегда.

Да, но проблемы со сборкой чаще встречаются из-за постоянных изменений и проблем с версиями. Если хотя бы их решить, уже станет намного легче.

Что ты подразумеваешь под упрощением стабилизации?

Чтобы пакеты попадали в стабильную ветку не через 3-4 месяца (а то и никогда) после релиза, а как только они собрались и запустились успешно. Я например перешел на ~ из-за того, что проблем со сборкой в стабильной и ~ примерно одинаково, зато не нужно размаскировать полсистемы для актуальных версий.

Еще из простых способов упростить разработку — добавить портежу feature автоматической отправки багрепортов (или какой-нибудь статистики, чтобы не захламлять багзиллу этими репортами) с emerge --info, логами и всем нужным для того, чтобы оперативно увидеть какой пакет и почему не собрался. Затем сервер смотрит, кто занимается этим пакетом и спамит им на почту. Сложного ничего, реализуется элементарно.

в условиях CVS это практически невозможно :-(

Там нет веток?

Пользователи вроде меня были бы рады помочь, если бы не сложность. Когда у меня не собирается пакет, мне проще его замаскировать, чем вспоминать пароль от багзиллы, выкладывать вручную логи на пасту, описывать ситуацию. Если портеж будет выдавать «Build failed. Would you like to submit a report?» и затем проводить короткий опросник «что ты делал прошлым вечером» и автоматом отправлять все логи, от меня будут идти сотни репортов :)

major blockers for git migration are resolved

в depend`сах 8 багов. 4 сделаны, 4ре нет (из них 1 «in progress»). я понимаю что «lack of manpower» и все такое. но ненадо было прошлого? года вещать что до конца года все будет з@36ись сделаем

А когда portage перейдёт на гит взамен rsync?

Профитов для перехода синхронизации end-user'а практически нет. В данный момент кстати можно использовать CVS вместо rsync, но тогда не будет кэша метаданных и небыстрый portage станет еще более небыстрым :-/. С git будет та же песня

Сложного ничего, реализуется элементарно.

Предложи референсную реализацию :-). А то запланированных feature просто пруд пруди, а кода почти нет :-(

Чтобы пакеты попадали в стабильную ветку не через 3-4 месяца (а то и никогда) после релиза, а как только они собрались и запустились успешно.

Без длительного тестирования это будет очень хреновый stable. Devmanual рекомендует начинать стабилизацию не раньше чем через 30 дней после попадания пакета в дерево не от хорошей жизни...

Понятно. Всё же неторопливость портежа несколько удручает. Пробовал перевести его на pypy2, но прироста в скорости вообще не заметил.

Интересно, если загнать дерево в базу, это добавить портежу прыти?

Предложи референсную реализацию :-)

Дай ман, как работать с портежом и куда это нужно запиливать. А то я даже ебилдописание не очень осилил: 9000 разных мануалов, а потом в ирке говорят забыть все чему меня учили, потому что апи уже поменялось и надо писать вот так (и тут дают 9001 мануал).

Там нет веток?

Есть, но они еще более упоротые чем в svn(точнее наоборот - в svn они менее упоротые, потому что svn появилось позже)

Создай фичреквест на багзилле :-)
Может у Portage team будут какие-нибудь идеи на этот счет

Оке.

ну так 4 оставшихся - это не major :-)
Просто нужно их решить. А вот из закрытых один был связаном с тем что при конвертации из cvs в git пролюбливались UTF-8 символы

Интересно, если загнать дерево в базу, это добавить портежу прыти?

Всё это - полумеры. Пока portage будет считать зависимости, задействуя только одно ядро - далеко мы не уйдем :-/. Portage team утверждает, что в текущем состоянии распараллелить алгоритм не представляется возможным без его полного переписывания - а это адЪ.

https://bugs.gentoo.org/show_bug.cgi?id=481128

Дай ман, как работать с портежом и куда это нужно запиливать.

в сырцах есть кое-какая документация(DEVELOPING, docs), также есть пояснения на странице проекта, но вообще sources is the best documentation :-)

9000 разных мануалов

1 основной и по 1 на каждый большой eclass. Ничего сложного, ИМХО. Ну и знание самой утилиты/языка на котором она написана, на которую пишешь ебилд. Я вот например не знаю Ruby - потому мне не нужно знать ruby eclass - всё равно ничего не пойму :-).

потому что апи уже поменялось и надо писать вот так (и тут дают 9001 мануал).

ну так тут надо выбирать либо чтоб ебилд был в главном дереве и его могли поддерживать другие люди, либо пихать в свой оверлей где QA может быть какое захочешь(вплоть до никакого)

Ок, по свободе посмотрю (мечты-мечты, лол).

С git будет та же песня

почему же тогда калька так не считает?

http://www.calculate-linux.org/blogs/en/320/show

также нужно сказать что используется ЯП, который «не совсем параллелится»

:)

а теперь тот, что «in progress» не делается ибо они пока не знают как более правильно сравнить данные в гите и цвс..

все-таки «лак оф манповер» присутствует.

<crazy idea>
обьеденить сообщества разработчиков генты и слаки. для слакварщиков создать новый профиль с единственным флагом "vanilla". а слак-девов напрячь помогать делать таски гентушников
</crazy idea>

для начала было неплохо посмотреть на прародителя

Проект pkgng был создан как попытка кардинальной переработки инструментария pkg_install, исторически сложившиеся ограничения в котором существенно мешают развитию инфраструктуры портов, которая вынуждена работать с оглядкой на устаревший инструментарий. Например, вместо корректной и оптимальной реализации тех или иных возможностей, разработчикам до сих пор приходилось выдумывать различные «хаки» в Mk/bsd.*.mk и метаданных. Предпринимаемые ранее попытки создания более современных утилит, например, portmaster и portupgrade, также в конечном счёте упирались в ограничения pkg_install

Метаданные оформлены в виде текстового файла «+MANIFEST» в формате YAML и содержат всю информацию о пакете и определение особенностей его обработки

yaml вашу мать а не bash

http://www.opennet.ru/opennews/art.shtml?num=34739

чойто полчаса он 15 минут отсилы собирается!

кстати в идее есть большая сложность, т.к. существует очень широкий спектр ошибок, которые заведомо будут WONTFIX. Поэтому в случае ошибки во-первых нужно проводить анализ и предлагать пересобрать в более безопасной конфирурации (безопасные флаги, не-9999 или наоборот 9999, без микса ~arch arch, с локалью C, прогнать сначала *-updater, с disable-silent-rules, ещё куча специфичных для программы случаев), а потом уже делать баг :)

существует очень широкий спектр ошибок, которые заведомо будут WONTFIX

Можно на стороне сервера написать фильтры, которые будут именно эти известные ошибки пропускать.

почему же тогда калька так не считает?

либо всегда хранить дерево с глубиной 1, либо оно начнет жрать место и тормозить. Плюс калькулейт в дерево не коммитит, так что на кучу коммитов в дерево будет один большой коммит в кальку.

Идеальные варианты для обычного юзера это или web-delta-rsync, или bdiff от squashfs (но это пока не допилено, хотя идеи были).

я думаю дело всего-лишь во фреймворке для простого описания проверок адекватности багов :)

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

я и говорю, нужен фреймворк, в который можно достаточно просто загнать тесты. Причем желательно, чтобы часть их прогонялась на юзерской машине :).

Вот насчет юзерской машины — очень сомневаюсь. Потому что мейнтейнеры должны по мере работы добавлять в список известные проблемы (чтобы они не дублировались) и удалять wontfix-проблемы. Юзеру придется обновлять базу этих штук довольно часто, да и по объему она может быть немаленькая.

например проверка: остуствие микса ~arch и arch. Для того, чтобы её сделать на сервере юзеру нужно скинуть инфу о всех зависимостях. Проверка того, что нету зависимостей из неофициальных оверлеев. Проверка того, что ебилд не модифицирован.

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

остуствие микса ~arch и arch

А разве нельзя так делать? Это лишает поддержки мейнтейнеров?

Жалко лето кончилось, т.к. такую вещь можно было бы в GSoC протолкнуть.

Есть следующее лето, спешить нам некуда :)

почему же тогда калька так не считает?

Потому что они выстраивали свою инфраструктуру с нуля и забота об обратная совместимости их не тяготила.

который «не совсем параллелится»

Если ты насчет GIL то его таки можно обойти(по крайней мере в Python 3.*), другое дело что, как я уже сказал, сам алгоритм на это как бы не рассчитан :-(