Основное дерево портежей перешло на git
winterheart 13 Августа, 2015 - 11:14
8-12 августа официальное дерево портежей gentoo-x86 было перенесено с CVS на git.
Данное изменение в основном затрагивает разработчиков, для пользователей практически ничего не изменится.
8-12 августа официальное дерево портежей gentoo-x86 было перенесено с CVS на git.
Данное изменение в основном затрагивает разработчиков, для пользователей практически ничего не изменится.
Какие же изменения заметны пользователям?
- При первой синхронизации emerge фактически заново скачает всё дерево, так как в процессе миграции все файлы ebuild были изменены на новый формат: вместо заголовка CVS был внедрен пустой заголовок git;
- Все манифесты были сконвертированы из обычных в Thin Manifest (без учета контрольных сумм ебилдов).
Прямая синхронизация git-дерева возможна и будет анонсирована позднее.
»
- Блог пользователя - winterheart
- Для комментирования войдите или зарегистрируйтесь
И это прекрасно!
И это прекрасно!
Король умер! Да здравтсвует король?
1. Доступ к старым версиям ebuild через git так и не будет осуществляться? (ну хотя бы через отдельный репозиторий)
2. Неужели на замене "# $Header: многобукаф" на "# $Id$" удалось сэкономить ~20%
3. portage - это не ядро. Выдержит ли он DVCS хранилище? Не окажется ли копия репозитория через 5 лет размером в десятки гигабайт.
UPD. по п.2:
а) + Удалены старые ChangeLog
b) + Thin Manifest существенно "тоньше"
Отсюда (из 2.b) вопрос 4:
4. Теперь подписывать свои ebuild нет необходимости? А доверие к overlay? Подписи содержимого files теперь нет. Как всё это скажется на безопасности?
Summary. Во что оцениваются перспективы (и проводилась ли такая оценка) и достойна ли история такого отношения к ней?
------
PS. "Король умер! Да здравствует король!" довела Францию до революции, свергшей монархию.
у меня манифесты теперь
у меня манифесты теперь перезаписываются при каждом обновлении дерева. Не могу сказать, что все, но много. Это нормально?
Нет, но мы в курсе проблемы.
Нет, но мы в курсе проблемы. Подробности - https://bugs.gentoo.org/show_bug.cgi?id=557192
Нейтральность - высшее достижение сознания!
Всех с наступающим Днем Победы!
- Пап, а кто такие фашисты?
- Это очень плохие люди, сынок! Они мучают других людей, издеваются над
ними. Они хотят лишить нас свободы, сынок!
- Как модераторы у нас на форуме?
- Хотя с другой стороны, сынок, не так уж эти фашисты и плохи.
:)
Kevol написал(а): Отсюда (из
С чего это? Подписываются сами коммиты в git и push
Нейтральность - высшее достижение сознания!
.
То есть emerge/ebuild будут обращаться к git во время установки пакета для сверки этих подписей?
Или проверка всего git будет происходить в начале установки набора пакетов?
/
Вопрос конечно интересный и важный, но…
Справедливости ради следовало бы сначала спросить как аналогичная задача решалась на предыдущем этапе (при использовании CVS)?
По моим наблюдениям практических покушений не было не только в Gentoo. Рекомендации по добавлению репозиториев в бинарных дистрах хорошо если не поголовно вполне подобны известной ереси (#14443).
Хотя бы определиться с подходом к решению было бы важно и нужно.
Слово тов. Pinkbyte, как товарищу, который должен быть в теме. И которому это по профилю (ибо он в Security Team).
:wq
--
Live free or die
.
Мне как разработчику, использующему git для контроля развития проекта, прежде всего странно: видеть применение git для portage.
A. Portage сам по себе представляет систему управления версиями. Конечно версиями билдов пакетов, а не самого portage. (Плюс он берет на себя сохранность прилагаемых файлов.)
B. Git является системой контроля изменений (хотя многие говорят по привычке "версий"). Основной задачей системы является оперирование дельтами (diff). Эти дельты имеют смысл только по применению к конкретному объекту-файлу (причем только подходящей версии/состояния/содержимого). В совокупности это позволяет отслеживать историю происхождения строк в файлах. Одной из ключевых особенностей (ИМХО недостатком) является отсутствие явного управления происхождением файла.
Суммируя A и B получаем, что в portage git может оперировать только срезами истории. Этого достаточно для сопровождения базы бинарных пакетов. Но для текстовых описаний билдов крайне (что мягко сказано) полезным является получение истории развития скриптов. Иначе применение git, является чуть более технологичным методом, чем набор архивов, создаваемых после каждого атомарного изменения portage.
В силу собственной лени, не изучая другие доступные на данный момент DCVS/DVCS, не могу предложить более подходящую систему, но полагаю, что есть более подходящее по архитектуре для portage решение.
Сопровождая собственные маленькие ebuild для внутреннего использования пакетов, был вынужден тащить версию 9999, которая показывала в git-е историю развития. Но я сам являлся как мантайнером, так и разработчиком. То есть у меня отсутствовали всякие r1-r2 латающие старые стабильные версии. Если что, легче стабилизировать последнюю :) .
Вот примерчик:
Есть пакет foo/bar версии 1.2.3, который когда-то имел предыдущие версии с foo/bar-1.2.0.ebuild, foo/bar-1.2.1.ebuild, foo/bar-1.2.2.ebuild.
Он стабилизировался в foo/bar-1.2.3.ebuild
Но нашли ошибку, которую латает patch1. Выпустили foo/bar-1.2.3-r1.ebuild
Автор выпустил пакет foo/bar-1.2.4. Он нестабильный.
Вот нашли уязвимость, которую надо залатать patch2. В связи с чем выпустили foo/bar-1.2.3-r2.ebuild и foo/bar-1.2.4-r1.ebuild
Теперь в foo находится только
bar-1.2.3-r2.ebuild
bar-1.2.4-r1.ebuild
И что может предложить для просмотра истории изменений содержимого каждого из этих файлов git? Что говорить о моментах появления нестабильного, стабилизации и удаления по устареванию, когда присутствуют и изменяют состав родственные текстовые файлы?
PS. Из-за такой особенности пришлось жестко отказаться от былой привычки по SVN держать равнодоступные различные версии подразделов (проектов/подпроектов). В git возможна доступность к разноверсионности только при использовании ветвей, которые уже не являются каталогами.
/
ГОСТ не зря рекомендует начинать с описания прикладного уровня.
Полагаю правильным начинать с формализации и согласования требований, предъявляемых
portage'м к СКВ.И не стал бы сразу вписываться в соответствие этим требованиям некоторой существующей СКВ.
:wq
--
Live free or die
.
Интересно, а этот ответ кто-то кроме меня смог понять?
Согласен. Но не понятно, что из этого проводилось в команде gentoo.
Kevol написал(а): B. Git
А вот и нет, git работает несколько по другому. Он хранит файлы целиком, дельты вычисляются только при git fetch/push/...
Working on Gentoo Linux for Asus P535 and Qtopia :-)
.
Когда я писал данное утверждение, то был в курсе о внутреннем представлении. Конечно, такая внутренняя организация помогает решать достаточно сложные преобразования узлов дерева. Но вопрос состоит в том, чтобы следить за процессом наследования информации. А здесь структура и развитие информации для portage и ядра в корне различаются. Данная проблема является частой при миграции с Subversion на Git. Поэтому пользователям svn отсутствие множественного наследования в git является достаточно поздно осознанной неожиданностью. И если в большинстве реальных проектов удается переосмыслить способ организации, когда в едином дереве репозитория сосуществуют множества проектов имеющих родственные связи, но находящихся на разных стадиях развития, а в родном для git ядре данных вопросов не существует как класс, то для portage множественные родственные связи между ebuild (и не только) являются ключевым моментом.
git vs svn?
Не совсем согласен с родственными связями, проблема с перемещенными и переименованными файлами в git сделана намного лучше чем в том же subversion.
Можно подробнее?
Working on Gentoo Linux for Asus P535 and Qtopia :-)
подробнее
Можно, конечно еще больше приблизить пример к операциям с ebuild, но я надеюсь смысл уже здесь должен быть понятен.
Про опции -M -C для annotate, log я в курсе. Заставить отобразить правильную историю b у меня не вышло.
Суть проблемы в том, что такая работа с исходными текстами проекте признак плохого стиля. Информация должна быть указана в одном месте. Но в portage как раз это на оборот. Причина? Да в portage находится не исходная информация и правила ее обработки, а уже обработанная информация. Просто обрабатывается она пока вручную - вот это состояние стабильное, вот здесь мы создаем ебилд для новой версии, вот тот ебилд мы скорректируем и присвоим ему новый номер, а теперь стабилизируем вот этот ебилд, а потом почистим устаревшие. В итоге хоть и куча родственников, а ни внутренне содержимое, ни наследование не имеет истории в системе контроля версий. Можно получить конечно слайдшоу состояний и в голове восстанавливать происхождение содержимого.
В итоге, ебилд можно рассматривать как единое целое - "вот так оно правильно причем сейчас, как было когда-то не имеет смысла, но если что - можно поднять архивы и во всем разобраться, но кому это нужно".
Ну да, все верно. Только я не
Ну да, все верно. Только я не понял, а в чем недостаток то? Сам ведь говоришь, дерево портажа - не исходники. Зачем нужно знать "правильную" историю файла b?
Ответить на комментарий | Russian Gentoo Linux Community
I read this paragraph fully about the difference of latest
and previous technologies, it's remarkable article.
Take a look at my page :: Mikki - http://margaret3703.wikidot.com/blog:7
git --no-pager log --follow b
Я думаю вы не пробовали параметр --follow:
Date: Thu Sep 24 22:11:42 2015 +0300
commit b5f6c9c873b614fb540e1dc710e7c390303941b9
Author: Oleh Kravchenko
3
a => b | 0
1 file changed, 0 insertions(+), 0 deletions(-)
commit d00cfaea1f0e61b7ea395788b891a45df88e1e0c
Date: Thu Sep 24 22:11:42 2015 +0300
Author: Oleh Kravchenko
2
a | 4 ++++
1 file changed, 4 insertions(+)
commit 0c1b3e85b2a11a2e05c7b3d174ec4731826daf45
Date: Thu Sep 24 22:11:41 2015 +0300
Author: Oleh Kravchenko
1
a | 4 ++++
1 file changed, 4 insertions(+)
commit fae6adcc3d39b82a97ebf092063582fcad8fcbaf
Date: Thu Sep 24 22:11:41 2015 +0300
Author: Oleh Kravchenko
0
a | 0
1 file changed, 0 insertions(+), 0 deletions(-)
Working on Gentoo Linux for Asus P535 and Qtopia :-)
для тупых можно ? есть ебилд
для тупых можно ?
есть ебилд foo/bar-0.01_rc1.ebuild
При стабилизации в апстриме коммитер естественно делает из него foo/bar-0.01.ebuild.
После тестов arch находим баги и правим - добавляем патчи - > foo/bar-0.01-r1.ebuild
Арчи его стабилизируют - foo/bar-0.01-r1.ebuild ( ~amd64 -> amd64 ) -> получаем еще 5-10 модификаций файла.
Проблема в том, что это тот же самый пакет, и информация об изменениях размазана между гитом и файловой системой.
Т.Е гит решил только 2 проблемы:
1. "Ребята, с 14.00 я буду заливать кде, не коммитьте в дерево ничего"
2. Ой, у меня пропал интернет.
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а): есть
Будем считать что он закомичен;
Делает коммит;
Опять же, я надеюсь делает коммит;
Коммит ведь да?
И все таки, в чем проблема? Если фиксировать изменения, то никаких проблем не будет.
Working on Gentoo Linux for Asus P535 and Qtopia :-)