Linux get lib arch

Official repositories (Русский)

Репозиторий — хранилище пакетов программ, которые можно загрузить и установить на компьютер.

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

Пакеты в официальных репозиториях постоянно обновляются, при этом старые версии пакетов сразу удаляются. В Arch нет главных (major) релизов дистрибутива: каждый пакет обновляется сразу после того, как его новая версия становится доступна в upstream. Каждый репозиторий полноценен в том смысле, что содержит в себе совместимые между собой версии программ.

Contents

Стабильные репозитории

Этот репозиторий можно найти в каталоге . /core/os/ на каждом из доступных зеркал.

core содержит пакеты для:

• Загрузки Arch Linux
• Подключения к интернету
• Сборки пакетов
• Управления и восстановления поддерживаемых файловых систем
• Процесса установки системы (например, openssh )

а также все необходимые зависимости этих пакетов (необязательно из makedepends) и мета-пакета base .

core имеет достаточно строгие требования к качеству. Разработчики/пользователи должны подтвердить (в ответ на signoff-запрос в почтовой рассылке) работоспособность обновлений, прежде чем они будут приняты. Для малоиспользуемых пакетов обычно достаточно следующих шагов: информирование пользователей об обновлении, запрос подтверждений, удержание пакета в #testing около недели (в зависимости от серьёзности изменений), отсутствие серьёзных баг-репортов и неявное подтверждение от мейнтейнера пакета.

extra

Этот репозиторий можно найти в каталоге . /extra/os/ на каждом из доступных зеркал.

extra содержит все пакеты, которые не подходят для core. Например: Xorg, оконные менеджеры, веб-браузеры, медиаплееры, инструменты для работы с языками, такими как Python и Ruby, и многое другое.

community

Этот репозиторий можно найти в каталоге . /community/os/ на каждом из доступных зеркал.

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

multilib

Этот репозиторий можно найти в каталоге . /multilib/os/ на каждом из доступных зеркал.

multilib содержит 32-битное программное обеспечение и библиотеки, которые можно использовать для запуска и сборки 32-битных приложений на 64-битных системах (например, wine , steam и т.д.).

32-битные библиотеки хранятся в директории /usr/lib32/ при включённом репозитории multilib.

Включение multilib

Раскомментируйте раздел [multilib] в /etc/pacman.conf , чтобы включить репозиторий multilib:

Затем обновите систему и установите необходимые multilib-пакеты.

Отключение multilib

Выполните следующую команду, чтобы удалить все пакеты, установленные из репозитория multilib:

Если вы столкнулись с конфликтами с gcc-libs, переустановите пакет gcc-libs и группу base-devel .

Закомментируйте раздел [multilib] в /etc/pacman.conf :

Тестовые репозитории

Тестовые репозитории предоставляют площадку для размещения пакетов перед принятием их в основные репозитории. Сопровождающие пакетов (и широкая аудитория) могут получить доступ к тестовым пакетам, чтобы убедиться в отсутствии проблем при работе с новой версией приложения. Пакет может быть перемещён в основные репозитории, как только он был протестирован и ошибок не было обнаружено.

Требование тестирования пакетов в таких репозиториях обязательно только для пакетов из репозитория core и пакетов, затрагивающих множество других программ (например, perl и python ), а также обычно применимо к большим коллекциям ПО, например, GNOME или KDE.

testing

Этот репозиторий можно найти в каталоге . /testing/os/ на каждом из доступных зеркал.

testing содержит пакеты, являющиеся кандидатами на внесение в репозитории core и extra.

Новые пакеты попадают в testing в следующих случаях:

• Они предназначены для репозитория core. Все пакеты для core сперва должны пройти через testing.
• Есть вероятность того, что они повредят что-либо при обновлении, в следствие чего их необходимо сперва протестировать.

testing — единственный репозиторий, в котором могут быть совпадения имён с другими официальными репозиториями. Если он включён, он должен быть первым репозиторием среди перечисленных в файле /etc/pacman.conf .

community-testing

Этот репозиторий похож на репозиторий testing, но создан для пакетов, являющихся кандидатами на внесение в репозиторий community.

multilib-testing

Этот репозиторий похож на репозиторий testing, но создан для пакетов, являющихся кандидатами на внесение в репозиторий multilib.

gnome-unstable

Этот репозиторий содержит пакеты с будущим релизом (или кандидатом в релиз) окружения рабочего стола GNOME до их перевода в главный репозиторий testing.

Добавьте нижеприведенные строки в файл /etc/pacman.conf , чтобы включить данный репозиторий:

Репозиторий gnome-unstable должен быть первым в списке репозиториев (в том числе выше записи для репозитория testing).

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

kde-unstable

Этот репозиторий содержит самую свежую бета-версию или версию-кандидат на выпуск KDE Plasma и Applications.

