Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
На этот форум и wiki ведут ссылки с официальных сайтов Mageia.
У форума нет нигде и никаких чатов, wiki пока не работает (в процессе подключения), идёт небольшая реорганизация.Форум закрывается, подробности в теме «Реорганизация форума».
Mageia Russian Community Forum → Обсуждение сборки пакетов → Сборка пакетов для windows программ под вайн
Походу сам не качается, но url надо писать, чтобы все знали откуда взято.
Тоесть мануал верный? Тогда однозначно - качать, вкладывать и пакетить, только так.
Тоесть мануал верный? Тогда однозначно к=- качать, вкладывать и пакетить, только так.
Чтож, если так, то.. Значит, вступают в строй все + и - ручного копирования, описанные ранее. Один вопрос решен. Приступаю к сборке пакета.
Приступаю к сборке пакета.
Кидай пока в construct, потом разберемся.
Опыт подсказывает, что "нет ничего более постоянного чем "временное"". 
Вот еще один интересный момент - как быть с зависимостями самих виндовс программ типа net. framework, jdk, directX? Многие из них требуют наличия лицензии самой винды и запрещают перепаковку. Можно использовать скрипт winetricks для выкачки и установки этого ПО. Но блин юрлы у компонентов часто меняются и скрипт завершается с ошибкой. Да и работа со скриптом требует определенных навыков. А в пакеты компоненты винды не засунешь без некоторых юридических проблем. Плюс лицензия на винду запрещает использовать библиотеки и шрифты по отдельности от самой винды. Поэтому программы придется крайне тщательно подбирать, причем такие, которые либо не используют такие компоненты, либо УЖЕ несут их в составе своего дистрибутива и котрые имеют разрешение на распространение (уточнить, что не только авторы имеют право их распространять в составе программы!). Но ничего - дорогу осилит лишь идущий!
Можно подумать над созданием отдельной ветки или вообще репозитария на сторонних ресурсах для таких проблемных компонентов. И сам собой встает вопрос - что будут делать администраторы в случае, если такие компоненты будут находиться в ветке wine и будет угроза судебного иска. И вообще, что будут делать в случае если на сервере репозитария будет лежать контент с нарушениями лицензии или авторского права?
Если проблем с хранением пакетов с компонентами винды не предвидится, то можно ли будет их загрузить на сервер?
Вот поэтому я и против вообще любого опакечивания виндовых программ. Кому нужно ставит в вайне то, что нужно. Кому не нужно - вообще не парится. + У держателей сайта-репы-форума голова не болит из-за возможных проблемм с законом и потенциального закрытия ресурса. Особенно в свете последних событий (лукоморье, либрусек и т. д.). И все довольны. Потому я и говорил, что затея похожа на изобретение велосипеда. Но коль уж хочется - думайте, решайте как обойти подводные камни проприетарщины.
Вот поэтому я и против вообще любого опакечивания виндовых программ. Кому нужно ставит в вайне то, что нужно. Кому не нужно - вообще не парится. + У держателей сайта-репы-форума голова не болит из-за возможных проблемм с законом и потенциального закрытия ресурса. Особенно в свете последних событий (лукоморье, либрусек и т. д.). И все довольны. Потому я и говорил, что затея похожа на изобретение велосипеда. Но коль уж хочется - думайте, решайте как обойти подводные камни проприетарщины.
Согласен, но все равно репозитарий будет более достойным вариантом. Вот так прятаться и где-то что-то тайком использовать - тоже не выход.
Кстати, не пора ли перетрясти на предмет законности и основной репозитарий? А то там все пакеты без разбора в одну кучу свалены. Разделение лишь по архитектурам и типам пакетов. Даже в Магейе они выделили tainted для таких ОСОБЫХ случаев.
Зато это будет на совести конкретного пользователя, на его страх и риск и не затронет сообщество, которое в большинстве своём не сильно-то нуждается в виндовых программах. ИМХО конечно.
Полно виндовых программ с открытым кодом, например, Flylink. Подбор ПО для wine ветки по тем же принципам, что и линуксовый - смотреть лицензию.
Например, я опакечивал vmware-player, но его нельзя опакечивать. Мы обсуждали этот вопрос здесь на форуме и решили, что в виде пакетов его быть не может, но src.rpm - пожалуйста. По сути src.rpm является лишь инструкцией о том как опакетить vmware-player, и каждый, кому это надо, сможет сделать это сам. Но это для очень нужных пакетов, которые хотелось бы опакетить, но нельзя.
По зависимостям: если есть любая такого рода зависимость, то пакет собирать нельзя.
Зато это будет на совести конкретного пользователя, на его страх и риск и не затронет сообщество, которое в большинстве своём не сильно-то нуждается в виндовых программах. ИМХО конечно.
Чтож, это так и каждый выбирает по себе женщину, религию, дорогу.. Дьяволу служить или Пророку - каждый выбирает по себе... Но есть одно НО - до тех пор, пока Линукс будет использоваться в работе и пока не появится нативных аналогов, мы как линуксоиды обязаны помочь другим пользователям. Даже если будет непросто! Тем и отличаемся от остальных...
Полно виндовых программ с открытым кодом, например, Flylink. Подбор ПО для wine ветки по тем же принципам, что и линуксовый - смотреть лицензию.
Например, я опакечивал vmware-player, но его нельзя опакечивать. Мы обсуждали этот вопрос здесь на форуме и решили, что в виде пакетов его быть не может, но src.rpm - пожалуйста. По сути src.rpm является лишь инструкцией о том как опакетить vmware-player, и каждый, кому это надо, сможет сделать это сам. Но это для очень нужных пакетов, которые хотелось бы опакетить, но нельзя.
По зависимостям: если есть любая такого рода зависимость, то пакет собирать нельзя.
Получается что-то типа дебиановского пакета со скриптом для загрузки, распаковки, установки и настройки например флеш плеера? Сам плеер выкачивается из сети с сайта Адоба и в пакете его нет. С той лишь разницей, что там он берет готовое для установки и настройки, а src.rpm использует это готовое с сайта для сборки?
Мда, жалко! Сколько программ идет мимо ветки репозитария только из-за собственнических компонент, которые популярны и широко используются..
Ну если считать, что линукс используется в работе (на предприятии любом), то на таком предприятии обязательно будет линукс-админ и для него поставить виндо-прогу в вайне не должно быть проблеммой абсолютно. А что до пользователей, то лучше пусть у них будет лишний стимул поглубже изучить линукс, чем лишняя возможность навредить системе чужеродными для нее (системы) действиями. Но, повторюсь, это только моё личное мнение.
vmware-player не скачаешь с сайта просто так, там сначала надо лицензию читать, а ссылка всегда динамическая.
skype, flash-player можно скачать с сайта при установке пакета, что и происходит.
Так что в каждом конкретном случае надо думать и смотреть как сделали в линусе в аналогичных ситуациях.
Ну если считать, что линукс используется в работе (на предприятии любом), то на таком предприятии обязательно будет линукс-админ и для него поставить виндо-прогу в вайне не должно быть проблеммой абсолютно. А что до пользователей, то лучше пусть у них будет лишний стимул поглубже изучить линукс, чем лишняя возможность навредить системе чужеродными для нее (системы) действиями. Но, повторюсь, это только моё личное мнение.
Если это сделать из репозитария с цифр. подписью, проверенными пакетами и работоспособностью их содержимого штатными средствами магейи, то все будет хорошо. Ну а если пользователь хочет эксперименты начать, то тут и без ветки вайн система прикажет долго жить.. На крупном предприятии - да и не один. А как быть небольшим, где держать такого спеца - достаточно дорогая задача в плане финансов? Самому изучать - ну так смысл магейи и вообще пакетных дистров в плане экономии времени и удобства теряется.. Пусть лучше они будут хорошо делать свое дело, а мы свое.
vmware-player не скачаешь с сайта просто так, там сначала надо лицензию читать, а ссылка всегда динамическая.
skype, flash-player можно скачать с сайта при установке пакета, что и происходит.
Так что в каждом конкретном случае надо думать и смотреть как сделали в линусе в аналогичных ситуациях.
Золотые слова! А я еще к этому добавлю, что прежде чем пакетировать программу, нужно подумать о целесообразности включения в ветку и посмотреть нативные аналоги. На форуме спрашивали в чем еще ценность ветки вайн кроме программ, которых нет как класс или опенсорсных, но созданных только для виндовс. Так вот, еще один плюс - поспособствовать переходу с пиратской винды на линукс. И не просто переезду в чистое поле, а на уже подготовленный участок с фундаментом и каркасом дома, который пользователь будет достраивать уже сам. Заодно и порядок в голове наведется..
А как быть небольшим, где держать такого спеца - достаточно дорогая задача в плане финансов? Самому изучать - ну так смысл магейи и вообще пакетных дистров в плане экономии времени и удобства теряется..
Ну тут уж палка о двух концах: либо раскошелиться на зарплату хорошему линукс-админу, либо раскошелиться на покупку лицензий на винду+антивирус+бухгалтерские/манагерские проги и т. д. + на ту же зарплату (пусть и несколько меньше) виндовому админу.
З.Ы. А вообще пора заканчивать прения пока они не превратились в запрешенный на нашем форуме холивар. 
В итоге - нравится/хочется - делайте. А время покажет.
Значит, приступаем. В принципе, все основные моменты понятны. Если будут вопросы, то задам их в соответствующих ветках форума. Всем спасибо за обсуждение! Завтра загружу пакет с FlyLink с привязкой к системному wine из репозитария core Магейи. И ждем обещанной ветки репозитария на сервере.
Всем добрый вечер! Не подскажет ли кто-нибудь вот какую вещь. Если у виндовой опенсорц программы (не кроссплатформенной) есть и непосредственно тарболы с исходниками, то что ложить в src.rpm? Бинарики, котрые rpm кладет и в .rpm и в src.rpm при сборке. Или все же исходники из тарболов, соответственно собирая src.rpm отдельно.
src.rpm создается сам, собирайте командой в каталоге SPECS:
rpmbuild -ba ./*.specsrc.rpm создается сам, собирайте командой в каталоге SPECS:
Консольrpmbuild -ba ./*.spec
Это я знаю. Вопрос в другом. Что должно быть внутри src.rpm? Тот же бинарник, что в пакете rpm, как советовали выше, скрипт, который будет выкачивать этот бинарник по юрлу из интернета или исходники из тарбола. Что из них? Проблема касается заявки на пакет с flylink. И это поможет решить подобные проблемы в будущем. Хотя непросто переносить ПО, построенное на принципах разработки с открытым кодом в Линуксе, но созданное в среде проприетарщины, обратно..
src.rpm формируется сам, поставленный вопрос некорректен.
Если не понятно как использовать различного рода exe-инсталлеры, то возьмите у нас в репах линуксовый образец - physion ftp://ftp.mageia.org.ru/mageia2/SRPMS/, там тоже нет тарбола, тем не менее это не помешало разработать алгоритм сборки этого пакета.
src.rpm формируется сам, поставленный вопрос некорректен.
Если не понятно как использовать различного рода exe-инсталлеры, то возьмите у нас в репах линуксовый образец - physion ftp://ftp.mageia.org.ru/mageia2/SRPMS/, там тоже нет тарбола, тем не менее это не помешало разработать алгоритм сборки этого пакета.
За пример спасибо! Разобрался. Это касается только случая, если продукт с закрытым кодом. А если у программы исходный код открыт, то в случае с виндовыми программами придется создать и src.rpm именно с исходниками этой программы отдельно создавать. А если учесть тот факт, что src.rpm необходим для сборки и самого rpm, то придется или помещать исходники из тарбола в отдельный src.rpm или делать их оба, но у одного будет особый индекс в версии типа -binary.src.rpm.
konovalenko_dima, не надо мудрить. src.rpm не Вы создаете, они создаются сами.
В src.rpm попадает всё, что находится в сборочной папке SOURCES и обязательно перечислено в spec-файле. На этом всё.
Ну и плюс сам СПЕК-файл, конечно.
Mageia Russian Community Forum → Обсуждение сборки пакетов → Сборка пакетов для windows программ под вайн
Работает на PunBB, при поддержке Informer Technologies, Inc, при поддержке sevo44.ru