59716 2026-07-02 19:47:54 +0300 Каталог altlinux/ по умолчанию (по аналогии с debian/) 2026-07-06 10:06:10 +0300 1 1 4 Development Sisyphus gear unstable x86_64 Linux NEW P5 enhancement --- 1 rider ldv cas dutyrok glebfm ldv legion placeholder rider rx1513 qa-sisyphus oldest_to_newest 290618 0 rider 2026-07-02 19:47:54 +0300 продлагаю добавить поддержку размещения всего .gear/* в каталоге altlinux/ в дереве проекта по умолчанию - сделать так что бы .gear-rules был наравне с .gear/rules и altlinux/rules specfile из каталога altlinux искался наравне с specfile из корневого каталога проекта. Цель - возможности перенести всё что нужно для сборки проекта под altlinux в единый каталог altlinux/ без дополнительного .gear 290652 1 dutyrok 2026-07-03 14:05:16 +0300 Поддерживаю, это решило бы спор о том, можно хранить спеки в .gear/ или нельзя в тем, что все необходимые файлы для сборки пакета на Alt переедут в соответствующую директорию. 290657 2 rx1513 2026-07-03 14:15:37 +0300 (Ответ для Alexandr Shashkin на комментарий #1) > Поддерживаю, это решило бы спор о том, можно хранить спеки в .gear/ или > нельзя в тем, что все необходимые файлы для сборки пакета на Alt переедут в > соответствующую директорию. Как? Что мешает это сделать сейчас? Есть несколько схем сборок, которые хранят всё в корне сборочного репозитория. Например сборка из тегов без исходников или сборка с апстримнным поддеревом. С ними как быть? Какая реальная проблема существует на текущий момент и ближайшем будущем, которая бы нуждалась в запрете размещения файлов в .gear? 290661 3 rider 2026-07-03 14:27:46 +0300 Сейчас от .gear-rules или .gear/rules отказаться невозможно. 290686 4 rx1513 2026-07-03 16:20:36 +0300 (Ответ для Anton Farygin на комментарий #3) > Сейчас от .gear-rules или .gear/rules отказаться невозможно. А зачем отказываться? 290698 5 rider 2026-07-03 20:52:32 +0300 (Ответ для Сергей Жидких на комментарий #4) > (Ответ для Anton Farygin на комментарий #3) > > Сейчас от .gear-rules или .gear/rules отказаться невозможно. > А зачем отказываться? что бы было одно место для вcего, что связано с altlinux, с такой конфигураций репозитория удобнее работать. 290715 6 cas 2026-07-05 12:03:36 +0300 Я против обязательной дополнительной сущности в виде подкаталога. Если придерживаться концепции pristine source, то сам исходный код лежит в теге, а в пустом бранче спек, патчи и .gear/. Так проще * мержить * разделять альтовые файлы и апстримные файлы * искать среди альтового. Все подкаталоги являются суррогатным решением, противным идеологии git. И не надо приводить в пример Debian, который буквально соткан из неэффективных суррогатных решений. 290717 7 rx1513 2026-07-05 14:31:41 +0300 (Ответ для 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`, которые приводят к необходимости обязательного слияния поддерева с созданием нового коммита, что в некоторых случаях совершенно неприемлемо. Однако я думаю, что обе эти проблемы можно легко исправить. 290737 8 rider 2026-07-06 10:06:10 +0300 В git subtree к сожалению не работает нормально сопровождение изменений поверх апстрима - по опыту использования конфликты разрешаются гораздо тяжелее. Плюс сложнее отправлять изменения в апстрим проекта.