[devel] Q: процесс работы над пакетами

[devel] Q: процесс работы над пакетами

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Hi,

Мне показалось, что устройство нашего репозитория несколько устарело
и не вполне удовлетворяет нашим девелоперским потребностям.

Чтобы улучшенный репозитарий действительно стал эффективнее, мне нужно
понять, как построить процесс работы с ним таким образом, чтобы учесть
workflow большинства разработчиков.

Поэтому я прошу вас рассказать, как выглядит ваш процесс работы над
пакетами.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

* Dmitry V. Levin <ldv@> [060220 15:31]:
> Поэтому я прошу вас рассказать, как выглядит ваш процесс работы над
> пакетами.
Настроены пакеты sandman и sisyphus.  Рабочий каталог пакета
выглядит как:

%name/
 \- files/
 |   \- %name-%version.tar.bz2
 \- work/
 |   \- %name-%version/
 \- %name.spec

После того как новая сборка готова, исходники запихиваются в
sandman, спек коммитится в нужное место и запускается скрипт
который: собирает пакет(ы) в sandman, вытаскивает результаты,
подписывает, копирует src.rpm'ы в "outbox" и отдаёт всё
свежесобранное sisyphus'у, который обновляет мой локальный
"сизифчик".

Во всём это мне неудобны полторы вещи - необходимость разбираться
какие исходники нужно обновить в sandman и копировать spec в в
рабочую копию samndman'ского модуля.  Ещё нужно руками обновлять
list.* от sisyphus (но это уже из другой оперы).

Ну и естественно, что все NMU над моими пакетами просто молча
скипаются, если мне об этом не сообщают, потому как я не смотрю в
сизиф перед сборкой пакета, да и сам процесс сборки может
затянуться.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Alexey Rusakov]

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

Re: [devel] Q: процесс работы над пакетами

[Vitaly Lipatov]

On Monday 20 February 2006 15:29, Dmitry V. Levin wrote:
> Hi,
>
> Мне показалось, что устройство нашего репозитория несколько
> устарело и не вполне удовлетворяет нашим девелоперским
> потребностям.
>
> Чтобы улучшенный репозитарий действительно стал эффективнее,
> мне нужно понять, как построить процесс работы с ним таким
> образом, чтобы учесть workflow большинства разработчиков.
>
> Поэтому я прошу вас рассказать, как выглядит ваш процесс
> работы над пакетами.
У меня процесс проходит по возможности в выполнении скриптов из 
etersoft-build-utils.
Собственно, основные приёмы использования описаны на
http://www.freesource.info/wiki/AltLinux/Razrabotchiku/SborkaPaketov

Если совсем кратко, то я использую
rpmrb спек новая_версия
чтобы без вопросов собрать и отправить новую версию программы

rpmbsh -i -u спек
чтобы собрать пакет, установить его в тестовый hasher и далее 
отправить в инкоминг

rpmgp пакет
чтобы получить src.rpm на пакет из Сизифа и уставить его (rpm -i)

rpmbph -M24 -u спек
чтобы адаптировать спек к Master 2.4, собрать в hasher с Master 
2.4 и отправить в Инкоминг.

Никаких систем контроля версий не использую, потому как не считаю 
нужным и возможным возвращаться обратно когда-либо. К тому же 
всегда есть пакет в Сизифе.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Q: процесс работы над пакетами

[Vitaly Lipatov]

On Tuesday 21 February 2006 02:17, Alexey Rusakov wrote:
> 8. rpm -bs --sign --nodeps <имя>.spec
rpmbs -s 
> 9. H <имя-версия>.src.rpm (H - скрипт, суть которого сводится
> к вызову hsh с нужными параметрами и выводу на экран наиболее
> интересных строк из лога сборки; кроме этого, линки на успешно
> собранные пакеты сбрасываются в специальный каталог good; всё
rpmbsh -u

> не соберусь в него же засунуть пункт 7) 10. При необходимости
> (=вообще не собралось или собралось, но с подозрительными
> сообщениями) - investigation, по результатам которого возможен
> возврат к пункту 7.
> 11. sudo rpm -Uvh и первичное тестирование собранных rpm'ов (с
> возможным возвратом к пункту 6)
rpmbsh -i -u
> 12. rsync -vP <имя-версия>.src.rpm (завёрнутый в скрипт,
> который берёт все пакеты из каталога good и синхронизирует их
> с /i/S, после чего удаляет)
rpmbs -u

> На данный момент больше всего напрягают две вещи:
> неполная автоматизация рутинных операций со спеком (в
> частности, сменил версию-rpmgs-упаковал .src.rpm-отправил
> собирать в hasher) и невозможность работать с hasher как с
rpmrb спек новая_версия

> build factory (в которую можно асинхронно со сборкой бросать
> пакеты, она их соберёт в порядке поступления и пришлёт по
Минимально -
rpmbsh ждёт когда освободится hasher
> почте извещение о результатах сборки). Поскольку мой hsh
Возможность с почтой я начал, но забросил за невостребованностью.
...