Добавьте нижеприведенные строки в файл /etc/pacman.conf , чтобы включить данный репозиторий:

Репозиторий kde-unstable должен быть первым в списке репозиториев (в том числе выше записи для репозитория testing).

Отключение тестовых репозиториев

Если вы ранее включили тестовые репозитории, а теперь решили их отключить, необходимо:

1. Удалить (закомментировать) их из файла /etc/pacman.conf .
2. Выполнить pacman -Syuu , чтобы «откатить» обновления из этих репозиториев.

Второй пункт необязателен, но помните об этом на случай, если вы заметите какие-либо проблемы.

Репозитории Staging

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

См. [1] для получения информации об исторических деталях.

Историческая справка

Разделение репозиториев появилось по историческим причинам. Когда дистрибутивом не пользовалось много людей, был только один репозиторий, известный как official (нынешний core). В то время official содержал в основном приложения, которые предпочитал Джадд Винет (Judd Vinet — основатель Arch Linux). Репозиторий был устроен таким образом, чтобы содержать «всего по одному»: одно окружение рабочего стола, один основной браузер и т.д.

Конечно, были пользователи, которым не нравился выбор Джадда, и, когда появилась удобная система сборки пакетов, они начали создавать собственные пакеты. Эти пакеты вошли в репозиторий unofficial и поддерживали их другие разработчики, а не Джадд. В конце концов, разработчиками было принято решение поддерживать оба репозитория, и названия official и unofficial перестали отображать их истинный смысл. Примерно в районе версии 0.5 названия были изменены на current и extra.

Вскоре после выхода версии 2007.8.1, current был переименован в core, чтобы не было неоднозначностей в трактовке того, что, собственно, должен содержать репозиторий. Сейчас репозитории практически равны в глазах разработчиков и сообщества, но core имеет некоторые отличия. Самое главное из них — то, что только пакеты из core включаются в установочные CD и релизы. Этот репозиторий все ещё содержит полноценную систему Linux, однако, скорее всего, это не та система, которую вы хотели бы использовать.

Примерно между версиями 0.5 и 0.6 обнаружилось, что есть большое количество пакетов, которые разработчики не хотели поддерживать. Джейсон Чу (Jason Chu) создал неофициальные «Репозитории Доверенных Пользователей» (Trusted User Repositories), где доверенные пользователи могли размещать созданные ими пакеты. Также существовал репозиторий staging, из которого пакеты могли быть перенесены в официальные репозитории одним из разработчиков Arch Linux, но, если не считать этого пункта, разработчики и доверенные пользователи были практически равны.

Такое разделение работало до тех пор, пока доверенным пользователям не надоело поддерживать собственные репозитории, а обычные пользователи не захотели выкладывать свои пакеты. Это привело к развитию AUR. Доверенные пользователи объединились в меньшую по размеру группу, которая сейчас поддерживает репозиторий community. Доверенные пользователи все ещё образуют отдельную от разработчиков Arch Linux группу и довольно мало общаются между собой. Тем не менее, популярные пакеты время от времени все ещё перемещают из community в extra. AUR позволяет также обычным пользователям выкладывать свои файлы PKGBUILD.

После того, как однажды ядро из репозитория core поломало множество систем, в репозитории была введена политика подтверждения («core signoff policy»). С тех пор все обновления пакетов для core должны сперва пройти через репозиторий testing и только после нескольких подтверждений («signoffs») от других разработчиков пакет можно перенести. Через какое-то время было замечено, что некоторые пакеты в core почти не используются, а число подписей пользователей и отсутствие отчётов об ошибках неофициально стали критерием для утверждения таких пакетов.

В конце 2009 и начале 2010, в связи с созданием новых файловых систем и желанием поддерживать их при установке, а также осознанием того, что репозиторий core никогда не был чётко структурирован (просто «важные пакеты, выбранные разработчиками»), назначение репозитория было сформулировано более точно.

Источник

Arch Linux User Repository

Search Criteria

Package Details: libselinux 3.2-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/libselinux.git (read-only, click to copy)
Package Base:	libselinux
Description:	SELinux library and simple utilities
Upstream URL:	https://github.com/SELinuxProject/selinux
Keywords:	selinux
Licenses:	custom
Groups:	selinux
Conflicts:	selinux-usr-libselinux
Provides:	selinux-usr-libselinux=3.2-1
Submitter:	Siosm
Maintainer:	IooNag
Last Packager:	IooNag
Votes:	116
Popularity:	0.006971
First Submitted:	2013-11-03 20:05
Last Updated:	2021-07-03 14:39

Dependencies (9)

• pcre (pcre-svn)
• libsepol>=3.2
• pkgconf (pkgconf-git) (make)
• python (python-dbg, python35, python38, python36, python310, python311, python37) (make)
• ruby(make)
• swig (swig-git) (make)
• xz (xz-git, xz-static-git) (make)
• python (python-dbg, python35, python38, python36, python310, python311, python37) (optional) – python bindings
• ruby(optional) – ruby bindings

