On Thu, Aug 30, 2007 at 09:27:57PM +0400, Alexey Tourbin wrote: > On Thu, Aug 30, 2007 at 08:00:43PM +0400, Dmitry V. Levin wrote: > > On Thu, Aug 30, 2007 at 07:43:56PM +0400, Alexey Tourbin wrote: > > > On Thu, Aug 30, 2007 at 04:07:20PM +0400, Alexey Tourbin wrote: > > [...] > > > > Допустим, я опубликовал perl2.git в котором нет наследования > > > > от perl.git. Публичного репозитария perl2.git ещё нету, поэтому > > > > проверка наследования "для нового пакета" отключается, а собранные > > > > пакеты perl-* просто пройдут в сизиф? > > > > > > Вот решение проблемы: требовать, чтобы имя gear-репозитария в точности > > > совпадало с именем src.rpm пакета, который получился при сборке. > > > > Я предлагал к реализации немного более слабый вариант этой проверки: > > Либо имя gear-репозитория в точности совпадает с именем spm-пакета, > > либо отправляющий тэг на сборку явно указывает имя будущего spm-пакета. > > Как будет называться публичный gear-репозитарий, в котором будет > опубликовано сборочное дерево? Единственный правильный вариант -- > это по названию src.rpm пакета. По имени srpm-пакета. > > По окончании сборки имя spm-пакета сравнивается с заявленным, и в случае > > несовпадения результат сборки отвергается. > > Тогда я не вижу, почему maintainer хочет публиковать свой приватный > репозитарий под другим именем. Допустим кто-то публикует питон по > адресу perl.git. Какой в этом смысл? Названия публичного и приватного > репозитариев отличается, find-package не работает. У меня есть несколько репозиториев, из которых я собираю пакеты с разными именами, напр. readline*, openssl* и т.п. Т.е. причина простая: из одного репозитория собирается несколько разных родственных пакетов. > > > Тут получается вот какая особенность: проверить наследование коммитов > > > можно ТОЛЬКО ПОСЛЕ ТОГО, КАК ПАКЕТ УЖЕ СОБРАЛСЯ (причем, на всех > > > основных архитектурах). Это противоречит нашему интуитивному > > > представлению о том, что наследование коммитов нужно проверять > > > до того, как собирать пакет. > > > > Не вижу, что может помешать проверить git-merge-base до сборки, > > если имя spm-пакета известно. А оно известно до сборки по определению > > (либо совпадает с именем gear-репозитория, либо указано явно). > > А зачем его проверять до сборки? Если что-то можно проверить ещё до сборки, то почему бы этого не сделать? Поскольку проверка git-merge-base дешевле сборки, в этом есть смысл: экономия ресурсов. -- ldv