Бета для linux deb x64 что это значит

Что такое бета-версия Linux и стоит ли ее пробовать?

За несколько недель или месяцев до выхода новой версии операционной системы на базе Linux, зачастую, появляются её бета-версия. Это дает возможность заранее увидеть, что происходит на конвейере в данный момент.

Но стоит ли вам загружать эти бета-версии?

Что такое бета-версия ОС Linux?

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

Короче говоря, бета-версия – это ПОЧТИ готовый к выпуску продукт.

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

Почему существуют бета-версии

Разработчики выпускают бета-версии по ряду причин. Эти версии дают людям возможность непосредственно протестировать новые функции, которые, возможно, появятся в финальном релизе.

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

Бета-версии предназначены не только для конечных пользователей. Эти итерации предоставляют разработчикам приложений и производителям оборудования возможность протестировать свои программы на следующей версии ОС перед официальным выпуском. Таким образом, программное обеспечение Linux, которое не поставляется разработчиками ОС, может обеспечить надежную работу с первого дня.

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

Кто должен попробовать бета-версии?

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

Но это не единственные причины, по которым люди скачивают бета-версии. Многие устанавливают их просто из любопытства. Это особенно распространено в мире Linux, где людям нравиться “возиться” со своими компьютерами. Вы можете свободно скачать бета-версию ОС на базе Linux, но вам нужно знать чего ожидать.

Чего ожидать от бета-версии Linux

Бета-релизы могут быть интересными. Помимо того, что они дают представление о будущем, они дают возможность узнать больше о процессе разработки Linux. Вот некоторые вещи, о которых нужно помнить, когда вы нажимаете кнопку загрузки.

1. Бета не представляет конечный продукт. Для разработчиков несправедливо говорить, что вы не используете их программное обеспечение, потому что вы опробовали бета-версию, а опыт еще не был стабильным или функциональным.
2. Вещи могут измениться до официального релиза. Хотя бета-версия в значительной степени завершена, это не означает, что все в порядке.
3. Опыт может показаться противоречивым и ненадежным. Элементы интерфейса могут сдвигаться или исчезать без предварительного уведомления. Различные компоненты или вся среда рабочего стола могут самопроизвольно перезагружаться.
4. Некоторые вещи могут не работать вообще. В то время как большинство функций могут быть полезны, разработчики могут сдерживать некоторые функциональные возможности для полной версии, особенно когда задействован облачный сервис.

Часто можно запустить бета-версию ОС на вашем ПК, не сталкиваясь с какими-либо явными проблемами. Возможно, вы слышали, как это делает друг или вы сделали это сами. Все в порядке. Только не думайте, что в следующий раз все пойдет хорошо, потому что в прошлый раз все шло гладко.

Каковы риски бета-версии Linux?

Это справедливый вопрос. Достаточно бета-версий ОС Linux настолько стабильны и надежны, что создают впечатление, что все бета-версии безопасны для использования.

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

Кроме того, переключение обратно на не бета-версию, вероятно, повлечет за собой переустановку ОС с нуля.

Существует также риск для самого проекта Linux. Вы можете сделать преждевременное суждение о рассматриваемой ОС на базе Linux. Вы так же можете повлиять на восприятие других людей ОС на базе Linux, если вы слишком много говорите о своем опыте бета-версии. Они могут не знать, что вы используете экспериментальное программное обеспечение, которое явно не готово для публичного использования.

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

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

Безопасность в бета-версии Linux

Итак, прочитав это, вы решили, что собираетесь загрузить бета-версию ОС Linux. Теперь давайте поговорим о мерах предосторожности, которые вы можете предпринять, чтобы оставаться в безопасности.

1. Установите бета-версию на дополнительный компьютер. Если у вас больше одной машины, на основном компьютере, установите ​​стабильную ОС, а второй компьютер, можно использовать как тестовую машину, без риска потери ваших данных.
2. Запустите бета-версию внутри виртуальной машины. Виртуальная машина запускает симуляцию ПК на вашем компьютере. Все данные на этом виртуальном ПК отделены от ваших данных, что исключает потери. Это безопасный способ опробовать операционные системы Linux, но он не обеспечивает такой гладкой работы, как установка ОС непосредственно на жесткий диск.
3. Сделайте резервную копию ваших данных заранее. Если вы собираетесь установить бета-версию на свой основной компьютер, по крайней мере, убедитесь, что вы сохранили последние копии своих данных в надежном месте.

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

Источник

Еще раз о deb пакетах

Подготовка

Чтобы начать создавать deb пакеты, нужно установить несколько пакетов:

Подготовка папки с исходниками

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

Папка должна называться имяпакета-версия. Т.е. если у меня есть папка Plugins с программой версии 0.1, то я создаю папку с именем plugins-0.1.

Теперь нужно создать архив с этой папкой. Архив должен содержать в имени *.orig.tar.gz, т.е.:

Последний подготовительный шаг, это создание в папке с исходниками папки debian со множеством служебных файлов. Чтобы это сделать, нужно выполнить команду:

