Содержимое пакетов и аддонов в текстовом файле

[RulllJazzz]

Цитата: RulllJazzz от Вчера в 21:08:39

Вектор предлагаю (даже настаиваю) направить на взаимодействие инструмента с wiki, т.к. это основная наша база знаний и туда мы сейчас переносим информацию.

Ну, это просто. Выкинуть из скрипта html-шаблон, вставить wiki-шаблон. Я таким образом даже .doc генерировал.

Вот, как мне кажется, еще одно направление развития скрипта — генерация текстовых страниц с вики-разметкой, готовых для копи-паста в вику.

Алексей, глянь генератор html DdShurick'a (20Kb), это будет, я думаю, проще, чем изобретать новый собственный велосипед. Ежели что - я помогу. Тут-то (в синтаксисе wiki и html) я понимаю.

Ну, это просто. Выкинуть из скрипта html-шаблон, вставить wiki-шаблон. Я таким образом даже .doc генерировал.

Excel о котором говорил Павел, это не Excel файл, а один из форматов, с которым МС Excel работает, а именно формат CSV.

Аналогично и тут. Одну копию генератора сделать для wiki, вторую для .csv, впендюрить всё это в скрипт и на выходе получать сразу 2 файла - для сервера и для вики.

P.S.: о CSV на википедии.

[DdShurick]

 CSV прекрасно открылся в Gnumeric. Синтаксис предельно простой, разделение запятыми. С этим форматом проблем не вижу.
Основная проблема это необходимость выкачивать пакет для проверки. Это относится и к скрипту Lexeii, и к моему генератору. Есть смысл выполнять проверку пакетов на сервере, тогда отпадёт необходимость в закачке, но, думаю это будет возможно только когда Tarmo запустит свой сервер.
 Как это реализовать? Создать на сервере пользователя и разрешить ему выполнять скрипт. Тогда выполнив команду ssh login:password@servername -n packscript мы быстро получим необходимые данные.

[RulllJazzz]

но, думаю это будет возможно только когда Tarmo запустит свой сервер

Зачем столько ждать. SSH, если мне не изменяет память, наш сервак поддерживает уже сейчас, юзера слепить не проблема. Выделить ему папку, в которую положить пару пакетов для экспериментов - тоже.

Если Tarmo появится - попрошу его организовать это.

[Lexeii]

Всё это хорошо. Как всё закрутилось!
Но мой скрипт не годится для запуска на сервере. GUI здесь лишний. Нужно снова реорганизовать код, добавив возможность запуска скрипта без GUI, полностью управляемым через параметры запуска. Жаль, но из-за ненормального режима работы на предприятии (работа в ночную смену и некстати внеочередные экзамены днем), сегодня мне хочется просто выспаться.

[RulllJazzz]

Если хочешь спать - спи. Мы от тебя никуда не убежим. 

Лучше, конечно, один файл препарировать и закачать на сервер, чем оставить как есть и каждый раз скачивать файлы с сервера. Ты в теме, у тебя траффик сам знаешь какой.

Морду можно, я думаю, и веб написать, чтоб в обозревателе открывалась. Морду эту будет выдвавть сам сервер при определённых запросах (как например аутентификация на ftp). Короче, это опять надо к Tarmo идти челом бить. 

[Lexeii]

Я не хочу распыляться. Веб-программирование не мой конек. Знаю html, несколько хуже -- javascript, и совсем плохо -- php. Моя задача сейчас -- научить скрипт выполнять свою работу без диалога, принимая только параметры командной строки. А дальше -- будем сотрудничать.

[Tarmo]

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

Нет, увы. Вернее поддерживает, но только по заранее предоставленному хостеру списку ИП-адресов... всех туда не запустят.

Моя задача сейчас -- научить скрипт выполнять свою работу без диалога

Если это заработает - тогда написать к этому добру обёртку из рнр не составит особого труда. Вернее это будет необходимо сделать, поскольку нет возможности запускать удалённо шелловские скрипты.