P.S.
Кстати, сегодня вышла etersoft-build-utils 1.0
:)

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Q: процесс работы над пакетами

[Alexey Rusakov]

Vitaly Lipatov wrote:

>On Tuesday 21 February 2006 02:17, Alexey Rusakov wrote:
>  
>
>>8. rpm -bs --sign --nodeps <имя>.spec
>>    
>>
>rpmbs -s 
>  
>
У меня при попытке его использовать в своё время возникли какие-то 
странные проблемы, а разбираться было лень. Остался на бабушкиных приёмах.

>>На данный момент больше всего напрягают две вещи:
>>неполная автоматизация рутинных операций со спеком (в
>>частности, сменил версию-rpmgs-упаковал .src.rpm-отправил
>>собирать в hasher) и невозможность работать с hasher как с
>>    
>>
>rpmrb спек новая_версия
>  
>
Во многих моих спеках версия конструируется из major и minor (по схеме 
%ver_major.n). В принципе, rpmrb допиливается до моих нужд, может даже в 
исходный код лезть не понадобится.

>>build factory (в которую можно асинхронно со сборкой бросать
>>пакеты, она их соберёт в порядке поступления и пришлёт по
>>    
>>
>Минимально -
>rpmbsh ждёт когда освободится hasher
>  
>
А если два rpmbsh будут ждать, когда освободится hasher, будет гонка?
В общем, это не совсем то. В идеале хочется, чтобы можно было бросить 
пакет (или даже спек при известном каталоге с исходниками) в 
какую-нибудь дырку, и получить подборку линков (симлинков, url - зависит 
от организации софта) на пакет по окончании сборки. Да, и в идеале 
хочется, чтобы это масштабировалось на сетевую среду :)

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Q: процесс работы над пакетами

[php-coder]

--- Dmitry V. Levin 2006-02-20 15:29:49 +0300
+++ php-coder 2006-02-21 13:41:40 +0600

