Поддерживаю, это решило бы спор о том, можно хранить спеки в .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 к сожалению не работает нормально сопровождение изменений поверх апстрима - по опыту использования конфликты разрешаются гораздо тяжелее.
Плюс сложнее отправлять изменения в апстрим проекта.