[RulllJazzz]

Если это заработает - тогда написать к этому добру обёртку из рнр

оно уже работает, просто мы ещё об этом не знаем. 

Алексей, ты на всякий случай оставь вариант скрипта с мордой для оффлайна. Пусть полежит, может пригодится и то и это.

[Lexeii]

Разрабатываю концепцию.

Код

# pupkg --help

pupkg — сервисные функции для работы с пакетами и аддонами дистрибутивов
        Puppy(Rus) Linux

Использование:
  pupkg                          запуск графического интерфейса программы
  pupkg команда {параметры}

Команды:
  create дистрибутив.iso         создать «паспорт» дистрибутива из образа
  create имя                     создать «паспорт» текущей системы
  describe пакет                 описать файлы и зависимости пакета pet (sfs)

  find-deps пакет {дистрибутив}  найти нерешенные зависимости для пакета
                                 в указанном (или во всех) дистрибутивах
  find-pkgs пакет {дистрибутив}  найти пакеты, требующиеся для решения
                                 зависимостей
  inspect пакет {дистрибутив}    найти в пакете лишние файлы, имеющиеся
                                 в указанном (или во всех) дистрибутивах,
                                 а также во вспомогательных пакетах
  repack пакет                   перепаковка пакета с удалением лишних файлов

  gen-inst пакет                 сгенерировать скрипт авто-установки
  wiki-page пакет                создать вики-описание пакета
  find-file файл                 найти пакет, содержащий файл
  setup пути_distro libs packs   установка путей расположения описания
                                 дистрибутивов, вспомогательных пакетов
                                 (библиотек) и пакетов. Сохраняется в ~/.pupkg
                                 (при отсутствии файла и настроек, они
                                 устанавливаются по умолчанию)
  recharge                       обновить списки с сервера

  help, --help                   выдать эту справку
  version, --version             выдать информацию о версии

[DdShurick]

2 Lexeii. Я немножко изменил первые две секции скрипта. Смысл от этого не меняется, но запись короче. Хотя я не уверен, что цикл в цикле - хорошо.

[RulllJazzz]

А моя идея может просто загнуться без посторонней помощи. Даже самый навороченный скрипт ничего не значит без сопутствующих баз данных. Файлы, генерируемые скриптом — это базы данных. Во-первых, нужны базы по дистрибутивам. Это потом скрипт будет выдавать отчеты, подходит ли конкретный пакет к конкретному дистрибутиву, есть ли нерешенные зависимости и где найти пакеты для их решения. Во-вторых, нужны базы по пакетам. Как мне кажется, пакеты стоит разделить на основные (содержащие программу) и вспомогательные (содержащие библиотеки и прочие зависимости).

Алексей, конкретизируй. Базы данных по чему конкретно и в каком виде. Если можно, то и рецепт от шеф-повара (сколько варить и чем заправлять  )

[Lexeii]

Рецепт от шеф-повара нечаянно затерялся среди других блюдeй.

Этот рецепт, к сожалению, подходит только для людей действия, не желающих долго раздумывать. Для вторых этой ночью я напишу заметку, и мы сможем вместе поразмышлять как подавать блюдо и под каким соусом.

[Lexeii]

Если говорить о самом распространенном способе установки PuppyRus Linux — Frugal, который является «коньком» PuppyRus, то видно, что дополнительные программы устанавливаются в систему из пакетов формата pet, либо при помощи подключаемых модулей формата sfs.

Для самих программ при Frugal-установке безразлично, находятся ли они в файле сохранения 2fs, либо в файле модуля sfs, поэтому я далее для простоты и pet и sfs буду называть просто пакетами.

Есть пакеты, которые содержат в себе все файлы, необходимые для работы программы, как, например, Opera или Firefox. Есть пакеты, для нормальной работы (или вообще, для работы) которых требуется реализовать некоторые зависимости. Что такое зависимости? В основном, это файлы библиотек с расширением so. Также, это могут быть среды программирования, как Perl или Python. Остановимся на библиотеках, так как с перлами пока не всё ясно. Тут встают два вопроса.