В процессе выполнения этой команды будет задан вопрос о том, какой тип архива мы создаем, самый простой это single.

Настройка пакета

Вся настройка пакета происходит путем редактирования файлов в каталоге debian. Рассмотрим те файлы, которые будем использовать:

• changelog — история пакета.
• control — главный конфиг пакета;
• rules — аналог Makefile для пакета;

Кроме этих файлов, в папке debian будет создано много файлов *.ex которые являются примерами для конфигурации различных вещей, но мы не будем их использовать и поэтому их нужно удалить.

changelog

Данный файл содержит историю изменения пакета и текущую версию пакета. Посмотрим на его содержимое:

В начале идет название пакета — libvksplugins, затем его версия. Версия делиться на две части символом «-». Первая часть показывает версию программы в пакете, вторая «ревизию» пакета. Ревизия это версия пакета, т.е. если раньше такого пакета не было, то ревизия равна 1. Если же пакет с такой версией программы уже был, но в нем произошли изменения, то ревизия увеличивается.

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

Надпись urgency=low показывает срочность изменения. Т.к. срочности нет, то значение равно low. Если бы, мы делали пакет для исправления серьезной уязвимости или ошибки, то значение можно было бы установить в high.

После первой строки идет пустая строка, а за ней первая запись:

В Debian, changelog используется для автоматического закрытия ошибок в системах отслеживания ошибок в программных продуктах. Т.к. в данном случае, я не использую такую систему, то эта строка принимает вид:

Последняя строка является подписью человека, сделавшего запись. В ней содержится имя и адрес, а также дата изменения.

После установки deb пакета, файл changelog устанавливается в

control

Файл debian/control является главным конфигом, при создании deb пакета. Вот пример такого файла:

Видно, что файл разбит на секции при помощи пустых строк. Каждая секция описывает один пакет, создаваемый из папки с исходниками. Рассмотрим их по порядку:

Source Данная секция говорит о том, что нужно создать пакет исходных кодов. Параметром указано libvksplugins, это значит, что пакет исходных кодов будет называться libvksplugins.

Priority Эта секция устанавливает приоритет пакета. Т.к. система может прекрасно обойтись без нового пакета, то значение секции установлено в optional. Т.е. этот пакет не обязателен для установки. Подробнее о приоритетах написано здесь.

Maintainer Эта секция описывает контакты человека, создающего пакет. Ее формат довольно прост и дополнительного описание не требует.

Build-Depends Одна из самых важных секций, устанавливающая зависимости пакета. Зависимости, указанные в данной секции должны быть выполнены, чтобы можно было собрать пакет. Т.е. список зависимостей для сборки и установки могут отличаться.

Видно, что в зависимостях стоят debhelper (>= 9), cmake. Зависимость debhelper (>= 9) ставиться для всех пакетов по умолчанию. Она нужна для корректной работы программ вида dh_*.

Второй элемент cmake был добавлен потому, что папка с исходниками содержала файл CMakeLists.txt, т.е. для сборки используется система сборки CMake. Для того, чтобы узнать, какие зависимости есть у программы, можно почитать ее документацию. Кроме этого, можно воспользоваться командой dpkg-depcheck. Данная команда должна запускаться так:

Но, т.к. при использовании CMake нет скрипта конфигурирования, то я использую ее так:

Из примечательных тут можно отметить:

cmake
qt4-qmake
libqt4-dev

Остальные являются зависимостями данных. Причем, cmake уже есть в списке зависимостей сборки. В принципе, можно его оставить как есть или указать используемую версию:

При этом в CMakeLists.txt указана версия cmake, которую нужно использовать:

Я думаю, что разработчику виднее, и поэтому указываю версию из CMakeLists.txt. Для Qt 4 все понятно с номерами версий, но для очистки совести проверим и их версии:

Т.е. для Qt 4 указываем версию 4.8.6:

Standards-Version Версия стандарта, в соответствии с которым создан файл. Это значение не нужно менять.

Section. Секция для пакета, т.е. группа пакетов, выполняющая одну задачу. В Политике Debian разделе 2.4 этот вопрос описан более подробно.

Homepage Домашняя страница проекта. Т.к. данный код писал я и у него нет страницы, просто удаляю эту строку.

Vcs-* Ссылки на репозитории проекта. Их у меня тоже нет, поэтому удаляю эти строки.

Другие пакеты После секции файла, где описывается пакет с исходниками, идут секции, которые описывают другие пакеты, создаваемые из пакета с исходниками. Схема создания пакетов:

Из схемы видно, что из исходников программы, я хочу получить 4 пакета:

• пакет с исходными кодами;
• пакет с бинарником (самой библиотекой);
• пакет для разработки (заголовочные файлы);
• пакет с документацией.

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

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

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

Схема на рисунке выше показывает, что пакет с исходниками называется libvksplugins_source, однако, в файле control указано, что пакет с исходниками будет называться libvksplugins. На самом деле, он действительно будет называться libvksplugins, а пакет с бинарниками, будет называться libvksplugins… deb. Суть этой путаницы в том, что пакет с исходниками представляет собой tar архив и служебные файлы, тогда как пакет бинарников это архив с расширение deb.

