Xz compressed source tarball что это
Что такое тарболлы Linux и как их использовать?
Согласно Википедии, тарбол – это компьютерный формат файла, который может объединять несколько файлов в один файл, называемый «тарбол», обычно сжатый.
Так как это помогает нам и для чего мы можем их использовать?
В прошлом tar-файлы создавались для хранения данных на лентах, а термин tar обозначает архивный архив на магнитной ленте. Хотя он все еще может использоваться для этой цели, концепция tar-файла – это просто способ сгруппировать множество файлов в один архив.
Каковы преимущества использования Tar-файла?
Причины создания файлов Tar
Файлы tar при сжатии создают хорошие резервные копии и могут быть скопированы на DVD-диски, внешние жесткие диски, ленты и другие мультимедийные устройства, а также в сетевые папки. Используя файл tar для этой цели, вы можете извлечь все файлы из архива обратно в их исходные места, если вам нужно.
Файлы Tar также можно использовать для распространения программного обеспечения или другого совместно используемого контента. Приложение состоит из десятков различных программ и библиотек, а также другого вспомогательного контента, такого как изображения, файлы конфигурации, файлы readme и файлы make. Файл tar помогает сохранить эту структуру вместе для целей распространения.
Недостаток использования файлов Tar
В Википедии перечислены некоторые ограничения для использования файлов tar, которые включают, но не ограничиваются:
Как создать файл Tar
Для создания файла tar вы используете следующий синтаксис:
Это создает tar-файл garybackup со всеми файлами в моей папке с музыкой, изображениями и видео. Полученный файл полностью распакован и занимает тот же размер, что и исходные папки.
Это не очень хорошо с точки зрения копирования по сети или записи на DVD, потому что это займет больше пропускной способности, больше дисков и будет медленнее копировать.
Вы можете использовать команду gzip вместе с командой tar для создания сжатого файла tar. По сути, сжатый tar-файл – это tarball.
Как перечислить файлы в файле Tar
Для получения списка содержимого файла tar используется следующий синтаксис:
Как извлечь файл Tar
Чтобы извлечь все файлы из tar-файла, используйте следующий синтаксис:
А ссылки на source tarball у нас достаточными пруфлинками релиза теперь не являются?
мне просто интересно, а стоит ли вообще переводить changelog из тарболлов и писать свои новости, или можно через несколько дней «написать» не первой свежести копипасту?
>можно через несколько дней «написать» не первой свежести копипасту?
Так вроде многие делают.
Если за такие новости давали бы больше скора чем за обычную копипасту. тогда это бы было оправдано.
мдеее…капец. Что такое релиз — это разве не появление тарболла?
1) мы подтверждаем новости тогда, когда об этом написано на оффсайте или в официальной рассылке, а не сразу после появления тарбола, тега в репозитории и тд
2) ссылку на исходники я убрал потому, что она мне кажется там лишней
> мдеее…капец. Что такое релиз — это разве не появление тарболла?
релиз это когда об этом объявляют разработчики. А тарболл могут еще и заменить, если какой то баг внезапно найдут
значит на будущее, release notes из тарболлов можно не брать и не переводить?
спасибо, больше я свое время тратить не стану, подтверждайте копипасты с опеннета
а я думал, ты меня в игнор загнал 😀
релиз это когда об этом объявляют разработчики.
то есть пока их вебмастер не вышел из запоя, мы без релиза?
А тарболл могут еще и заменить, если какой то баг внезапно найдут
а были ли в истории такие случаи, которые были зафиксированы, что тарболлы подменялись?
Да ладно тебе. Не обижайся.
Один раз Моно удалил мой опрос «почему вы используете линукс на десктопе». Там были разные интересные варианты.
Он просто приравнял его к «каким дистрибутивом вы пользуетесь» Так и написал в причине. С тех пор я и не пишу опросы.
чейнжлог в любом случае не менялся
если можно, у кого такое было (дабы знать, что лучше не обновлять сразу 🙂 )
Лор станет еще более шаблонным.
Шаблонные новости-копипасты.
Шаблонные плоские опросы
(в одном стиле: Какой/каким *** вы пользуетесь? )
вот зачем ты опять в бутылку лезешь. Твоя новость написано хорошо и никуда не делась, ее подтвердят тогда когда будет официальный анонс. Я одного вот понять не могу, что тебе в этот раз не понравилось?
а он разве уже не такой?
это не мое личное решение, мы еще давно договорились стараться не подтверждать раньше анонса
KDEшники традиционно поздно делают анонсы релизов, обычно добирается даже до Дебиан Сид и прочих, не особенно шустрых дистров, а потом в комментариях к новости арчеводы всякие плюются, что уже неделю как обновились
круто, машина времени ЛОРа ушла в прошлое
не сбрасывай Шамана со счетов, он все так же внезапен 🙂
Я понимаю, что вопрос о времени релиза спорный и неоднозначный, но ссылку на исходник удалять не стоит. На сайте опенсорсной тематики.
И в данном случае он прав. ИМХО. У разработчиков, тем более у кедерастов 😉 действительно имеется тьма своих заморочек с анонсированием релиза. И случаи замены тарболла можно по пальцам пересчитать. Тем более, что сюда попадают и замены, произошедшие после официального анонса. Как у OpenOffice от инфры не помню какой версии, когда в выложенных пакетах обнаружились множественные проблемы.
это не моя логика, а общее решение. Подтвержу завтра утром наверное или ближе к обеду
если она там действительно настолько нужна, то я ее верну. Но я правда не вижу смысла давать прямую ссылку на тарбол в данном случае. Может ты объяснишь зачем она там?
Может ты объяснишь зачем она там?
1. Чтоб использовать по назначению: выкачать, почитать, попробовать поставить.
2. Это же пруф новости.
Теперь у деда Бердяя появилась коллега в деле написания кривых новостей и флейма по поводу их преждевременности бабка Сильвия.
походу, они сами не знают, чего хотят
> 1. Чтоб использовать по назначению: выкачать, почитать, попробовать поставить.
ясно, для пользователей лфс короче 🙂 Вернул ссылку обратно
ну пусть сами и пишут, или копипасту подтверждают, мне такой расклад не интересен
покажи мне новостной сайт, где уже висит новость о выходе сабжа
ибо анонс могут написать наркоманы
ссылку удалили
комментарии закрыли
ладно бы висела себе в неподтверженных? зачем надо было удалять ссылку и закрывать для комментариев?
ССЗБ.
Больше ничего на этот сайт не пишу.
> 1) мы подтверждаем новости тогда, когда об этом написано на оффсайте или в официальной рассылке, а не сразу после появления тарбола, тега в репозитории и тд
2) ссылку на исходники я убрал потому, что она мне кажется там лишней
Без нее будут вопросы «а где ж дистр»? Если ни в рассылке, ни на сайте новости нет, ссыль на исходник более чем логична.
Это спорно. В общем и целом, для активно разрабатываемых проектов, по крайней мере, анонсов может и не быть вообще.
How to build Python 3.4.6 from source?
I want to install Python 3.4.6 but it is only available in source code format.
The install options on the official Python website are Gzip’d source tarball and XZ compressed source tarball. I have never installed Python this way before so I don’t know what to do. How do I install Python and what file do I download?
3 Answers 3
You will need Visual Studio 2010 Express, which is becoming increasingly hard to find. See the comments in this question for a link to download it. You can also try Visual Studio Community 2017, which will probably work as well. All that you really need to do is open a solution and click build.
The Python 3.4 branch is in security fixes only mode. This means that only security fixes will be accepted on this branch, no more non-critical bug fixes. New releases on this branch are source-only, no binaries will be provided. See the official announcement.
If you really need a python 3.4.6 binary for windows, you will have to compile it yourself. But if you’re new to python and just want to try or learn python, there’s no reason why you couldn’t use version 3.4.4, or 3.6.x.
Use the latest version
Step 1 – Prerequsiteis Use the following command to install prerequisites for Python before installing it.
Step 2 – Download Python 3.7 Download Python using following command from python official site. You can also download latest version in place of specified below.
Now extract the downloaded package.
Step 3 – Compile Python Source Use below set of commands to compile python source code on your system using altinstall.
Step 4 – Check Python Version Check the latest version installed of python using below command
Как создавать, собирать, устанавливать и использовать пакеты с программами и библиотеками для UNIX-подобных систем
Речь пойдёт о программах и библиотеках для UNIX-подобных систем, распространяемых в виде исходного кода (в том числе в виде тарболлов), написанных обычно на C и C++ (хотя этот же порядок работы может применяться к софту на любом языке). Многие вещи в этой статье написаны применительно конкретно к GNU/Linux, хотя многое из статьи может быть обобщено и на другие UNIX-подобные ОС.
Под словом «пакет» я понимаю в этой статье пакет с исходными текстами, причём не пакет конкретного дистрибутива GNU/Linux, а просто пакет, исходящий от оригинальных авторов софта (UPD от 2017-02-09: кроме тех случаев, где из контекста ясно, что слово «пакет» употреблено в другом смысле).
В этой статье я разберу следующие вопросы:
И ещё одно предупреждение. Я написал эту статью наскоро для одного человека. А после написания подумал, мол, раз уж написал, выложу уж на Хабр, чтоб не пропала. Поэтому в статье есть недочёты типа нечёткого структуирования статьи, фраз типа «не осуществляет сама инклудивание» и пр. Я это исправлять не буду. Может когда-нибудь в следующей жизни, когда руки дойдут. Выбор был между тем, чтобы публиковать так или не публиковать вовсе.
Итак, начнём мы с того, что создадим пакет с программой Hello, world. Для начала определимся с системой сборки.
Собственно, сама сборка пакета обычно осуществляется с помощью программы make (хотя это не единственный путь). Конфиг для make обычно лежит в файле под названием Makefile.
Есть несколько вариантов: просто использовать make либо использовать совместно с make некую высокоуровневую систему сборки (обычно autotools или cmake), которая будет, собственно, генерировать конфиги для make.
Мы в нашем примере будет использовать только make для простоты. Итак, создаём hello.c:
Внимание! Работает на GNU/Linux. Работа под macOS не гарантируется! Этот Makefile не является портируемым вообще на все UNIX-подобные системы! Подробнее будет дальше.
здесь означает символ табуляции.
Это далеко не единственный способ написать этот Makefile. Вообще, цель всей моей статьи — дать некую базу. Что ещё можно в этом Makefile изменить, вы можете потом узнать из других источников.
Итак, теперь давайте разбирать наш Makefile.
Для начала скажу следующее. Допустим, пользователь скачал пакет. Ему нужно сперва собрать его, т. е. получить бинарники в каталоге с самим пакетом (либо в случае out of tree build получить их в неком другом каталоге, что не меняет сути), а затем установить, т. е. скопировать полученные бинарники в место их окончательного хранения в системе.
То есть смотрите. Вы залогинены под юзером user. Ваш домашний каталог /home/user. Вы скачали пакет, распаковали его, скажем в /home/user/Desktop/foo. Далее вы его собрали. Собрали в этой же папке, /home/user/Desktop/foo. Либо, если речь идёт об out of tree build, вы создали ещё одну папку /home/user/Desktop/foo-build и собрали в ней. Теперь, после сборки вы решаете установить её в /usr/local. Вот тут уже вам нужны права root. Вы при помощи sudo устанавливаете эту программу в /usr/local.
Пара слов о размещении каталогов в системе. Разберу лишь некоторые каталоги. Более подробную информацию можно найти в Filesystem Hierarchy Standard (поддержан многими дистрибутивами GNU/Linux) и по команде «man 7 hier» в GNU/Linux и, возможно, других ОС. Во всяком случае я расскажу, как они были устроены, скажем, лет пять назад (т. е. где-то в 2012-м году), всякие новые веяния типа недавнего нововведения в Fedora «давайте-ка мы всё переместим в /usr» я рассматривать не буду.
То есть, например, вы устанавливаете пакет, указывая ему prefix /usr/local. Тогда бинарники пойдут в /usr/local/bin, бинарные файлы библиотек — в /usr/local/lib и так далее.
Теперь вернусь к разбору Makefile. PREFIX — это и есть тот prefix, про который я сейчас говорил. В качестве дефолтного префикса (пользователь сможет его переопределить) у нас указан /usr/local — хороший дефолтный выбор. Обычно его всегда указывают в качестве дефолтного префикса при создании пакетов (к сожалению, некоторые пакеты этого всё же не делают, дальше будет подробнее). Далее идёт CC. Это стандартное название для переменной make, в которую кладут компилятор, в данном случае cc. cc — это в свою очередь обычно используемая команда для запуска компилятора по умолчанию в данной системе. Это может быть gcc или clang. На некоторых системах команда cc может отсутствовать. CFLAGS — стандартное название для переменной с флагами компиляции.
Если просто набрать make, то будет выполнена та цель, которая идёт в Makefile первой. Обычная практика в том, чтобы называть её all. И такая цель обычно собирает весь проект, но ничего не устанавливает. Эта цель обычно «виртуальная», т. е. у нас нет файла под названием all. Т. к. наша задача собрать лишь один бинарник hello, то мы просто делаем all зависящим от hello. Далее идёт описание цели сборки hello. Его можно было в принципе разбить на два этапа: сборка hello.o из hello.c и сборка hello из hello.o. Я так делать не стал для простоты.
Что делает install? Это почти то же, что и cp. Точные отличия я и сам не знаю. Для установки программ нужно использовать install, а не cp.
Здесь я предполагаю, что у вас на системе установлен так называемый BSD install. В GNU/Linux’е он есть. В некоторых системах его может не быть. Может быть какой-нибудь другой install, который в этой ситуации не сработает. Именно это я имел в виду, когда сказал, что работа в разных ОС не гарантируется.
Здесь я не рассматривал DESTDIR, который, между прочим, крайне рекомендуется использовать в Makefile. Я даже не рассматривал цель clean.
Это создаст архив, внутри которого есть каталог hello-1.0, который содержит hello.c и Makefile. Таков способ распространения пакетов.
C++-вариант пакета. Исходник будет тем же, его нужно будет назвать hello.cpp. Makefile будет таким:
Обратите внимание, что стандартное название переменной для флагов к компилятору C++ — это CXXFLAGS, а не CPPFLAGS. CPPFLAGS же — это название переменной для флагов к препроцессору C.
Теперь разберём, как устанавливать пакеты из сорцов (любые, программы и библиотеки). Независимо от системы сборки. Этот алгоритм будет пригоден в том числе для тарболла, который мы создали только что. Допустим, что пакет, который нужно собрать, тоже называется hello.
Первый шаг: скачать и зайти в папку с сорцами. Тут два варианта: скачиваем из системы контроля версий (я разберу для примера git) или скачиваем тарболл.
Первый вариант. git. Делаем clone:
Теперь нужно собрать. Будем считать для простоты, что мы не будем делать out of tree build (если автор пакета требует out of tree build, там обычно будут написаны инструкции, как это сделать). А значит, собирать мы будем в этой же папке, где сорцы. Т. е. в этой папке, в которую мы сейчас сделали cd.
Дальнейшие действия зависят от системы сборки, выбранной в проекте. Но независимо от системы сборки мы в процессе сборки должны будем указать prefix. Причём обычно его нужно будет указать именно на этапе сборки, а не на этапе установки, т. к. часто prefix захардкоживается внутрь бинарника. А это значит, что после установки программы в определённое место её нельзя просто так взять и передвинуть.
Я дам здесь примерные инструкции, работающие в большинстве случаев. Точные инструкции вы увидите у автора проекта, там могут быть разные нюансы.
Обязательно указывайте prefix при сборке (что бы там не писал в инструкции автор). Если вы не укажите, то будет выбран дефолтный. Обычно это /usr/local, и это достаточно хороший выбор. А если нет? Что если автор пакета указал какой-то другой дефолтный префикс? Вы установите непонятно куда. В частности libqglviewer использует в качестве дефолтного префикса /usr, что совершенно неправильно (я отправил автору баг репорт). Итак, совершенно всегда указывайте префикс. Читайте инструкции, которые автор указывает на своём сайте и прикидывайте, куда впихнуть prefix.
Итак, какие могут быть системы сборки. Во-первых, может быть просто make. Такой вариант с голым make встречается редко. Один из немногих пакетов с «голым» make — bzip ( www.bzip.org ). В случае с нашим hello-1.0.tar.xz, который мы создали, у нас именно такой вариант.
Итак, собирать в случае голого make нужно так:
(Конкретно в случае с bzip на этапе сборки указывать PREFIX не надо. Но теоретически можно представить себе пакет, который захардкоживает PREFIX внутрь бинарника. Поэтому в общем случае PREFIX нужен.)
Следующий вариант — это autotools. В этом случае собираем так:
Следующий вариант — cmake. Собираем так (обратите внимание на точку в конце команды cmake):
Откуда точка в конце? Дело в том, что cmake’у нужно передавать путь к сорцам. А поскольку у нас не out of tree build, мы собираем здесь же. Сорцы находятся там же, где находимся мы. Поэтому точка, т. е. текущий каталог.
Итак, собрали одним из этих способов. Что дальше? Теперь нужно установить.
В случае голого make это делается так:
Нужно будет указать тот же prefix, который вы указывали при сборке.
В случае autotools и cmake так:
В случае, если для записи в prefix вам нужен sudo, то вот эту команду для установки нужно будет набирать с sudo. Вообще, сборка всегда осуществляется с обычными правами, а вот установка осуществляется с теми правами, которые нужны, чтобы записать в prefix.
В результате бинарник положился в /foo/bin.
Теперь хочу ещё немного поговорить про префиксы. Какие префиксы вообще есть?
Префикс /. Вряд ли когда-нибудь вам придётся его выбирать. Он используется для программ, критичных для ранних стадий загрузки ОС (т. е. критичные элементы для загрузки находятся в /bin, /lib и т. д.) (впрочем, даже если вам нужно установить программу в /, её сперва устанавливают в /usr, т. е. собирают и устанавливают с префиксом /usr, а потом перемещают необходимое в / [т. е. перемещают из /usr/bin в /bin, скажем], во всяком случае именно так поступают авторы Linux From Scratch 7.10 с пакетом, скажем, bash).
Префикс /usr. Стандартный префикс, используемый обычно для программ, установленных через менеджер пакетов. То есть если вы установили программу через менеджер пакетов, она ведёт себя так, словно она собрана и установлена на вашей системе с префиксом /usr. Самому устанавливать пакеты с префиксом /usr нельзя.
Префикс /usr/local. Отличный префикс для установки туда программ самостоятельно. Хорош тем, что /usr/local/bin есть в дефолтном PATH (во всяком случае в дебиане). То есть сразу после установки программы вы сможете просто запускать программу по названию. Потому что бинарник лежит в /usr/local/bin, а /usr/local/bin есть в PATH. Плох тем, что там все программы лежат смешанно. Вот допустим, вы установили библиотеку foo, а потом библиотеку bar. Обе в этот prefix. Тогда дерево может выглядеть так (в совсем упрощённом виде):
Видите? Всё смешано. Нет единой папки, которая бы содержала «всё, связанное с foo» и другой папки, которая бы содержала «всё, связанное с bar». (Хотя это ваше дело, считать, что это действительно плохо или нет). Понятное дело, что такая же проблема присутствует при любой установке разных пакетов в один префикс. То есть префикс /usr страдает от того же: пакеты «размазаны» по системе (здесь уже речь идёт о пакетах, поставленных через менеджер пакетов, т. е. тех, которые, собственно, составляют систему). Собственно, это и есть одно из бросающихся отличий большинства UNIX-подобных систем от Windows. В Windows каждая программа находится в своей папке в Program Files. В большинстве UNIX-подобных систем она «размазана» по системе. (UPD от 2017-02-09: в Windows программы на самом деле тоже «размазаны», скажем, по реестру, просто это не так бросается в глаза.) Существуют дистибутивы GNU/Linux, «решающие» эту проблему, например, GoboLinux. Там каждый пакет в своём каталоге, как в Windows.
Префиксы вида /opt/XXX. Папку /opt предполагается использовать следующим образом: в ней нужно создавать подкаталоги, называть их названиями пакетов и использовать эти подкаталоги как префиксы. При таком подходе указанная выше проблема /usr/local (если считать её проблемой) исчезает. Каждый пакет будет установлен в свой каталог. Приведённый выше пример с foo и bar будет выглядеть так (я бы посоветовал в названии подкаталогов в /opt указывать ещё и номер версии):
Недостаток у такого решения тоже есть. Вам придётся самому добавлять все эти бесчисленные каталоги /opt/foo-1.0/bin (для каждого пакета) в PATH.
Префиксы, соответствующие домашним каталогам. Т. е., скажем, /home/user. Советую в случае, когда хочется поставить «только для себя», т. е. только для одного юзера. Или когда нет прав root. Возможно, ваши конфиги, поставляемые с ОС уже настроены таким образом, чтобы помещать
/bin в PATH при условии, что такой каталог есть. Так что PATH будет настроен как надо.
Каждый префикс может содержать в себе свои bin, sbin, lib, include и т. д.
Итак, что из этого выбрать? Если нужно поставить на всей системе, то я бы посоветовал /opt/XXX. Я сам так обычно ставлю.
Допустим, нужно собрать некий файл a.c с этой библиотекой. Как это сделать?
Во-первых, вверху файла нужно написать #include, соответствующий подключаему хедеру. Ну а собирать нужно так:
Давайте разбираться. Для начала скажу, что I (большая английская и) и l (маленькая английская эль) — это две разные буквы. Не перепутайте их в приведённых командах.
Первая команда производит компиляцию, то есть создаёт a.o на основе a.c. Вторая — линковку, то есть окончательный бинарник на основании a.o.
Можно соединить две наши команды в одну, тогда будет что-то такое:
Если вы установите у себя на машине libfoo и libfoo-dev, то результат будет как если бы вы сами собрали пакет foo из исходных кодов с префиксом /usr. У вас на системе будут, скажем, файлы: