From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <43FA4E0F.8050904@altlinux.org> Date: Tue, 21 Feb 2006 02:17:35 +0300 From: Alexey Rusakov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050815 Thunderbird/1.0.6 Mnenhy/0.7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Q: =?UTF-8?B?0L/RgNC+0YbQtdGB0YEg0YDQsNCx0L7RgtGLINC9?= =?UTF-8?B?0LDQtCDQv9Cw0LrQtdGC0LDQvNC4?= References: <20060220122949.GA5244@nomad.office.altlinux.org> In-Reply-To: <20060220122949.GA5244@nomad.office.altlinux.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.6 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2006 23:17:36 -0000 Archived-At: List-Archive: List-Post: Dmitry V. Levin wrote: >Мне показалось, что устройство нашего репозитория несколько устарело >и не вполне удовлетворяет нашим девелоперским потребностям. > >Чтобы улучшенный репозитарий действительно стал эффективнее, мне нужно >понять, как построить процесс работы с ним таким образом, чтобы учесть >workflow большинства разработчиков. > >Поэтому я прошу вас рассказать, как выглядит ваш процесс работы над >пакетами. > > Средства и ресурсы: Sisyphus или его подходящее зеркало где-нибудь в инете; hasher с патчем из Bug #8121 (слегка обновлённым); etersoft-build-utils для упрощения жизни; пара самодельных скриптов; vim и сколько получится pty'ев. Порядок работы: практически все спеки я держу в своём SPECS, из-за чего риск потери изменений при NMU (особенно о которых меня не известили личным письмом) весьма велик. Если же всё-таки требуется объединить изменения или я просто собираю чужой пакет (для NMU или будущий свой), то 1. (если нужно) apt-get source <имя> 2. (если нужно) Объединяются версии спека. 3. Увеличивается номер версии. 4. (если сменилась версия апстрима) rpmgs <имя>.spec (это из etersoft-build-utils, выкачивает тарболл с исходниками по %Url и добавляет "рыбу" в %changelog) 5. (опционально) Из тарболла берётся configure.in, просматривается на предмет очевидных зависимостей (напр., AC_CHECK_LIB и PKG_CHECK_MODULE). 6. (если нужно/хочется) В SOURCES кладутся/докладываются патчи. 7. Редактируется спек, вносятся все желаемые изменения, заполняется %changelog. 8. rpm -bs --sign --nodeps <имя>.spec 9. H <имя-версия>.src.rpm (H - скрипт, суть которого сводится к вызову hsh с нужными параметрами и выводу на экран наиболее интересных строк из лога сборки; кроме этого, линки на успешно собранные пакеты сбрасываются в специальный каталог good; всё не соберусь в него же засунуть пункт 7) 10. При необходимости (=вообще не собралось или собралось, но с подозрительными сообщениями) - investigation, по результатам которого возможен возврат к пункту 7. 11. sudo rpm -Uvh и первичное тестирование собранных rpm'ов (с возможным возвратом к пункту 6) 12. rsync -vP <имя-версия>.src.rpm (завёрнутый в скрипт, который берёт все пакеты из каталога good и синхронизирует их с /i/S, после чего удаляет) На данный момент больше всего напрягают две вещи: неполная автоматизация рутинных операций со спеком (в частности, сменил версию-rpmgs-упаковал .src.rpm-отправил собирать в hasher) и невозможность работать с hasher как с build factory (в которую можно асинхронно со сборкой бросать пакеты, она их соберёт в порядке поступления и пришлёт по почте извещение о результатах сборки). Поскольку мой hsh работает напрямую с оригинальным Sisyphus (т.е. через сеть), сборка пакетов с большим количеством зависимостей может затянуться. Впрочем, тот же glib2 собирается ужасно долго безо всяких зависимостей. Касаемо второго - думаю написать что-нибудь вроде hshd - демоническую обёртку для hsh. Пока на то, чтобы сесть и написать, времени не хватает. -- Alexey "Ktirf" Rusakov