Настройка пакета библиотеки Посмотрим внимательно на описание пакета библиотеки:

Package: libvksplugins
Architecture: any
Depends: $, $
Description: Library for creating plugins with VKS 2
This library provides a mechanism for creating plugins
to use in project VKS 2.

Параметр Architecture устанавливает архитектуру собираемого пакета. Значение any означает, что после сборки бинарников нужная архитектура будет подставлена системой сборки. Т.е. на 64х битной машине, получится пакет . _amd64. а на 32х битной пакет . _i386. .

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

Третья строка, описывает зависимости создаваемого пакета. Вот как она описана в 4й главе Руководства начинающего разработчика Debian:

Утилита dh_shlibdeps вычисляет зависимости двоичного пакета от общих библиотек. Она генерирует список исполняемых файлов ELF и общих библиотек, которые находит для каждого двоичного пакета. Этот список подставляется вместо $ .

Утилита dh_perl вычисляет зависимости Perl. Она генерирует список зависимостей от perl или perlapi для каждого двоичного пакета. Этот список подставляется вместо $ .

Некоторые команды пакета debhelper могут добавлять зависимости к вашему генерируемому пакету. Каждая команда генерирует список необходимых пакетов для каждого двоичного пакета. Этот список подставляется вместо
$ .

Утилита dh_gencontrol генерирует файл DEBIAN/control для каждого двоичного пакета, заменяя $ , $ , $ и т.д на полученные значения.

Т.е. эта строка говорит о том, что сборщик пакета сам определит зависимости.

Последний раздел данной секции это описание пакета. Первая строка содержит кратное описание, последующие строки содержат более подробное описание. Подробное описание, должно иметь определенный формат:

• строка должна начинаться с пробела;
• строка не должна быть длиннее 80 символов;
• пустая строка должна начинаться с пробела и состоять из символа точки.

Настройка пакета заголовочных файлов Пакет с заголовочными файлами, будет называться libvksplugins-dev, вот его описание:

Package: libvksplugins-dev
Section: libdevel
Architecture: any
Depends: libvksplugins (= $), $
Description: Development package for libvksplugins
This package provides development files for
library libvksplugins.
.
Also, it contains pkg-config file, to use.

В данном примере, интересна строка Depends. В ней указано, что данный пакет будет зависеть от пакета библиотеки libvksplugins, причем (= $ ) говорит о том, что необходимо строгое совпадение версий бинарного пакета и пакета разработчика. Это важный момент потому, что заголовочные файлы должны строго соответствовать бинарникам.

Настройка пакета документации Вместе с библиотекой поставляется документация, чтобы она была в отдельном пакете, добавляем его описание:

Package: libvksplugins-doc
Architecture: all
Depends: $, $
Description: Documentation for libvksplugins
Package contains html documentation files for libvksplugins

Тут должно быть все понятно.

rules

Данный файл является аналогом Makefile для сборки пакетов. По умолчанию, он создается в таком виде:

Видно, что это bash скрипт с синтаксисом Makefile. Единственная интересная конструкция здесь это

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

Т.к. исходники используют систему сборки CMake, то нужно изменить эту запись следующим образом:

Содержимое пакетов

После того, как мы указали в debian/control какие пакеты мы хотим получить, нужно указать какие файлы в какой пакет помещать. Для этого, для каждого названия пакета из файла control, нужно создать в папке debian два файла. Первый должен называться пакет.dirs, а второй пакет.install. Суть файлов в том, что первый указывает, какие папки нужно создать для пакета, а второй, какие файлы включить в пакет.

Посмотрим на их содержимое:

Важный момент, отсутствие начальной дроби в путях и отсутствие дроби в конце пути к папке. Проверив, куда CMake устанавливает файлы библиотеки, можно сформировать такие файлы:

Завершение настройки

Т.к. исходники мои, то никаких дополнительных описаний и ограничений copyright у меня нет, поэтому я удаляю все лишние файлы из каталога debian.

Сборка пакетов

После настройки, сборка пакетов происходит довольно просто, нужно в папке проекта (которая включает подпапку debian) выполнить команду:

Параметры -us -uc говорят о том, что не нужно подписывать gpg ключом созданные пакеты. Их можно не использовать, если настроен ключ подписи gpg по умолчанию. Как указать ключ подписи по умолчанию, я тоже не понял. Если все прошло хорошо, то у нас поваляется набор пакетов в папке выше:

Заключение

Если вы дочитали до сюда — значит вы любите читать.

Этот текст является результатом моего опыта внедрения deb пакетов на работе. Опыт показал, что наличие сетевого репозитория (reprepro) и внимательное отслеживание версий, позволяют без проблем обновлять и тестировать различные версии ПО на парке из 30 машин с системами Astra Linux 1.3, 1.4 и Эльбрус ОС.

Источник