Bug 5685

*** Bug 5686 has been marked as a duplicate of this bug. ***

Лучше даже наверное не просто скрипт, а с графической оболочкой.
Осталось определить откуда он будет скачивать пакеты и лицензию, или этот скрипт будет генерироваться каждый раз когда происходит заказ?

Всё скачивать будет клиент.
Граф. оболочка потом.

Created attachment 1773 [details]
скрипт установки wine@etersoft под убунту.

Comment on attachment 1773 [details]
скрипт установки wine@etersoft под убунту.

Все переменные "говорящие". Функции описаны. скрипт короткий- не вижу смысла документировать каждую строчку.

Проверь скриптик.

Нет ли риска уже настроенную хост систему удалить вместе с ~/.wine?

1) Не удаляется стандартный wine. (...57 строка, gawk не найдена...)
2) Не помешало бы, перед удалением .wine делать wineserver -k
3) Напоминаю про текстовую переменную, которую надо завести...
4) И еще такой нереальный случай. Если запустить скрипт из под рута, а потом от юзера - то не удастся переписать временный файл win-inst

Так вроде как все..

Переделал скрипт. Сделал читаемым. Изменил внутреннюю логику так, что его можно дополнять функционалом не переписывая основную часть. 
Отлаживаю.

Отлаживал скрипт.

По умолчанию скрипт переносит существующий ~/.wine в ~/wine.backup, это поведение можно изменить опциями, которые описаны во встроенной документации.
Скрипт обрабатывает аргументы командной строки.

Запуск скрипта необходимо производить от имени обычного пользователя, в ходе выполнения попросит пароль для sudo.

Если запускать скрипт через sudo, тогда не будет создан .wine, потому что все исполняемые в скрипте команды выполняются от имени root'а, в скрипте можно сделать проверку этой ситуации или сделать `su -` обратно в пользователя для создания .wine. Надо ли вообще реализовывать.

скрипт не может обработать такую ситуацию.
Пользователь запускает скрипт, пакет начинает устанавливаться. В ходе установки пользователь нажимает `ctrl+c`, выполнение скрипта останавливается. Пакет установился но не правильно. Для того чтобы удалить этот пакет, система требует сначала его установить еще раз, и только потом удалить.
Чисто теоретически(вероятно) можно сделать проверку такой ситуации, нужно ли это реализовать?

Вероятно надо добавить опцию только удаления wine/WINE@Etersoft.


Имена пакетов хранятся в переменной LIST_OF_PACKAGES.
Я проверял установку на 2-х пакетах, wine* и wine-local*. Нужна ли установка других пакетов "из коробки"? По хорошему проверять бы наличие микрософтовских шрифтов в системе.

Created attachment 2108 [details]
wineinstall

Как его людям отгружать будем?

(В ответ на comment #12)
> Created attachment 2108 [details]
> wineinstall
> 
> Как его людям отгружать будем?

Напиши пожалуйста инструкцию по пунктам как использовать скрипт. Я конечно что то понял но не все. Нужно подробно (где и как его запускать)

В самом скрипте в переменную LIST_OF_PACKAGES помещается список пакетов, которые надо установить. Это сделано для того, чтобы клиент не мог поставить пакеты, которые несовместимы друг с другом, с другой стороны в таком виде придется зашивать названия пакетов при отгрузке. Можно сделать так, чтобы устанавливались все пакеты в текущем каталоге, но у пользователей очень часто бывает так, что в каталоге много пакетов набросано, в таком случае можно сузить круг подозреваемых проверяя имена пакетов на вхождение подстроки wine. Надо подумать как удобнее будет клиенту.

./wineinstall --help
Usage: ./wineinstall [options]

-h, --help            display this help message
-n, --new            remove old ~/.wine and set new wine enviroment
-k, --keep            keep and replace old ~/.wine to ~/wine.backup

по умолчанию опция -n включенна, то есть при запуске скрипта, после проверки наличия пакетов и их установки происходит удаление каталога ~/.wine.
Опция -k при установке указывает на то, что при установке не надо удалять ~/.wine и перемещяет его в ~/wine.backup.

мне кажется, что ничего нового я не написал.

Если скрипт будет отгружаться отдельно от пакетов, а скорее всего так оно и будет, тогда надо сделать так чтобы устанавливались пакеты из текущего каталога в названии которых присутствует слово wine.

(В ответ на comment #14)
> В самом скрипте в переменную LIST_OF_PACKAGES помещается список пакетов,
> которые надо установить. Это сделано для того, чтобы клиент не мог поставить
> пакеты, которые несовместимы друг с другом, с другой стороны в таком виде
> придется зашивать названия пакетов при отгрузке. Можно сделать так, чтобы
> устанавливались все пакеты в текущем каталоге, но у пользователей очень часто
> бывает так, что в каталоге много пакетов набросано, в таком случае можно сузить
> круг подозреваемых проверяя имена пакетов на вхождение подстроки wine. Надо
> подумать как удобнее будет клиенту.

А нельзя формировать LIST_OF_PACKAGES на лету, производя отгрузку? Чтобы в него попадали все пакеты, которые складываются в директорию для скачивания.


(В ответ на comment #15)
> Если скрипт будет отгружаться отдельно от пакетов, а скорее всего так оно и
> будет, тогда надо сделать так чтобы устанавливались пакеты из текущего каталога
> в названии которых присутствует слово wine.

Это логично, только тогда маска будет wine-etersoft-. Опять же, с помощью LIST_OF_PACKAGES это идея замещается на идею работы со списком.

Может лучше в скрипт зашивать ссылки на пакеты для скачивания и самим скачивать, а только потом устанавливать?

переменная LIST_OF_PACKAGES была заведена для того, чтобы скрипт гарантированно работал. НА мой взгляд в скрипт лучше зашивать конкретные имена пакетов(ссылки для скачивания оных), чтобы установка проходила в любом случае, так как не редки случае, когда клиент скачивает куча разных пакетов(наших пакетов) в одну директорию, что будет если он запустит скрипт установки в такой директории совсем не понятно(хотя dpkg/rpm/apt-get/yum должны делать какую-то сортировку, если пакеты заданы паттерном).

переменная LIST_OF_PACKAGES была заведена для того, чтобы скрипт гарантированно работал. НА мой взгляд в скрипт лучше зашивать конкретные имена пакетов(ссылки для скачивания оных), чтобы установка проходила в любом случае, так как не редки случае, когда клиент скачивает куча разных пакетов(наших пакетов) в одну директорию, что будет если он запустит скрипт установки в такой директории совсем не понятно(хотя dpkg/rpm/apt-get/yum должны делать какую-то сортировку, если пакеты заданы паттерном).

переменная LIST_OF_PACKAGES была заведена для того, чтобы скрипт гарантированно работал. НА мой взгляд в скрипт лучше зашивать конкретные имена пакетов(ссылки для скачивания оных), чтобы установка проходила в любом случае, так как не редки случае, когда клиент скачивает куча разных пакетов(наших пакетов) в одну директорию, что будет если он запустит скрипт установки в такой директории совсем не понятно(хотя dpkg/rpm/apt-get/yum должны делать какую-то сортировку, если пакеты заданы паттерном).

Сводная таблица, в которой указано куда включен корневой сертификат cacert.org 
http://wiki.cacert.org/InclusionStatus, к сожалению не густо.

(В ответ на comment #21)
> Сводная таблица, в которой указано куда включен корневой сертификат cacert.org 
> http://wiki.cacert.org/InclusionStatus, к сожалению не густо.

прошу прощения, ошибся окошком.

Откладываю.
Скрипт держим в уме (что он есть).
Но скорее всего будем использовать epm.