From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4C614819.20200@altlinux.com> Date: Tue, 10 Aug 2010 16:37:45 +0400 From: Anton Farygin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: devel@lists.altlinux.org References: <4C5338C5.9090905@tut.by> <20100731101221.GF6086@wrars-comp.wrarsdomain> <4C53F82C.6060103@gmail.com> <20100731102638.GG6086@wrars-comp.wrarsdomain> <4C57B519.6050700@altlinux.com> <20100803115442.GB12310@mw.office.seiros.ru> <4C58497F.9040109@altlinux.com> <4C58629B.6020806@altlinux.com> <20100804060013.GA30446@mw.office.seiros.ru> <4C590698.1080109@altlinux.ru> <4C6120BD.2030309@tangramltd.com> <4C612AFD.9070100@altlinux.com> <4C6143F9.9050704@tangramltd.com> In-Reply-To: <4C6143F9.9050704@tangramltd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0KPQvNC+0LvRh9Cw0L3QuNGPIFBIUCBbd2FzOiAgUEhQ?= =?utf-8?b?IDUuMy4zXQ==?= 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, 10 Aug 2010 12:37:23 -0000 Archived-At: List-Archive: List-Post: 10.08.2010 16:20, Slava Dubrovskiy пишет: > 10.08.2010 13:33, Anton Farygin пишет: >> 10.08.2010 13:49, Slava Dubrovskiy пишет: >>> 04.08.2010 09:20, Alexey Gladkov пишет: >>>> On 04.08.2010 10:00, Денис Смирнов wrote: >>>> >>>>> Интересно, кто-нибудь может сойти с ума настолько, чтобы сделать у нас >>>>> поддержку нескольких веток PHP? ;) >>>>> >>>> Оно так было очень давно. >>>> >>> А расскажите пожалуйста, почему сборка php сделана именно так? >>> 1. Т. е. почему каждый sapi и ext собирается из своего srpm? >>> Например в дебиане и сборке от remi все собирается одномоментно. Это >>> позволяет избежать проблем, когда какое-то расширение не пересобрали с >>> новой версией (речь идет про те что поставляются с самим php, а не >>> сторонними). Также это упрощает поддержку пакета, бэкпорт. Не нужно >>> делать патч и выделять libphp и т.д. >> >> у нас так устроена система сборки, что не пересобрать какое-то >> расширение с новой версией PHP просто невозможно. >> > Ок. Раньше такое было. >> >> Сборка каждого sapi и ext в отельном пакете _значительно_ упрощает >> сопровождение PHP, особенно когда ext мейнтенит не один человек, а >> несколько разных. > Ой не могу согласиться. Например прикладывать патчи которые должны быть > в обоих srpm более трудоемко. Как показывает практика, бэкпортированием > мантейнер не занимается. И это приходится делать менее опытному > заинтересованному члену тиим. И такое количество пакетов и сама система > сборки отбивает всякое желание. > Про нескольких мантейнеров одного ext тоже не убедительно. Тут сам php > пол-года был без мантейнера. А вы говорите про целых двух или больше. Это реальность. > >> >>> >>> 2. Зачем конфиги располагаются в версийзависимых директориях? >>> Обновление php это просто ад. Приходится вручную проверять все изменения >>> и вносить их заново. >>> >> В этом утверждении есть ответ на вопрос номер 2. > Да, не правильно спросил. > Но проблема остается. При каждом обновлении конфиги приходится проверять > и править вручную. pre и post скрипты не работают. А в этих скриптах и нет ничего такого, что бы могло помочь. У меня есть мысль, которую я уже давно думаю.. отказаться от идеи ведения нескольких версий PHP в репозитории, ибо оно в принципе не так что бы очень актуально. При этом можно попробовать сделать один конфиг для PHP, без привязки к версиям, который не будет обновляться при установке новой версии.