Во-первых, зачем людей мучать этими зависимостями? Не говоря уже о том, что самый ходовой способ распространения свободных программ — в исходных текстах (автор распространяет свою программу, но не будет распространять вместе с ней энное количество исходных текстов других проектов), то тут имеются и другие аспекты, почему так делается. Библиотеки предполагают наличие каких-то полезных функций, готовых решений для открытых проектов, и также предполагают широкое их использование. Библиотеки могут быть статически связаны (когда все исполнимые файлы, библиотеки и прочие файлы находятся в пределах одного пакета) и динамически связаны (когда одни и те же библиотеки могут использовать несколько разных программ). При динамическом связывании экономится как место на жестком диске, так и место в оперативной памяти, так как библиотека, уже загруженная в память одной программой, может без дублирования использоваться любым количеством программ. Для маленьких, легких проектов это актуально. При этом подбирается набор программ, использующих одни и те же библиотеки.

Во-вторых, откуда берутся эти библиотеки? Многие библиотеки уже есть в дистрибутиве «из коробки». В принципе, всем установленным в дистрибутиве программам этого должно хватать (хотя и тут не помешало бы сделать проверку, потому что наши дистрибутивы собираются «на коленке»). Для прочих программ, распространяющихся в виде пакетов, должны существовать пакеты с библиотеками, являющимися их зависимостями. Итак, отметьте на будущее понятия «библиотеки в дистрибутиве», «пакет с программой», «пакет с библиотеками».

Написание данного скрипта началось с реализации чисто утилитарной функции — получить список файлов, находящихся в каком-либо пакете для того, чтобы, не скачивая пакеты, можно было производить по ним поиск. Дальнейшее развитие скрипта было вдохновлено tazpkg — пакетным менеджером дистрибутива SliTaz GNU/Linux — небольшим скриптом, написанным даже не на Bash, а на более простом и ограниченным Ash, реализуемым проектом BusyBox, скриптом, реализующим большое количество полезных функций при работе с пакетами — загрузка, установка, обновление, блокировка обновления, поиски по файлам, описанию и названиям пакетов даже в офф-лайне, синхронизация локальной базы данных по пакетам с сервером, работа с зеркалами и многое другое. Так как пакетный менеджер в PuppyRus уже как бы есть, было решено развивать скрипт в направлении полезных функций для авторов дистрибутивов, сборщиков пакетов и обычных пользователей.

Следующая (после составления списка файлов) и, пожалуй, основная функция скрипта — поиск и реализация зависимостей-библиотек. Идея заключается в следующем. Ведется учет, какие библиотеки уже имеются в каждом из дистрибутивов PuppyRus (и всех, кто к нему присоединился) — это я называю «паспортом» дистрибутива. Такой же учет ведется и в каждом из пакетов библиотек. Каждый из пакетов с программами анкетируется на предмет, какие из библиотек требуются ему для работы (из тех, что не идут в составе этого пакета с программой). Далее сравниваются «спрос» и «предложение» и делаются выводы. Они могут выглядеть так: пакет X не имеет (нерешенных) зависимостей в дистрибутивах A и B, а для работы в дистрибутиве C требуется установить пакеты с библиотеками L и M. Эта информация может быть оформлена в виде вики-странички со ссылками на все необходимые пакеты.

Более того, можно сформировать установочный скрипт, который последовательно сам закачает и установит все зависимости и саму программу. Более того, можно написать универсальный скрипт, пригодный для всех дистрибутивов, который будет искать определенные библиотеки в дистрибутиве (может быть, они уже установлены?) и устанавливать их в случае необходимости, а потом устанавливать саму программу. Этот скрипт должен быть также доступен на вики-странице. Это — полезная функция для пользователей.

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

