From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: ALT Linux Team development discussions , "Vladimir D. Seleznev" References: <20171030152721.22d4179f@boyarsh.office.basealt.ru> <2e01a216-8e80-5450-76a1-2c4a22177a6e@basealt.ru> <03696139-ae55-a338-6f1a-b2b5e26eeed8@basealt.ru> <20171030173915.11e573e6@boyarsh.office.basealt.ru> <7d8c3600-686c-3a29-b17a-e35bfe91aa0f@basealt.ru> <20171030183007.78cdc4ae@sem.office.basealt.ru> <9895d5b1-2685-a3a5-a0d2-6a83242cc230@basealt.ru> <20171030203556.GC2520@altlinux.org> <20171030210450.GC18841@portlab> <20171031105339.GC902@portlab> From: Anton Farygin Organization: BaseALT Message-ID: <79ce306a-219c-2e53-810e-bb91b0bb50fc@basealt.ru> Date: Tue, 31 Oct 2017 14:01:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171031105339.GC902@portlab> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [devel] rpm-macros-ubt 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: Tue, 31 Oct 2017 11:01:41 -0000 Archived-At: List-Archive: List-Post: 31.10.2017 13:53, Vladimir D. Seleznev пишет: > On Tue, Oct 31, 2017 at 07:46:51AM +0300, Anton Farygin wrote: >> 31.10.2017 00:04, Vladimir D. Seleznev пишет: >>> On Mon, Oct 30, 2017 at 11:35:56PM +0300, Dmitry V. Levin wrote: >>>> On Mon, Oct 30, 2017 at 09:16:55PM +0300, Anton Farygin wrote: >>>>> 30.10.2017 18:30, Mikhail Efremov пишет: >>>>>> On Mon, 30 Oct 2017 18:13:11 +0300 Anton Farygin wrote: >>>>>>> 30.10.2017 17:39, Anton V. Boyarshinov пишет: >>>>>>>> On Mon, 30 Oct 2017 15:34:20 +0300 Anton Farygin wrote: >>>>>>>> >>>>>>>>> С FTP я конечно махнул. Имелось в виду то, что в разных бранчах будут >>>>>>>>> лежать сильно отличающиеся пакеты, которые при этом будут иметь >>>>>>>>> одинаковое имя файла. >>>>>>>> И что в этом такого уж плохого? Вообще, это открывает немало >>>>>>>> возможностей, сейчас закрытых. >>>>>>> А ты сможешь определить по скачанному файлу, для какого бранча он >>>>>>> предназачен ? >>>>>>> >>>>>>> Без Linux/RPM ? >>>>>> А что, сейчас это возможно? Откуда взялся пакет с релизом alt1? >>>>>> >>>>> С релизом alt1 - нет, невозможно. Но во всех репозиториях может быть >>>>> только один идентичный (одинаковый) файл с таким релизом. >>>>> >>>>> а вот с релизом alt0.M80P.1 - да, возможно даже визуально определить. >>>> Возможность по имени файла визуально определить, в какой бранч он был >>>> собран, не кажется мне столь важной, особенно в перспективе, когда будет >>>> много разных бранчей с более длинными именами и различными сроками жизни. >>> С другой стороны, ничего не мешает к релизу собранного бинарного пакета >>> добавлять appendix в виде .${!сизиф?имя_бранча}[.rb${номер_пересборки}], >>> особенно если ченджлог будет дописываться. Тогда каждая новая сборка >>> бинарного пакета в каждый бранч будет иметь уникальное имя, например, >>> package-1.0.0-alt1.p9.rb2.x86_64.rpm. >> И чем это будет отличаться от %ubt ? > %ubt находится в исходном пакете, и при сборке бинарных пакетов с %ubt > меняется не только суффик бранча, что принципиально. А в текущем > предложении исходный пакет не изменяется, и никакая информация из него > при сборке бинарных пакетов не искажается. Однако, основная мысль у меня > была не сколько про указание бранча, сколько про итераций пересборки > данного пакета для данного бранча, с добавлением в бинарный пакет всех > ченджлогов с датами пересборки (и, если предусмотреть механизм, причиной > пересборки). К сожалению, при сборке следующего релиза вся эта история > потеряется... Я ничего из этого не понял. Да, меняется %release, соответственным образом меняется changelog. Но - текущий формат changelog это всего-лишь устоявшееся правило, зафиксированное скриптами проверки. Если эти скрипты будут каким-то образом не считать за ошибку не полное совпадение release в записи версии changelog, то естественно %ubt из changelog можно легко будет убрать. > Но, опять-таки, было бы лучше, если бы по факту пересборки изменения > вносились с исходный пакет, но я пока не представляю как это можно было > бы аккуратно сделать. Исходный пакет - это атавизм.