Перекинул сюда сообщения из темы про 2Gis, чтобы все обсуждение вопросов сборки ПО с wine-префиксом было в одном месте.
Перекинутые сообщения в этой теме под номерами с 8 по 26.
xxblx

Всем спасибо за комментарии и ответы! Если честно, ожидал продолжения дискуссии о целесообразности с эмоциями, но все четко и по делу. Итак, давайте по порядку.
1) Что делать с ключами? Мне думается, что отталкиваться нужно от того, будут ли формально наши пакеты являться частью основного репозитария пусть и в отдельной ветке или это будет считаться как отдельный проект в рамках сообщества. Я понимаю, что доверия к виндовс программам и уж тем более к закрытому коду много и на то есть веские основания. И желание держать их отдельно вполне предсказуемо. Так же как и желание не подписывать то, с чем могут быть проблемы, значит и потеря репутации и веса сообщества. Здесь 2 варианта (в случае ключей для подписи пакетов) - или один ключ для ВСЕХ пакетов репозитария как это сделано для линукс пакетов или отдельный ключ для отдельного проекта. Мне бы хотелось, чтобы ключ был один, без всякого разделения на своих и чужих...
2) Если нужна программа Flylink, то с нее и начнем, тем более, что по ссылкам выше она под wine вполне работоспособна (пусть и с шероховатостями). Но куда выкладывать пакет после его создания? Не хочу автору просьбы ничего навязывать, но лучше присмотреться все-таки к линукс программам. Но это просто совет, не более и решать, чем пользоваться, только ему.
3) Давайте более детально продумаем в каких каталогах должны быть размещены файлы виндовс программ. Может быть, выработается единая политика репозитария. Если она появится, то можно собрать правила, созданные здесь в новой теме и прикрепить ее. Это здорово облегчит работу на будущее. И брать ли за образец при создании пакета уже существующий пакет с 2ГИС и его особенности?
4) Теперь о структуре отдельной ветки (очень надеюсь, что это будет отдельная ветка как часть репозитария сообщества, а не как репозитарий вне сообщества!). Структура может быть такая:
/wine/
/wine/free/
/wine/free/SRPMS
/wine/free/i586(x86_64)/RPMS
Также  для ветки nonfree. Правда скажу сразу, что подветка x86_64 врят ли будет сильно заполнена, но будем искать и 64-битные версии программ. Вот только будет ли у нас настоящий 64-bit wine без multilib и biarch? Теперь о ветках - free - тут будут программы с лицензиями, разрешающими дальнейшее распространение и редистрибьюцию. Здесь же будут и некоторые opensource программы, которые есть исключительно только для windows и которых в линуксе нет. Ветка non-free соответственно будет для программ, которые несвободны в плане распространения и дистрибьюции, но на которые у нас могут быть разрешения на это от авторов (например, в будущем). Это может стать изюминкой всего репозитария и своего рода рекламой для авторов (чтобы они охотнее давали разрешение, но здесь как решит сообщество! если скажет нет, значит нет и будем работать с авторами аргументами, исключающими выгоду). Можно еще создать ветку noarch ветку для данных и полезных дополнений к программам (разумеется, никакого вареза и креков с ключами и генераторами оных). Мета информация для системы управления пакетами будет внутри RPMS.
5) Еще остается вопрос про версии вайна. Здесь мне думается 2 варианта - или приспосабливать программы под версию вайна из репозитария магейи (или RMC?) или создать пакеты разных версий вайна, хранить их в отдельной подветке ветки wine и в зависимостях каждого пакета с виндовс программой прописывать зависимости от конкретной версии вайна с удалением ранее установленного вайна (любого) во избежание конфликтов, но в этом случае скрипт постобработки пакета должен удалять и папку с вайном и всем ее содержимым из домашнего каталога пользователя (или как вариант вводить систему debian alternatives, но с этим уже нужно выходить к разрабам самой магейи). Общий принцип - программа должна как можно лучше работать под вайном той или иной версии и эта версия должна быть прописана в зависимостях к пакету (желательно как обязательная и идеально, если это будет вайн из самой магейи или из нашего репозитария). С него и надо начинать любые телодвижения по запуску программ, чтобы не нарушить целостность устоявшейся пакетной базы стабильного дистрибутива. Если программа с вайном из репозитария не заработала, то уже переходить на другую и смотреть и не забыть потом эту версию вайна по всем правилам собрать в пакет, чтобы уменьшить и без того сизифов труд. Параллельно можно будет  отправлять багрнпорты в проект wine и возможные патчи и исправления. Но это так - пожелание. При работе можно использовать базу данных по работоспособности программ в вайне на его сайте.
6)Касательно зависимостей. Можно разделить программу на несколько более мелких пакетов (если возможна редистрибьюция по лицензии) или в один большой, в котором все оптом. Про зависимости (обязательные!) от вайна - думаю, все и так понятно. И как идея - некоторые зависимости от линукс пакетов, например с данными. Но как необязательные. И это просто идея!
Таковы мои мысли на сей счет. Что добавит сообщество?