Теперь для сборщиков пакетов. Реальное тестирование программ на разных дистрибутивах отнимает много времени и может не дать ответов на все интересующие вопросы. Кроме того, следующая функция скрипта — нормализация пакетов. Некоторые сборщики для простоты дополняют пакет с программой всеми необходимыми библиотеками. Как уже было сказано, эти библиотеки уже могут быть в дистрибутиве, либо могут быть установлены в составе другого такого же «простого» пакета. Всё будет работать нормально только до тех пор, пока не будет удален один из пакетов. Кроме удаления самой программы он может повлечь удаление библиотек, использующихся в других «простых» пакетах или в системе по умолчанию. Нормализация пакетов позволит выбросить из них общие библиотеки для исключения конфликтных ситуаций.

Теперь немного о формате информации, с которой работает скрипт. Так сложилось изначально (на основании вывода списка файлов в пакете командой tar), что информация находится в обычном текстовом файле, структура которого позволяет назвать его базой данных. Каждая однородная запись располагается на отдельной строке. Информация внутри строки разделяется пробелами. Такой формат позволяет легко формировать и обрабатывать такие базы данных при помощи циклов, поиска с регулярными выражениями, и отделения во всех строках записи с определенным порядковым номером. Как пример базы данных — вывод команды ls -l содержит в себе атрибуты файла (права доступа), владельца и группу, размер, дату и путь к файлам, разделенные пробелами. При помощи одной лишь команды cut из этой базы данных можно получить список файлов с путями, каждый на новой строке. При необходимости этот формат может быть преобразован в CSV для дальнейшей, внешней обработки.

Таким образом, показано, что для выполнения работы скрипта, необходимы базы данных, которые он будет обрабатывать, а именно — «паспорта» дистрибутивов, список файлов пакетов с библиотеками, список зависимостей пакетов с программами, адреса для закачки пакетов.

[f329]

Во время работы скрипта при обработке некоторых пакетов (например skype-static обоих версий, вылазят следующие ошибки , но позже скрипт успешно завершает работу, и паспортные файлы в порядке и на месте...

[Lexeii]

Во время работы скрипта при обработке некоторых пакетов (например skype-static обоих версий, вылазят следующие ошибки , но позже скрипт успешно завершает работу, и паспортные файлы в порядке и на месте...

Алексей, я видел подобные ошибки и у себя, в некоторых пакетах. Каких-то ответов или решений у меня нету, есть только предположения.

Первое предположение связано с архиватором, при помощи которого пакет был собран в архив, и архиватором, при помощи которого архив пакета распаковывается. Насколько я понимаю, утилита tar распаковывает сама или поручает часть работы (например, распаковка gzip) другим утилитам. Как минимум, есть две версии утилиты tar — та, что реализована в рамках BusyBox и вторая — GNU tar. Сначала я использовал простенький tar из BusyBox и у меня никак не получалось распаковать архивы .tar.gz, которые прикреплял DdShurick к сообщениям в теме про консольный установщик PuppyRus. Приходилось искать обходные пути, сначала распаковывать gzip`ом (хоть и выдавало ошибку, но распаковывало), потом tar`ом. А после того, как я установил пакет с полноценным tar`ом, распаковка стала проходить гладко, без каких-либо ошибок.
Мне кажется, что эти ошибки — не критичные.

Второе — про ошибки утилиты ldd. Это очень своеобразная утилита, и очень хорошо, что она вообще работает и выполняет свои функции. Я уже забыл подробности, но в общих чертах, ldd загружает исполнимый файл, запускает его, но не дает ему работать, выписывает библиотеки, к которым бинарник обращается. А все эти ошибки, символы — это что-то связанное с компиляцией. Я не знаю, нужно ли перекомпилировать бинарник, либо можно просто устроить ему чистку при помощи strip, или что-то третье.

В общем, по этим ошибкам у меня только одно решение — самый лучший способ избавиться от ошибок — это не замечать их, т.к. в результате мы получаем то, что хотим.