[devel] Re: Re: Re: Re: apache2

[Anton Farygin]

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