From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <53A2D326.7080801@altlinux.com> Date: Thu, 19 Jun 2014 16:10:14 +0400 From: Anton Farygin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: devel@lists.altlinux.org References: <20140617194200.GA27630@dad.imath.kiev.ua> <20140619075237.GA9295@dad.imath.kiev.ua> <20140619110814.GA10173@dad.imath.kiev.ua> <53A2C53F.7080504@altlinux.com> <20140619115541.GA10395@dad.imath.kiev.ua> In-Reply-To: <20140619115541.GA10395@dad.imath.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?R2VhciDQuCDQstC90LXRiNC90LjQtSAgICBWQ1Mu?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 12:10:20 -0000 Archived-At: List-Archive: List-Post: On 19.06.2014 15:55, Igor Vlasenko wrote: > On Thu, Jun 19, 2014 at 03:10:55PM +0400, Anton Farygin wrote: >> On 19.06.2014 15:08, Igor Vlasenko wrote: >>> Соответственно, когда такие утилиты будут готовы, >>> надо будет просить всех майнтайнеров, использующих >>> VCS - обновляемые gear репозитории, создать и опубликовать >>> в этих репозиториях .gear/upstream/remotes, >>> а если есть желание ограничить доступ к своему репозиторию, >>> то делать это с помощью acl, а не сокрытием его служебной >>> информации. >> >> я в соседнем письме написал, почему нет смысла использовать для >> этого .gear/upstream/remotes >> т.е. - я не хотел бы использовать инструмент, который будет мне >> предоставлять алгоритм работы другого ментейнра. >> например, мне привычнее upstream remote держать в бранче не >> upstream, а source. >> >> Как тут быть ? > > Легко :) > > 2 файла .gear/upstream/tag-filter и > .gear/upstream/remotes - это формат, > в котором будет храниться служебная информация, > которая будет необходима для watch по tag. > > При этом .gear/upstream/remotes имеет более > глубокий смысл - > > * он позволяет сделать информацию о remotes публичной, > * может использоваться независимо от того, нужен ли watch по tag, > * крайне нужен NMUшникам. > > Но из этого совершенно не следует, что если пакет foo > одновременно сопровождает 2 майнтайнера A и B, то > если один из них создал .gear/upstream/remotes, > (например, А), то второй (В) > отгребет из этого файла не нужные ему ветви. следует что каждому мейнтейнеру для каждого своего пакета придётся делать действия, которых можно было бы избежать. > > Ведь никто не заставляет выполнять у себя > gear-restore-remotes, и робот тоже не будет этого > делать. Я в позапрошлом письме рассматривал алгоритм > обновления. Если в gear/rules тег, как в > tar:v@version@: . > то там достаточно использовать временную служебную ветвь, > какой-нибудь gearobersturmbannbranch. > Однако, служебная ветвь -- это мусор в репозитории, > поэтому умный робот проверит, есть ли в .git/config > ветви, описанные в .gear/upstream/remotes, > если есть, будет использовать их, чтобы не мусорить, > если же нет, создаст свой gearobersturmbannbranch. Умный робот мог бы посмотреть, если ли remotes на апстрим, описанный в watch файле и если есть - сделать fetch им, а не в отдельную служебную ветку. > > Если майнтайнер B тоже не хочет, чтобы у него создавался > gearobersturmbannbranch, а использовались его собственные, > отличные от майнтайнера A названия ветвей, > он может добавить файл .gear/upstream/remotes.$USER, > который будет иметь приоритет перед .gear/upstream/remotes. > А еще можно export GEAR_UPSTREAM_REMOTES_SUFFIX=..smth.., > и перекрыть все с помощью > .gear/upstream/remotes.$GEAR_UPSTREAM_REMOTES_SUFFIX > если вдруг понадобится. а что делать, если мейнтейнер не хочет записывать что-то в .gear/upstream (и тем более публиковать это) ? > > Конечно, в gear/rules архив может создаваться не по тегу, > а по ветви: tar:upstream: . > но тогда от создания у себя ветви upstream никуда не деться, > против лома нет приема, она железобетонно прописана в gear/rules, > разве что форкать свои .gear/rules. > > Так хорошо? Нет, плохо. Мне хотелось бы понять, чем не устраивает вариант с созданием веток под "настройки мейнтейнера" а не в соответствии с .gear/upstream/remotes ? Зачем плодить лишние сущности ? сделайте в домашнем каталоге .uupdate-branches и в нём пропишите все необходимые ветки. ну и дефолт в виде upstream upstream