From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Wed, 19 Jan 2022 14:10:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: ru To: devel@lists.altlinux.org References: <8f291e9f-337b-6882-5287-2825be0253ec@rosalinux.ru> <20211223090747.928b5667b416a58c2c55eeb6@altlinux.org> <20220111110125.4d6b1e4b@tower> <20220111151821.1402ea19@tower> <20220119125652.5e8f37a2@tower> <7a45f245-f92c-c5ea-21e9-b4afbe57b9d9@basealt.ru> From: Anton Farygin Organization: BaseALT In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0JDQstGC0L7QtNC10LrQu9Cw0YDQsNGG0LjRjyDQv9Cw?= =?utf-8?b?0YLRh9C10Lkg0LIg0YHQv9C10LrQsNGFIChXYXM6INCd0L7QstCw0Y8g0YE=?= =?utf-8?b?0YXQtdC80LAg0LLQtdC00LXQvdC40Y8g0LjRgdGF0L7QtNC90LjQutC+0LIg?= =?utf-8?b?0Y/QtNGA0LAp?= 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: Wed, 19 Jan 2022 11:10:19 -0000 Archived-At: List-Archive: List-Post: On 19.01.2022 13:48, Vladimir D. Seleznev wrote: > On Wed, Jan 19, 2022 at 01:32:50PM +0300, Anton Farygin wrote: >> On 19.01.2022 13:31, Vladimir D. Seleznev wrote: >>> On Wed, Jan 19, 2022 at 12:56:52PM +0300, Anton V. Boyarshinov wrote: >>>>>> С одной стороны, такая схема ощутимо более трудоёмка при сборке новой мажорной версии, но можно попробовать многое заскриптовать. >>>>>> С другой стороны, есть и определённые удобства в плане поддержки ядер в разных репозиториях. >>>>>> С третьей стороны, когда stable разъезжается с патчами, в старой схеме это видно на этапе мержа, а в новой -- на этапе сборки. Впрочем, тут есть и недостатки и достоинства. >>>>>> >>>>>> В общем, надо посмотреть. >>>>> Я напоминаю, что начиная с rpm-build-4.0.4-alt133 поддерживается >>>>> директива %autopatch. Её использование удобно тем, что нет необходимости >>>>> следить за соответствием декларации патча (PatchN: fix.patch) и наличием >>>>> его применением (%patchN -p1). Я думаю, она хорошо подходит к данной >>>>> схеме в т.ч.. >>>>> >>>> Вот хорошо бы было, если бы она не только следила за соответствием >>>> декларации патча и его наложением, но могла бы также замечать, что >>>> патчи в виде файлов есть, а ни декларации, ни наложения нет. >>> Может быть сделать соответствующую поддержку в gear? >>> >>> Например, можно реализовать директиву gear-rules declare-patches: yes, >>> при наличие которой при сборке пакета патчи последовательно, в порядке >>> следования diff'ов в gear-rules, подставляются в spec-файл (в таком >>> случае spec в gear является не чистым, а шаблоном для настоящего спека). >>> >> вот только у нас ещё остался архитектурно-независимый src.rpm. > Для них это не будет работать, а при сборке из gear в спеках сгенерённых > sourcerpms будут указаны все патчи. > А как это поможет сделать %ifarch для патчей ?