Required by (51)

• aide-selinux
• audiobookconverter-bin
• authselect
• cajviewer-bin
• casync
• coreutils-selinux
• cronie-selinux
• dbus-docs-selinux(make)
• dbus-selinux(make)
• findutils-selinux
• glib2-selinux(make)
• glib2-selinux(optional)
• glib2-selinux-docs(make)
• iproute2-selinux
• iris-temperature
• libsemanage
• libvirt-sandbox
• logrotate-selinux
• lxc-selinux
• mathematica(optional)
• matlab
• matlab(make)
• matlab-support(optional)
• mcstrans
• mdatp-bin
• moonpanoramamaker
• nbdkit(optional)
• oddjob(make)
• oddjob-selinux (requires selinux-usr-libselinux)
• openssh-selinux
• pam-selinux
• podman-git(optional)
• psmisc-selinux
• python-blivet(check)
• python-blivet-git
• restorecond
• sepolgen
• setools
• setools3-libs
• sudo-selinux
• systemd-libs-selinux
• systemd-libs-selinux(make)
• systemd-resolvconf-selinux(make)
• systemd-selinux(make)
• systemd-sysvcompat-selinux(make)
• util-linux-libs-selinux
• util-linux-libs-selinux(make)
• util-linux-selinux(make)
• xperia-flashtool
• xperia-flashtool-git
• xplor-nih

Sources (2)

Latest Comments

bred commented on 2020-03-03 08:37

@IooNag Ok, thanks

But considering that pkgconf is not so frequently used, maybe is better if you add it in the makedepends.

IooNag commented on 2020-03-03 08:10

@bred Yes, pkgconf needs to be installed before building this package, as well as make, gcc (for a C compiler). All these packages are in group base-devel, which is always required for AUR packages.

bred commented on 2020-03-03 07:49

It seems that the package «pkgconf» is a mandatory dependency for building «libselinux».

After the installation of «pkgconf» it has compiled correctly.

IooNag commented on 2020-03-02 21:07

@bred : What version of package pcre have you installed? What is the output of «pkg-config —libs libpcre» (this is the command which is used to normally insert «-lpcre» in the command line that failed)?

bred commented on 2020-03-02 13:11

I’ve this error during the linking: (pcre is installed!)

tallero commented on 2020-02-17 00:39

You are of course still free to work on package libselinux-python2 and backport bug fixes that could happen in libselinux’s Python bindings.

I am not that interested, too. I just needed an easy-to-use tool and someone adviced system-config-users. It seemed natural to me to package it, even if arch is slowly deprecating all python2-* packages.

If someone will ever want to use it in the future (for whatever reason) now can do it easily (because PKGBUILDs won’t be lost even when SELinux will end support).

I did this for screem, too.

IooNag commented on 2020-02-12 21:00

@tallero: it seems that system-config-users could be installed on RHEL/CentOS 7, but not on CentOS 8 according to https://unix.stackexchange.com/questions/547437/centos-8-system-config-users. Moreover this question suggests using Cockpit instead, which has already been packaged for Arch Linux (https://www.archlinux.org/packages/community/x86_64/cockpit/).

Anyway, if you want to fork/adopt system-config-users and maintain it on https://gitlab.com/tallero/system-config-users, that’s nice. Nevertheless I do not want to maintain a libselinux-python2-v3.0 package because this version is not supported upstream (by SELinux developers) and the future releases of libselinux are likely to break Python 2 compatibility. This is a matter of personal choices in the way I define how I spend my time. You are of course still free to work on package libselinux-python2 and backport bug fixes that could happen in libselinux’s Python bindings.

tallero commented on 2020-02-12 17:56

@IooNag: I agree with you. In any case libselinux-python2 packages just bindings and until the tool has not been replaced/ported to pygobject (if ever) it could simply stabilize on 3.0. This was packaged because of this question. Can’t find the original git repo, only tarballs, check this.

IooNag commented on 2020-02-12 07:46

tallero : is system-config-users maintained? The upstream of this project (Red Hat) seems to no longer maintain it (and the RPM seems not to exist for «recent» releases such as CentOS 8 or Fedora 31 on https://rpmfind.net/linux/rpm2html/search.php?query=system-config-users).

If system-config-users is no longer maintained upstream, I do not want to spend time to support libselinux-python2, for the sake of using old software for which bugs will never be fixed upstream.

tallero commented on 2020-02-11 22:17

@IooNag: I know of Python 2.x EOL; the library (same tar of this package) can still produce 2.x bindings. The software that needs it is system-config-users, the users/groups GUI manager included in Red Hat/CentOS 7.x.

Copyright © 2004-2021 aurweb Development Team.

AUR packages are user produced content. Any use of the provided files is at your own risk.

Источник