From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Anton Farygin Organization: ALT Linux Ltd. Date: Wed, 01 Feb 2006 10:56:34 +0300 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: References: <43D5181C.7050405@altlinux.ru> <43D51B68.2030201@altlinux.ru> <43D602D8.3040207@altlinux.ru> <20060124104141.GZ11208@osdn.org.ua> <43D60B4E.6080909@altlinux.ru> <20060124115713.GC20273@mithraen.dimline.ru> <43D8E0CD.7040800@vzljot.ru> <43D9025B.5080306@altlinux.ru> <43D9041B.80203@altlinux.ru> <43D9CEEE.4040600@altlinux.ru> <43D9D90E.3020802@altlinux.ru> <43DA3548.603@epam.com> <43DFA433.90208@epam.com> To: devel@altlinux.ru MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: Subject: [devel] Re: Re: Re: Re: apache2 X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.5 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: Wed, 01 Feb 2006 08:02:24 -0000 Archived-At: List-Archive: List-Post: On Tue, 31 Jan 2006 19:53:55 +0200, Sviataslau Svirydau wrote: > Anton Farygin wrote on 1/31/2006 5:04 PM: >>> ... На svn://malta надо >>> именно так укладывать все, как для >>> остальных пакетов сделано? >>> >>> >> Угу.. но готов рассмотреть другую >> структуру в качестве дефолтной, если >> оно будет интересно ;-) >> > На отдельную заявку не претендую :) В > принципе, в рамках существующей > струкуты можно добиться того, чего мне > надо без особых ухищрений... > > Я лучше расскажу как это организовано у > меня: > > 1. Я не использую возможности svn-build-common, > поэтому по старинке собираю пакеты из > ~/RPM. Хотя имеется несколько маленьких > ньюансов. === На файловой системе === 2. > исходники/патчи лежат в ~/RPM/SOURCES/%name-%version > 3. спек лежит вместе с исходниками в > ~/RPM/SOURCES/%name-%version (соответственно, если в > существующей струкутру я сделаю ссылку > SPECS->SOURCES, то получится то, что мне надо, и > вроде бы ничего другого не сломает) Пункт 3 стоит того, что бы его применить, ибо зачастую действительно так удобнее. > 4. src.rpm укладываются в ~/RPM/SRPMS/%name ==== > соответствующие строчки из ~/.rpmmacros ==== > %_srcrpmdir %{_topdir}/SRPMS/%name %_sourcedir > %{_topsrcdir}/SOURCES/%name-%version %_specdir > %{_topsrcdir}/SOURCES/%name-%version === в svn === Это понятно. Но в случае с SVN мне не очень удобно, наверное. > 5. для всех пакетов я использую один > svn-repository, на верхнем уровне фолдер для > каждого пакета, внутрях у каждого пакета > свои trunk/tags/branches 6. мелкие тарболы > закидываю в репозиторий, крупные - нет. В > любом случае в репозиторий попадает > %name-%version.tar.(gz|bz2).asc от апстрима (если > таковой имеется) с asc - согласен. С тарболлами надо всё ещё думать. Есть вариант указывать URL на upstream и вытягивать его оттуда (с проверкой MD5SUM), но тут есть проблема - не все тарболлы реально лежат у mainstream. По поводу branhces/tags/trunk: я предпочитаю делать: branches/3.0/ branches/3.1/ trunk branches/experimental (Daedalus). Ибо это облегчает жизнь при сборке пакетов для различных веток репозитария, и в дальнейшем станет легче жить при автоматизации процесса сборки. > > Итого, чего бы я мог предложить: > > 1. В качестве энхансмента могу > предложить передвинуть спек к > исходникам. (смысла держать отдельный > каталог для одного спека нет, удобнее, > когда все под рукой. Но поскольку есть > workaround, то это не критично) Это принято. Сейчас передвину. 2. Хотелось бы > зафиксировать правила, по которым > внутри svn://malta следует создавать > теги/бранчи (собсно расположение + naming > conventions). Полезно, например, ставить теги > на состояния, залитые в /i/S/. У меня для > этой цели из спека вытаскивается > "%{VERSION}-%{RELEASE}" и используется для имени > тега. Да, здесь тоже правильно, ибо поставив тэг - можно запустить пакет фактически на сборку в hasher'е. (через хуки послать письмо роботу, который заберёт из SVN пакет и выложит его в incoming). Тогда выливается такая структура: branches/3.0/<имя пакета>/trunk/ branches/3.0/<имя пакета>/tags/<версия>-<релиз>/ trunk/<имя пакета>/trunk/ trunk/<имя пакета>/tags/<версия>-<релиз>/ первые два - для updates и фиксирования состояния branch'а вторые два - для current Sisyphus. 3. в svn-build-tools используется имя > директирии для определения имени > пакета. Это наложит определенные > (неудобные, имхо) требования на создание > бранчей. Если ввести требование на > наличие только одного спекфайла в > каталоге с исходниками, то имя пакета > можно определять прямо из этого > спекфайла (при наличи Name в спеке раньше > определения дополнительных %package, имя > пакета выдается первым в rpm -q --qf '%{NAME}\n' > --specfile my.spec, с другими вариантами не > экспериментировал). А вот здесь может быть засада - в ряде случаев --specfile может не сработать, если его выполнять в недостаточно полном сборочном окружении. При чём сборочное окружение можно получить только выполнив rpm -qR --specfile :-( Поэтому над svn-build-common лучше всего ещё помедетировать... хотя, отрезав trunk и tags от пути - получим фактически имя пакета. И из него - имя SPEC файла. Так подойдёт ? Rgds, Rider