Hi,

В gear с момента последнего обсуждения реализованы ещё две возможности:
1. Новая конструкция вида "exclude: glob_pattern..".  Такие исключения
могут быть указаны в любой строке .gear-rules и влияют на все директивы
семейства copy (т.е. местоположение exclude не имеет значения).
2. Параметр base= в директивах семейства tar может принимать пустое
значение.  В этом случае в запаковываемый тарболл попадёт содержимое
каталога, но не сам каталог.

Скрипт commit-srpms дорос до утилиты git-srpmimport, у которой слегка
другой интерфейс и которая по умолчанию не только разжимает, но и
распаковывает тарболлы.

Например, "git-srpmimport glibc-2.3.6-alt6.src.rpm" распакует содержащиеся
в glibc-2.3.6-alt6.src.rpm тарболлы:
glibc-2.3.6.tar
glibc-fedora-20050428T0846.tar
glibc-helpers.tar
glibc-libidn-2.3.6.tar
glibc-linuxthreads-2.3.6.tar

в каталоги:
glibc
glibc-fedora
glibc-helpers
libidn
glibc-linuxthreads

Автоматически заполняемый при импорте файл .gear-rules при этом будет
содержать:
$ grep ^tar .gear-rules 
tar: glibc name=glibc-2.3.6
tar: glibc-fedora name=glibc-fedora-20050428T0846 base=
tar: glibc-helpers name=glibc-helpers
tar: libidn name=glibc-libidn-2.3.6 base=libidn
tar: glibc-linuxthreads name=glibc-linuxthreads-2.3.6 base=

Зачем бывает полезно хранить тарболлы полностью распакованными?
Я вижу как минимум три плюса:
+ Удобство: готовность к работе у развёрнутого дерева выше; это касается
как непосредственно работы с распакованным деревом, так и git-diff.
+ Производительность: git работает с большим числом небольших файлов
быстрее, чем с эквивалентным небольшим числом больших файлов.
+ Ресурсоёмкость: Для обработки и хранения в упакованном виде большого
числа небольших файлов требуется меньше ресурсов, чем для эквивалентного
небольшого числа больших файлов.

Вероятно, последние два плюса можно рассматривать как недочёты в работе с
большими файлами, которые когда-нибудь будут исправлены.  Первый плюс
никуда не денется в любом случае.

Впрочем, распакованный тарболл, в отличие от разжатого, теряет свою
оригинальность (т.е. он, строго говоря, уже не pristine source), а также
часть информации (владельцы файлов, полные права доступа, даты модификации),
которая может быть важна для сборки пакета (хотя таких зависимостей лучше
избегать).


-- 
ldv