Согласен, только продумать как реализовать подпись при перемещении в основную из тестинга.

Там скрипт на автомате подпишет по таймеру. То есть мы просто перемещаем в основную репу, а подпись нас не волнует, за нас все сделает скрипт на сервере по таймеру.

Вот и отлично! Начали формироваться общие правила! Со временем может появиться серьезный репозитарий, который будут рекомендовать к использованию! Что, если сделать доп. пакеты с картами 2ГИС и может быть, доп. слоями и прибамбасами к этим картам для разных городов и вместе с 2ГИС переместить в вайн ветку? Насчет ключей - может не стоит так сразу отказываться от подписывания вин-ветки. Ведь эти пакеты тоже часть работы сообщества да и подтверждает источник происхождения пакетов, а то работа очень будет напоминать детскую забаву, а ведь наполнение может стать серьезным и его будут активно использовать и в будущем вопрос о подписи может и встать! А так решим заранее проблему. Ведь в соседней теме уже поднимали вопрос о подписи когда в основном репозитарии накопилось очень много пакетов и у администраторов встала проблема подписывания такой оравы пакетов. Эта же проблема может всплыть с вин-веткой. Насчет пакета с 2ГИС - пусть будет в качестве образца. При создании пакетов в будущем предлагаю ориентироваться на него.

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

Во всех репозиториях тестинг подписывается, вообще там все ветки подписываются. Тестинг можно подписать, но вин-ветку пока не стоит.

Required: wine >= версия
или строго если только с конкретным wine:
Required: wine = версия

И то верно! Ведь при пересборке кроме спека еще и src.rpm требуется. Тогда гуд! Будем указывать url.  Насчет доверия - а где гарантия, что указннаый юрл именно с сайта автора, а не левый. За себя я могу поручиться, а вот за остальных.. Кстати, уж не по этой ли причине администраторы не хотят подписывать вин-ветку? Боятся иска в суд или 2 крепких ребят с ножами в темном переулке с парочкой дурацких вопросов о качестве сборки и источнике программ в пакетах?:-) Хотя и я могу не найти файла программы для пакета на официальном сайте автора этой программы равно как и самого сайта. А посему придется брать из других источников, заслуживающих доверия... Или которым доверия нет вообще, но там есть нужный файл...
Желания опакетить 2ГИС нет. Скорее есть желание довести поддержку 2ГИС в Магейе до логического конца. Правда, нужно будет узнать, можно ли эти карты и дополнения распространять без проблем со стороны правообладателя и поддерживать их в актуальном состоянии.

В России можно всё, что не запрещено. Запрета нет.

Или учебник ошибся или не все так просто.. Так указывать url в SOURCES или это бесполезно и нужно при сборке качать файл вручную?

Вот тоже интересно - если указывать урл то в SOURCES пакет можно не ложить, он сам туда скачается? Или, как написано rpmbuild просто отбросит урл и считает исходник по имени в каталоге SOURCES?