Поддерживаю, это решило бы спор о том, можно хранить спеки в .gear/ или нельзя в тем, что все необходимые файлы для сборки пакета на Alt переедут в соответствующую директорию.

(Ответ для Alexandr Shashkin на комментарий #1)
> Поддерживаю, это решило бы спор о том, можно хранить спеки в .gear/ или
> нельзя в тем, что все необходимые файлы для сборки пакета на Alt переедут в
> соответствующую директорию.

Как? Что мешает это сделать сейчас? Есть несколько схем сборок, которые хранят всё в корне сборочного репозитория. Например сборка из тегов без исходников или сборка с апстримнным поддеревом. С ними как быть?

Какая реальная проблема существует на текущий момент и ближайшем будущем, которая бы нуждалась в запрете размещения файлов в .gear?

Сейчас от .gear-rules или .gear/rules отказаться невозможно.

(Ответ для Anton Farygin на комментарий #3)
> Сейчас от .gear-rules или .gear/rules отказаться невозможно.
А зачем отказываться?

(Ответ для Сергей Жидких на комментарий #4)
> (Ответ для Anton Farygin на комментарий #3)
> > Сейчас от .gear-rules или .gear/rules отказаться невозможно.
> А зачем отказываться?

что бы было одно место для вcего, что связано с altlinux, с такой конфигураций репозитория удобнее работать.

Я против обязательной дополнительной сущности в виде подкаталога. Если придерживаться концепции pristine source, то сам исходный код лежит в теге, а в пустом бранче спек, патчи и .gear/. Так проще 
* мержить
* разделять альтовые файлы и апстримные файлы
* искать среди альтового.

Все подкаталоги являются суррогатным решением, противным идеологии git. И не надо приводить в пример Debian, который буквально соткан из неэффективных суррогатных решений.

(Ответ для Andrey Cherepanov на комментарий #6)
> Я против обязательной дополнительной сущности в виде подкаталога. Если
> придерживаться концепции pristine source, то сам исходный код лежит в теге,
> а в пустом бранче спек, патчи и .gear/. Так проще 
> * мержить
> * разделять альтовые файлы и апстримные файлы
> * искать среди альтового.
> 
> Все подкаталоги являются суррогатным решением, противным идеологии git. И не
> надо приводить в пример Debian, который буквально соткан из неэффективных
> суррогатных решений.

Такая схема неудобна, когда нужно работать с кодом, а не только заниматься упаковкой:

Если мейнтейнер по каким-то причинам не позаботился о добавлении gear-remotes, приходится добавлять его самому (и портить исходный сборочный репозиторий) либо лезть .gear/tags и искать нужный хэш там.

Потом нужно делать checkout, но перед ним нужно сделать обязательно сделать stash.

После checkout все сборочные файлы исчезают и чтобы соотносить код и сборочную среду приходится либо прыгать туда сюда либо делать копию исходников и вмешиваться в структуру репозитория.

Это всё несложно и можно автоматизировать в какой-то степени, но отнимает время и силы исследователя в пустую.

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

На мой взгляд, единственным правильным решением в данной ситуации является сборка из тега с добавлением git subtree, как это сделано здесь: https://git.altlinux.org/gears/i/iroh.git?p=iroh.git;a=tree.

Данный подход лишён минусов, описанных выше. Единственными двумя проблемами этого метода являются отсутствие гарантий соответствия между тегом и поддеревом, а также особенности реализации `git subtree`, которые приводят к необходимости обязательного слияния поддерева с созданием нового коммита, что в некоторых случаях совершенно неприемлемо.

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

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

Предлагаю:
1. научить gear видеть спек в каталоге altlinux/ без необходимости прописывания его в .gear/rules
2. делать автоматический exclude в теге diff (.gear/rules) для каталогов .gear и altlinux
3. оставить .gear в покое, так как заставлять всех всё переделывать неправильно, а создавать третью вариацию altlinux/rules совсем плохая идея (мало нам вариации .gear-rules и .gear/rules).

Т.е. для начала предлагаю создать удобства и рассказать о них. А там видно будет.

помимо spec есть и другие необходимые для сборки компоненты, которые всё равно придётся перечислять в .gear/rules

проще сделать .gear/* и всё.

(Ответ для Anton Farygin на комментарий #10)
> помимо spec есть и другие необходимые для сборки компоненты, которые всё
> равно придётся перечислять в .gear/rules
> 
> проще сделать .gear/* и всё.

Так они все опциональны и как их не прописывать? Например:
copy: что_угодно

именно. поэтому положить всё в один каталог altlinux выглядит здравой идеей - не делить на два.

полная аналогия с debian

(Ответ для Anton Farygin на комментарий #12)
> именно. поэтому положить всё в один каталог altlinux выглядит здравой идеей
> - не делить на два.
> 
> полная аналогия с debian

Тогда давайте сделаем copy altlinux/* по дефолту ещё (за исключением *.spec).
И тогда оставить разделение оказывается ещё более оправданным. При сборке из srpm совершенно не нужен же .gear/rules и подобное.

(Ответ для Антон Мидюков на комментарий #13)
> (Ответ для Anton Farygin на комментарий #12)
> > именно. поэтому положить всё в один каталог altlinux выглядит здравой идеей
> > - не делить на два.
> > 
> > полная аналогия с debian
> 
> Тогда давайте сделаем copy altlinux/* по дефолту ещё (за исключением *.spec).
> И тогда оставить разделение оказывается ещё более оправданным. При сборке из
> srpm совершенно не нужен же .gear/rules и подобное.

а он туда и не попадает

(Ответ для Anton Farygin на комментарий #14)
> (Ответ для Антон Мидюков на комментарий #13)
> > (Ответ для Anton Farygin на комментарий #12)
> > > именно. поэтому положить всё в один каталог altlinux выглядит здравой идеей
> > > - не делить на два.
> > > 
> > > полная аналогия с debian
> > 
> > Тогда давайте сделаем copy altlinux/* по дефолту ещё (за исключением *.spec).
> > И тогда оставить разделение оказывается ещё более оправданным. При сборке из
> > srpm совершенно не нужен же .gear/rules и подобное.
> 
> а он туда и не попадает

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