DVL> Поэтому я прошу вас рассказать, как выглядит ваш процесс работы над
DVL> пакетами.

    Я всё делаю сам и вручную. Никаких оптимизаций труда. Наверное, потому
    что пока у меня всего 10 пакетов, которые не так уж и часто
    обновляются и я за ними очень внимательно слежу :)

    Спеки в SVN хранятся. Все патчи и исходники в
    /mnt/other/distrib/packages/%name. Т.о. процес сборки пакета у меня
    примерно такой:

    $ cp ~dist/packages/%name/* RPM/SOURCES
    $ cp tmp/SPECS/%name.spec RPM/SPECS
    $ rpmbuild -bs RPM/SPECS/%name.spec
    $ hsh --apt-config=/build/apt.conf --excludedocs /build
      ~/RPM/SRPMS/%name-%version-%release.src.rpm
    $ sudo rpm -Uvh
      /build/repo/i686/RPMS.hasher/%name-%version-%release.i686.rpm

    Если всё окей, то:

    $ rpm --addsign RPM/SRPMS/%name-%version-%release.src.rpm
    $ rsync -va --partial --stats --delete-after -e ssh
    RPM/SRPMS/%name-%version-%release.src.rpm devel:/incoming/Sisyphus/


    P.S. А вообще конечно надо бы подумать над автоматизацией моей работы,
    благо пока Ctrl-r да Tab помогают вводить эти команды весьма быстро.

    P.P.S. Репозитарий для хашера подобран вручную, пакет за пакетом, и в
    нём у меня содержатся лишь пакеты необходимые для сборки моих пакетов.
    И ничего лишнего. Обновляю его тоже вручную и не так часто. Частично
    мне в этом помогает Makefile, указывающий на то какие пакеты
    обновились.

    buildreq тоже перестал использовать. Гы) Не доверяю его точности. В
    итоге почти все BuildRequires сделаны подобраны вручную (отправлял
    пакет в хашер, как только вылетал на ошибке, смотрел что за пакета не
    хвататет, добавлял его в зависимости и опять на пересборку ;)).

    Попытки использовать etersoft-build-utils тоже провалились. Во-первых,
    там все команды начинаются с rpm, что мне не очень понравилось,
    во-вторых, я опять же не не был в них уверен. Не я их писал и не знаю,
    что там происходит наверняка, в итоге так и делаю всё вручную. Пока не
    жалуюсь.


-- 
+ Semushin Slava | php-coder @ ngs.ru
+ ALT Linux Team | php-coder @ altlinux.ru

Re: [devel] Q: процесс работы над пакетами

[Vitaly Lipatov]

On Tuesday 21 February 2006 10:58, Alexey Rusakov wrote:
> >rpmbs -s
>
> У меня при попытке его использовать в своё время возникли
> какие-то странные проблемы, а разбираться было лень. Остался
> на бабушкиных приёмах.
Если что - пишите.

> Во многих моих спеках версия конструируется из major и minor
> (по схеме %ver_major.n). В принципе, rpmrb допиливается до
> моих нужд, может даже в исходный код лезть не понадобится.
Было бы интересно. rpmrb пока просто набросок

> >Минимально -
> >rpmbsh ждёт когда освободится hasher
>
> А если два rpmbsh будут ждать, когда освободится hasher, будет
> гонка? В общем, это не совсем то. В идеале хочется, чтобы
А есть разница кто первый пойдёт?

> можно было бросить пакет (или даже спек при известном каталоге
> с исходниками) в какую-нибудь дырку, и получить подборку
Да, такого нет.

> линков (симлинков, url - зависит от организации софта) на
> пакет по окончании сборки. Да, и в идеале хочется, чтобы это
> масштабировалось на сетевую среду :)
Может это уже sandman?

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Q: процесс работы над пакетами

[Alexey Rusakov]

php-coder wrote:
>     buildreq тоже перестал использовать. Гы) Не доверяю его точности. В
>     итоге почти все BuildRequires сделаны подобраны вручную (отправлял
>     пакет в хашер, как только вылетал на ошибке, смотрел что за пакета не
>     хвататет, добавлял его в зависимости и опять на пересборку ;)).
>   
Кстати да. Я buildreq'ом тоже не пользуюсь, в его нынешней реализации он 
меня не устраивает - очень много лишнего и кроме того, приходится 
собирать пакет не в hasher, что я делать не люблю (это ж пакеты -devel 
надо в систему ставить :).
2 at: buildreq2 когда-нибудь будет в Сизифе?

>     Попытки использовать etersoft-build-utils тоже провалились. Во-первых,
>     там все команды начинаются с rpm, что мне не очень понравилось,
>     во-вторых, я опять же не не был в них уверен.
Да, для меня тоже есть этот порог. Документации минимум, а использовать 
такие вещи полувслепую нетехнологично :) Тот же rpmgs я стал 
использовать только после того как в исходники заглянул пару раз (и это 
самый простой случай).

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Q: процесс работы над пакетами

[Денис Смирнов]

On Tue, Feb 21, 2006 at 11:48:32AM +0300, Vitaly Lipatov wrote:

VL> Может это уже sandman?

Скорее локальный incoming/

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

Re: [devel] Q: процесс работы над пакетами

[Aleksey Avdeev]

php-coder пишет:
> --- Dmitry V. Levin 2006-02-20 15:29:49 +0300
> +++ php-coder 2006-02-21 13:41:40 +0600
> 
> DVL> Поэтому я прошу вас рассказать, как выглядит ваш процесс работы над
> DVL> пакетами.
> 
>     Я всё делаю сам и вручную. Никаких оптимизаций труда. Наверное, потому
>     что пока у меня всего 10 пакетов, которые не так уж и часто
>     обновляются и я за ними очень внимательно слежу :)

  +1

  Автоматизацию только начал вводить (см. ниже).

> 
>     Спеки в SVN хранятся. Все патчи и исходники в
>     /mnt/other/distrib/packages/%name. Т.о. процес сборки пакета у меня

  У меня -- в SVN всё: весьма удобно, когда есть пакеты для сизифа и
бэкпортов.

  Бардак в ~/RPM начал мешать относительно недавно. Сейчас -- ввожу
автоматизацию, взяв за основу
<http://wiki.sisyphus.ru/devel/SubversionForSPECS>.

-- 

С уважением. Алексей.

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Mon, 20 Feb 2006 15:29:49 +0300, Dmitry V. Levin wrote:

> Hi,
> 
> Мне показалось, что устройство нашего
> репозитория несколько устарело и не
> вполне удовлетворяет нашим
> девелоперским потребностям.
> 
> Чтобы улучшенный репозитарий
> действительно стал эффективнее, мне
> нужно понять, как построить процесс
> работы с ним таким образом, чтобы учесть
> workflow большинства разработчиков.
> 
> Поэтому я прошу вас рассказать, как
> выглядит ваш процесс работы над
> пакетами.

Я пользуюсь SubversionForSPEC.

Если в ближайшем будущем ничего не
появится у нас централизованного, то
планирую расширять SubversionForSPECS до уровня
"выкладывания пакетов в OUT"

Т.е. - что бы оно ещё и собирало... 

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Alexey Rusakov]

Денис Смирнов wrote:
> On Tue, Feb 21, 2006 at 11:48:32AM +0300, Vitaly Lipatov wrote:
> 
> VL> Может это уже sandman?
> 
> Скорее локальный incoming/
Вот да, что-то вроде.

-- 
   Alexey "Ktirf" Rusakov

Re: [devel] Q: процесс работы над пакетами

[Michael Shigorin]

On Tue, Feb 21, 2006 at 01:04:13PM +0300, Alexey Rusakov wrote:
> 2 at: buildreq2 когда-нибудь будет в Сизифе?

Некоторые и так пользуются...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Q: процесс работы над пакетами

[Alexey Rusakov]

Michael Shigorin wrote:
> On Tue, Feb 21, 2006 at 01:04:13PM +0300, Alexey Rusakov wrote:
>> 2 at: buildreq2 когда-нибудь будет в Сизифе?
> 
> Некоторые и так пользуются...
Порядок нужон.

-- 
   Alexey "Ktirf" Rusakov

Re: [devel] Q: процесс работы над пакетами [JT]

[Vitaly Lipatov]

On Tuesday 21 February 2006 11:05, php-coder wrote:

>     Попытки использовать etersoft-build-utils тоже
> провалились. Во-первых, там все команды начинаются с rpm, что
> мне не очень понравилось, во-вторых, я опять же не не был в
Ну да, мы же не RPM-пакеты собираем ;)

> них уверен. Не я их писал и не знаю, что там происходит
Если не доверять программам, лучше не включать компьютер.

> наверняка, в итоге так и делаю всё вручную. Пока не жалуюсь.
Ой-да-пожалуйста :)

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Q: процесс работы над пакетами

[Vitaly Lipatov]

On Tuesday 21 February 2006 13:04, Alexey Rusakov wrote:
> Да, для меня тоже есть этот порог. Документации минимум, а
Ну может быть на
http://www.freesource.info/wiki/AltLinux/Razrabotchiku/SborkaPaketov?v=198u#h327-12
и мало написано...
> использовать такие вещи полувслепую нетехнологично :) Тот же
> rpmgs я стал использовать только после того как в исходники
> заглянул пару раз (и это самый простой случай).
Не думаю что было сложно спросить меня или попросить улучшить 
документацию. 
Я просто пока не понял, в каком виде она должна быть.
Если уж страницы на Вики, файлов README, QuickHelp.txt не 
хватает...
А также ключа -h у каждой команды...

Если кто-то составит перечень действий, я бы приписал к ним 
соотв. команды.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

Re: [devel] Q: процесс работы над пакетами

[Alexey Rusakov]

Vitaly Lipatov wrote:

>On Tuesday 21 February 2006 13:04, Alexey Rusakov wrote:
>  
>
>>Да, для меня тоже есть этот порог. Документации минимум, а
>>    
>>
>Ну может быть на
>http://www.freesource.info/wiki/AltLinux/Razrabotchiku/SborkaPaketov?v=198u#h327-12
>и мало написано...
>  
>
>>использовать такие вещи полувслепую нетехнологично :) Тот же
>>rpmgs я стал использовать только после того как в исходники
>>заглянул пару раз (и это самый простой случай).
>>    
>>
>Не думаю что было сложно спросить меня или попросить улучшить 
>документацию. 
>Я просто пока не понял, в каком виде она должна быть.
>Если уж страницы на Вики,
>
Страница на Вики - это хорошо, но далеко.

> файлов README,
>
Это самый полезный источник.

>QuickHelp.txt
>
Это просто сумма всех ключей -h, насколько я понял.

>не хватает...
>А также ключа -h у каждой команды...
>  
>
Кстати, попробуйте написать rpmrb -h . Там перед собственно помощью sed 
два раза ругается. Неаккуратненько (с) :)

>Если кто-то составит перечень действий, я бы приписал к ним 
>соотв. команды.
>  
>
Ну, я свой workflow описал... Только-чтошняя попытка ещё раз 
воспользоваться etersoft-build-utils en grand закончилась пониманием 
того, что под него не подходит очень многое. Ладно, я подумаю, как их 
допилить до своих нужд.

Что касается документации... Для меня беда в основном состоит в том, что 
даже зная действия, совершаемые скриптом, я не знаю, с какими 
параметрами эти действия совершаются. Например, для меня совсем не 
очевидно, что apt.conf берётся из /etc. Более того, у меня это просто не 
работает, потому что в системе я пользуюсь Дедалом, а Hasher у меня, 
естественно, работает из чистого Сизифа (между прочим, в Дедале лежит 
новая версия sisyphus_check, гораздо более могучая, я надеюсь).

-- 
  Alexey "Ktirf" Rusakov

Re: [devel] Q: процесс работы над пакетами

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

В Втр, 21/02/2006 в 15:28 +0300, Anton Farygin пишет:
> Я пользуюсь SubversionForSPEC.
> 
> Если в ближайшем будущем ничего не
> появится у нас централизованного, то
> планирую расширять SubversionForSPECS до уровня
> "выкладывания пакетов в OUT"
> 
> Т.е. - что бы оно ещё и собирало... 

Как будет решена проблема подгона больших архивов с исходниками?
Если просто пихать их версия за версией в svn, хранилище скоро лопнет.


[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Grigory Batalov]

On Wed, 22 Feb 2006 13:25:32 +0300
Mikhail Zabaluev <mhz@altlinux.org> wrote:

> > Я пользуюсь SubversionForSPEC.
> > 
> > Если в ближайшем будущем ничего не
> > появится у нас централизованного, то
> > планирую расширять SubversionForSPECS до уровня
> > "выкладывания пакетов в OUT"
> > 
> > Т.е. - что бы оно ещё и собирало... 
> 
> Как будет решена проблема подгона больших архивов с исходниками?
> Если просто пихать их версия за версией в svn, хранилище скоро лопнет.

  Можно приделать "сбоку" папку distfiles, как во FreeBSD =).

-- 
 Григорий Баталов,
 программист
 ЗАО "Ланит-Терком"

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Wed, 22 Feb 2006 13:25:32 +0300, Mikhail Zabaluev wrote:

> В Втр, 21/02/2006 в 15:28 +0300, Anton Farygin пишет:
>> Я пользуюсь SubversionForSPEC.
>> 
>> Если в ближайшем будущем ничего не
>> появится у нас централизованного, то
>> планирую расширять SubversionForSPECS до уровня
>> "выкладывания пакетов в OUT"
>> 
>> Т.е. - что бы оно ещё и собирало...
> 
> Как будет решена проблема подгона
> больших архивов с исходниками? Если
> просто пихать их версия за версией в svn,
> хранилище скоро лопнет.

Меня пока это не напрягает... а вообще
надо делать хранилище по стилю fedora.

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Wed, Feb 22, 2006 at 03:55:19PM +0300, Anton Farygin wrote:
> On Wed, 22 Feb 2006 13:25:32 +0300, Mikhail Zabaluev wrote:
> > В Втр, 21/02/2006 в 15:28 +0300, Anton Farygin пишет:
> >> Я пользуюсь SubversionForSPEC.
> >> 
> >> Если в ближайшем будущем ничего не
> >> появится у нас централизованного, то
> >> планирую расширять SubversionForSPECS до уровня
> >> "выкладывания пакетов в OUT"
> >> 
> >> Т.е. - что бы оно ещё и собирало...
> > 
> > Как будет решена проблема подгона
> > больших архивов с исходниками? Если
> > просто пихать их версия за версией в svn,
> > хранилище скоро лопнет.
> 
> Меня пока это не напрягает... а вообще
> надо делать хранилище по стилю fedora.

Нет, не надо, спасибо; очень неудобно, очень негибко, очень непрозрачно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Wed, 22 Feb 2006 16:41:44 +0300, Dmitry V. Levin wrote:

> Нет, не надо, спасибо; очень неудобно,
> очень негибко, очень непрозрачно.

А куда ещё можно положить большое количество бинарей ?

В идеале конечно хотелось бы счасться -
иметь такой бинарный репозитарий, что бы
между версиями тарболлов хранились дельты. 

Вопрос - как это правильно сделать ?

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Aleksey Avdeev]

Anton Farygin пишет:
> On Wed, 22 Feb 2006 16:41:44 +0300, Dmitry V. Levin wrote:
> 
> 
>>Нет, не надо, спасибо; очень неудобно,
>>очень негибко, очень непрозрачно.
> 
> 
> А куда ещё можно положить большое количество бинарей ?
> 
> В идеале конечно хотелось бы счасться -
> иметь такой бинарный репозитарий, что бы
> между версиями тарболлов хранились дельты. 

  Если не ошибаюсь -- subversion, для бинарей, так и поступает. Вопрос,
правда, на сколько это эффективно для сжатых тарболлов

> 
> Вопрос - как это правильно сделать ?

-- 

С уважением. Алексей.

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:

>   Если не ошибаюсь -- subversion, для бинарей,
>   так и поступает. Вопрос,
> правда, на сколько это эффективно для
> сжатых тарболлов

Помимо этого нужно понимать, что с точки
зрения subversion это два разных бинаря, а не обновление одного.

xdelta на такие тарболлы достаточно эффективна.

(я про <файл>-<версия>.tar.bz2)

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Anton Farygin wrote on 2/26/2006 1:06 PM:
> On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:
> 
>>   Если не ошибаюсь -- subversion, для бинарей,
>>   так и поступает. Вопрос,
>> правда, на сколько это эффективно для
>> сжатых тарболлов
> 
> Помимо этого нужно понимать, что с точки
> зрения subversion это два разных бинаря, а не обновление одного.

Как вариант: делать
svn mv <файл>-<версия>.tar.bz2 <файл>-<версия+1>.tar.bz2
перед добавлением новой версии :)
Если от этого действительно будет польза...

> xdelta на такие тарболлы достаточно эффективна.
> 
> (я про <файл>-<версия>.tar.bz2)


-- 
Best Regards,
Sviatoslav Sviridov


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

Anton Farygin пишет:
> On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:
> 
> 
>>  Если не ошибаюсь -- subversion, для бинарей,
>>  так и поступает. Вопрос,
>>правда, на сколько это эффективно для
>>сжатых тарболлов
> 
> Помимо этого нужно понимать, что с точки
> зрения subversion это два разных бинаря, а не обновление одного.

А можно отказаться от использования версии в именах тарболов? Их
вполне можно уместить svn-свойства файла.

Кстати, отказываться от версии в имени даже не обязательно -
можно использовать копирование старого архива в новый. Но это не
экономно.

> xdelta на такие тарболлы достаточно эффективна.
> 
> (я про <файл>-<версия>.tar.bz2)

Вроде как subversion учится использовать алгоритм xdelta:
http://svn.haxx.se/dev/archive-2005-02/0375.shtml

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Vitaly Ostanin wrote on 2/26/2006 1:25 PM:
> ...
>   
>> xdelta на такие тарболлы достаточно эффективна.
>>
>> (я про <файл>-<версия>.tar.bz2)
>>     
>
> Вроде как subversion учится использовать алгоритм xdelta:
> http://svn.haxx.se/dev/archive-2005-02/0375.shtml
>   
Дык научился уже :)
http://subversion.tigris.org/svn_1.2_releasenotes.html#xdelta

-- 
Best Regards,
Sviatoslav Sviridov


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Aleksey Avdeev]

Sviatoslav Sviridov пишет:
> Anton Farygin wrote on 2/26/2006 1:06 PM:
> 
>>On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:
>>
>>
>>>  Если не ошибаюсь -- subversion, для бинарей,
>>>  так и поступает. Вопрос,
>>>правда, на сколько это эффективно для
>>>сжатых тарболлов
>>
>>Помимо этого нужно понимать, что с точки
>>зрения subversion это два разных бинаря, а не обновление одного.
> 
> 
> Как вариант: делать
> svn mv <файл>-<версия>.tar.bz2 <файл>-<версия+1>.tar.bz2
> перед добавлением новой версии :)

  Это и имел ввиду.

  Правда, пользователей этому часть специально учить приходится... :-)

> Если от этого действительно будет польза...
> 
> 
>>xdelta на такие тарболлы достаточно эффективна.
>>
>>(я про <файл>-<версия>.tar.bz2)

-- 

С уважением. Алексей.

Re: [devel] Q: процесс работы над пакетами

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Sviatoslav Sviridov пишет:
> Vitaly Ostanin wrote on 2/26/2006 1:25 PM:
> 
>>...
>>  
>>
>>>xdelta на такие тарболлы достаточно эффективна.
>>>
>>>(я про <файл>-<версия>.tar.bz2)
>>>    
>>
>>Вроде как subversion учится использовать алгоритм xdelta:
>>http://svn.haxx.se/dev/archive-2005-02/0375.shtml
> 
> Дык научился уже :)
> http://subversion.tigris.org/svn_1.2_releasenotes.html#xdelta

Научился сервер. Как клиенту получить xdelta с сетевого репозитория?

Кстати, --diff-cmd учитывается на клиенте, или на сервере?

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

Vitaly Ostanin пишет:

<skipped/>

>>>Вроде как subversion учится использовать алгоритм xdelta:
>>>http://svn.haxx.se/dev/archive-2005-02/0375.shtml
>>
>>Дык научился уже :)
>>http://subversion.tigris.org/svn_1.2_releasenotes.html#xdelta
> 
> Научился сервер. Как клиенту получить xdelta с сетевого репозитория?

Точнее, как клиенту получить xdelta между произвольно заданными
версиями?

В несколько действий можно так - сохранить где-нибудь рабочую
копию, сделать update (в сетевом трафике качается только xdelta),
и потом руками xdelta между локальной старой и новой версиями.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Sun, 26 Feb 2006 13:20:12 +0200, Sviatoslav Sviridov wrote:

> Anton Farygin wrote on 2/26/2006 1:06 PM:
>> On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:
>> 
>>>   Если не ошибаюсь -- subversion, для бинарей,
>>>   так и поступает. Вопрос,
>>> правда, на сколько это эффективно для
>>> сжатых тарболлов
>> 
>> Помимо этого нужно понимать, что с
>> точки зрения subversion это два разных
>> бинаря, а не обновление одного.
> 
> Как вариант: делать
> svn mv <файл>-<версия>.tar.bz2
> <файл>-<версия+1>.tar.bz2 перед добавлением
> новой версии :) Если от этого
> действительно будет польза...

Я проверял.. что то не получается за одну
итерацию. Похоже что работает только в случае svn mv;svn commit;

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Aleksey Avdeev]

Anton Farygin пишет:
> On Sun, 26 Feb 2006 13:20:12 +0200, Sviatoslav Sviridov wrote:
> 
> 
>>Anton Farygin wrote on 2/26/2006 1:06 PM:
>>
>>>On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:
>>>
>>>
>>>>  Если не ошибаюсь -- subversion, для бинарей,
>>>>  так и поступает. Вопрос,
>>>>правда, на сколько это эффективно для
>>>>сжатых тарболлов
>>>
>>>Помимо этого нужно понимать, что с
>>>точки зрения subversion это два разных
>>>бинаря, а не обновление одного.
>>
>>Как вариант: делать
>>svn mv <файл>-<версия>.tar.bz2
>><файл>-<версия+1>.tar.bz2 перед добавлением
>>новой версии :) Если от этого
>>действительно будет польза...
> 
> 
> Я проверял.. что то не получается за одну
> итерацию. Похоже что работает только в случае svn mv;svn commit;

  Примерно: работает если файл с отсутствующий в репозитарии ранее
получен как svn cp существующего (svn cp -r ... -- частный случай).

PS: Для svn merge -- похоже что не работает.

-- 

С уважением. Алексей.

Re: [devel] Q: процесс работы над пакетами

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

Anton Farygin пишет:

<skipped/>

>>Как вариант: делать
>>svn mv <файл>-<версия>.tar.bz2
>><файл>-<версия+1>.tar.bz2 перед добавлением
>>новой версии :) Если от этого
>>действительно будет польза...
> 
> Я проверял.. что то не получается за одну
> итерацию. Похоже что работает только в случае svn mv;svn commit;

Попробуй
svn mv URL NEW_URL

svn help mv
намекает, что с PATH и URL перемещение работает по-разному.

И зачем в одну итерацию? В любом случае после интеграции с svn
нужно будет делать скриптовую обвязку.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Sviatoslav Sviridov]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

Vitaly Ostanin пишет:
> Vitaly Ostanin пишет:
>
> <skipped/>
>
>   
>>>> Вроде как subversion учится использовать алгоритм xdelta:
>>>> http://svn.haxx.se/dev/archive-2005-02/0375.shtml
>>>>         
>>> Дык научился уже :)
>>> http://subversion.tigris.org/svn_1.2_releasenotes.html#xdelta
>>>       
>> Научился сервер. Как клиенту получить xdelta с сетевого репозитория?
>>     
>
> Точнее, как клиенту получить xdelta между произвольно заданными
> версиями?
>
> В несколько действий можно так - сохранить где-нибудь рабочую
> копию, сделать update (в сетевом трафике качается только xdelta),
> и потом руками xdelta между локальной старой и новой версиями.
>
> <skipped/>
>   
Если сделать svn diff --force -r N1:N2 URL >some.patch, то на выходе
получается вроде бы как патч, но не читабельный, для бинарного файла
(вывод этой команды лучше не пускать на терминал - покорёжить может все
:)). Это не xdelta, но по кр. мере при помощи patch он прикладывается :)

ЗЫ проверил только на одном маленьком jar-файле.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Sun, Feb 26, 2006 at 12:04:59PM +0300, Anton Farygin wrote:
> On Wed, 22 Feb 2006 16:41:44 +0300, Dmitry V. Levin wrote:
> 
> > Нет, не надо, спасибо; очень неудобно,
> > очень негибко, очень непрозрачно.
> 
> А куда ещё можно положить большое количество бинарей ?

На диск? :)

> В идеале конечно хотелось бы счасться -
> иметь такой бинарный репозитарий, что бы
> между версиями тарболлов хранились дельты. 
> 
> Вопрос - как это правильно сделать ?

Вопрос - а зачем это делать?
Тут есть 2 противоположные задачи - экономить занимаемое место либо
увеличить скорость доступа.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

Dmitry V. Levin пишет:
> On Sun, Feb 26, 2006 at 12:04:59PM +0300, Anton Farygin wrote:
> 
>>On Wed, 22 Feb 2006 16:41:44 +0300, Dmitry V. Levin wrote:
>>
>>
>>>Нет, не надо, спасибо; очень неудобно,
>>>очень негибко, очень непрозрачно.
>>
>>А куда ещё можно положить большое количество бинарей ?
> 
> На диск? :)
> 
>>В идеале конечно хотелось бы счасться -
>>иметь такой бинарный репозитарий, что бы
>>между версиями тарболлов хранились дельты. 
>>
>>Вопрос - как это правильно сделать ?
> 
> Вопрос - а зачем это делать?
> Тут есть 2 противоположные задачи - экономить занимаемое место либо
> увеличить скорость доступа.

В чём именно противоположность?

Та же xdelta экономит и трафик, и занимаемое в репозитории
subversion место.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

On Sun, Feb 26, 2006 at 07:51:04PM +0300, Vitaly Ostanin wrote:
> Dmitry V. Levin пишет:
> > On Sun, Feb 26, 2006 at 12:04:59PM +0300, Anton Farygin wrote:
> >>On Wed, 22 Feb 2006 16:41:44 +0300, Dmitry V. Levin wrote:
> >>
> >>>Нет, не надо, спасибо; очень неудобно,
> >>>очень негибко, очень непрозрачно.
> >>
> >>А куда ещё можно положить большое количество бинарей ?
> > 
> > На диск? :)
> > 
> >>В идеале конечно хотелось бы счасться -
> >>иметь такой бинарный репозитарий, что бы
> >>между версиями тарболлов хранились дельты. 
> >>
> >>Вопрос - как это правильно сделать ?
> > 
> > Вопрос - а зачем это делать?
> > Тут есть 2 противоположные задачи - экономить занимаемое место либо
> > увеличить скорость доступа.
> 
> В чём именно противоположность?
> 
> Та же xdelta экономит и трафик, и занимаемое в репозитории
> subversion место.

Ну как же, для локальной работы взять готовый blob гораздо быстрее, чем взять его
начальную версию и прикладывать дельты.

Сетевой трафик дельты, конечно, могут сэкономить, если их мало.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

Dmitry V. Levin пишет:

<skipped/>

>>>>В идеале конечно хотелось бы счасться -
>>>>иметь такой бинарный репозитарий, что бы
>>>>между версиями тарболлов хранились дельты. 
>>>>
>>>>Вопрос - как это правильно сделать ?
>>>
>>>Вопрос - а зачем это делать?
>>>Тут есть 2 противоположные задачи - экономить занимаемое место либо
>>>увеличить скорость доступа.
>>
>>В чём именно противоположность?
>>
>>Та же xdelta экономит и трафик, и занимаемое в репозитории
>>subversion место.
> 
> Ну как же, для локальной работы взять готовый blob гораздо быстрее, чем взять его
> начальную версию и прикладывать дельты.

Чего-то я не понимаю, наверное. Зачем брать начальную версию и
прикладывать версии?

svn позволяет взять любую версию файла так же, как и cvs. Дельты
- это просто внутренний механизм хранения репозитория.

Для клиента доступны и файлы полностью, и дельты, как показал svd@

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

On Mon, Feb 27, 2006 at 12:18:10PM +0300, Vitaly Ostanin wrote:
> Dmitry V. Levin пишет:
[...]
> >>>>В идеале конечно хотелось бы счасться -
> >>>>иметь такой бинарный репозитарий, что бы
> >>>>между версиями тарболлов хранились дельты. 
> >>>>
> >>>>Вопрос - как это правильно сделать ?
> >>>
> >>>Вопрос - а зачем это делать?
> >>>Тут есть 2 противоположные задачи - экономить занимаемое место либо
> >>>увеличить скорость доступа.
> >>
> >>В чём именно противоположность?
> >>
> >>Та же xdelta экономит и трафик, и занимаемое в репозитории
> >>subversion место.
> > 
> > Ну как же, для локальной работы взять готовый blob гораздо быстрее, чем взять его
> > начальную версию и прикладывать дельты.
> 
> Чего-то я не понимаю, наверное. Зачем брать начальную версию и
> прикладывать версии?
> 
> svn позволяет взять любую версию файла так же, как и cvs. Дельты
> - это просто внутренний механизм хранения репозитория.

Все средства всё позволяют, вопрос в эффективности реализации.
Здесь то и кроется противоположность.

> Для клиента доступны и файлы полностью, и дельты, как показал svd@

Это хорошо, конечно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Sun, 26 Feb 2006 19:19:48 +0300, Dmitry V. Levin wrote:

>> Вопрос - как это правильно сделать ?
> 
> Вопрос - а зачем это делать? Тут есть 2
> противоположные задачи - экономить
> занимаемое место либо увеличить
> скорость доступа.

Увеличить скорость доступа, однозначно. 

Я не вижу смысла экономить где-то место.

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Mon, 27 Feb 2006 15:18:40 +0300, Dmitry V. Levin wrote:

> 
> Все средства всё позволяют, вопрос в
> эффективности реализации. Здесь то и
> кроется противоположность.

Можно расшифровать ? противоположность чему ?

Эффективность у кого ?

Rgds,
Rider

Re: [devel] Q: процесс работы над пакетами

[Anton Farygin]

On Sun, 26 Feb 2006 16:57:16 +0300, Aleksey Avdeev wrote:

> Anton Farygin пишет:
>> On Sun, 26 Feb 2006 13:20:12 +0200, Sviatoslav Sviridov wrote:
>> 
>> 
>>>Anton Farygin wrote on 2/26/2006 1:06 PM:
>>>
>>>>On Sun, 26 Feb 2006 13:00:21 +0300, Aleksey Avdeev wrote:
>>>>
>>>>
>>>>>  Если не ошибаюсь -- subversion, для бинарей,
>>>>>  так и поступает. Вопрос,
>>>>>правда, на сколько это эффективно для
>>>>>сжатых тарболлов
>>>>
>>>>Помимо этого нужно понимать, что с
>>>>точки зрения subversion это два разных
>>>>бинаря, а не обновление одного.
>>>
>>>Как вариант: делать
>>>svn mv <файл>-<версия>.tar.bz2
>>><файл>-<версия+1>.tar.bz2 перед добавлением
>>>новой версии :) Если от этого
>>>действительно будет польза...
>> 
>> 
>> Я проверял.. что то не получается за
>> одну итерацию. Похоже что работает
>> только в случае svn mv;svn commit;
> 
>   Примерно: работает если файл с
>   отсутствующий в репозитарии ранее
> получен как svn cp существующего (svn cp -r ... --
> частный случай).
> 
> PS: Для svn merge -- похоже что не работает.

ну да. в общем надо бы пройтись по этой фиче и зафиксить.


Rgds,
Rider