Verification: a143cc29221c9be0

Packages php available but not installed

Packages php available but not installed

error: Installed (but unpackaged) file(s) found

Ошибка означает, что в новой версии пакета появились новые файлы, отсутствующие ранее, и rpmbuild не знает, что с ними делать (и нужны ли ли вообще).

Если вы полагаете, что эти файлы нужны (а это так в 99.9% случаев), необходимо добавить их в секцию %files spec-файла. Если у вас есть несколько подпакетов, то надо сначала определить - к какому из них эти файлы относятся. Универсального рецепта здесь нет, однако есть несколько правил:

  • файлы в директориях /usr/include, /ust/lib(64)/pkgconfig, добавляются в devel-пакеты
  • файлы библиотек в директориях /lib(64) и /usr/lib(64), оканчивающиеся на суффикс .so (например, libfoo.so), также добавляются в devel-пакеты
  • файлы библиотек в директориях /lib(64) и /usr/lib(64), оканчивающиеся на цифру (например, libfoo.so.1), добавляются в пакеты с соответсвующими библиотеками. Согласно правилам РОСЫ, каждая библиотека должна упаковываться в отдельный подпакет, соотевтсвующий ее имени и значению SONAME (как правило, это цифра после суффикса .so - так что файлы libfoo.so.1 и libfoo.so.1.2 должны находиться в пакете lib(64)foo1). Часто ошибка "Installed but unpackaged files found) в пакетах с библиотеками вызвана изменением значения SONAME - например, вместо libfoo.so.1 в новой версии пакета появился файл libfoo.so.2. В этом случае вы также дополнительно увидите ошибку "Cannot find file or directory", сообщающую, что отсутсвует файл libfoo.so.1. Для исправления сборки в такой ситуации достаточно изменить значение макроса major в начале spec-файла:
%define major 2

Помните, что при добавлении файлов в секции %files принято заменять некоторые стандартные пути макросами (например вместо /usr/lib и /usr/lib64 необходимо использовать макрос %{_libdir}, вместо /usr/share/man - %{_mandir} и так далее). Более полный список можно посмотреть с скрипте из Updates Builder.

File not found

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

  • в новой версии действительно нет таких файлов - в этом случае надо просто убрать их описание из секции %files
  • в новой версии файлы переименованы либо перемещены в другое место. В этом случае вы также увидите ошибку "Installed (but unpackaged) file(s) found", как в случае с библиотеками (см. выше). В случае с библиотеками для исправления сразу обеих ошибок необходимо изменить значение переменной major в начале spec-файла. В общем же случае необходимо исправить секцию %files, чтобы она соответсвовала новым реалиям.
  • отсутсвующие файлы собираются или не собираются в зависимости от параметров окружения и сборки - опций компиляции или установленных в сборочной среде пакетов (описанных в BuildRequires). Возможно, в новой версии пакета надо использовать какие-то новые опции сборки либо добавить дополнительные сборочные зависимости для получения этих файлов. Выявить такие ситуации можно на основе анализа журналов сборки и вывода команд наподобие configure или cmake, которые сообщают, какие опцилнальные возможности будут включены при сборке, а какие - нет. Например, squid может собираться с поддержкой аутентификации SASL и без нее. В первом случае в пакете будет присутсвовать файл basic_sasl_auth, во втором его не будет. Для ключения/отключения SASL необходимо добавить/удалить значение SASL из параметра --enable-auth-basic команды configure, а также добавить сборочную зависимость (BuildRequires) от sasl-devel.

Помните, что при добавлении файлов в секции %files принято заменять некоторые стандартные пути макросами, а также что при описании файлов в секции %files могут использоваться символы '?' и '*' (означающие один произвольный символ и любое количество произвольных символов соответсвенно).

cp: cannot stat '': No such file or directory

Ошибка означает, что rpmbuild не смог найти файл , помеченный как %doc в секции %files вашего пакета. Возможно, этот файл был переименован (в этом случе вы также увидите ошибку "Installed (but unpackaged) file(s) found") - в этом случае надо изменить имя файла на новое (например, README могут переименовать в README.md). Если неупакованного файла с близким именем не появилось, то значит старый файл в новой версии отсутсвует и его определение в %doc необходимо просто удалить.

Reversed (or previously applied) patch detected

Ошибка означает, что применявшийся к старой версии пакета патч по крайней мере частично уже применен в новой версии. Обратите внимание, что команда patch делает такой вывод на основе попытки применить только первую часть патча! Если патч сложный и затрагивает несколько файлов или несколько мест одного файла, то необходимо вручную проверить, какие из этих изменений уже есть в новой версии, а каких нет. Для этого можно попробовать применить патч к новой версии вручную, отвечая "n" на вопрос "Assume '-R'" и "y" на предложени продолжить применять остальные части патча.

Если все изменения из патча действительно уже присутсвуют в новой версии, то патч можно спокойно удалить (физически из Git-репозитория, а также из spec-файла). Если же нет, то необходимо определить - нужны ли в новой версии оставшиеся изменения и если да, то переделать патч соответствующим образом. Такой анализ уже требует некоторых познаний в том, что именно делает патч.

/var/tmp/rpm-tmp.xxxxx: line yy: cd: : No such file or directory

Ошибка означает, что rpmbuild не может определить, в какую директорию ему перейти после распаковки архива с исходным кодом. Имя директории указывается в опции -n макроса %setup в секции %prep. Если эта опция отсутсвует, то подразумевается использование "-n %{name}-%{version}". Для исправления ошибки необходимо посмотреть, как расположены файлы в новой версии архива с исходным кодом - обычно такой архив содержит директорию вида "-", но время от времени разработчики могут что-то изменять (например, переименовывать директорию просто в . Для исправления ошибки необходимо соответсвующим образом исправить значение опции "-n" макроса %setup.

empty-debug-info и debuginfo-without-sources

Ошибки означают, что rpmbuild не смог должным образом сформировать подпакет с отладочной информацией. Две основные причины такого поведения:

  • в пакете нет исполнимых файлов или библиотек. Если в пакете при этом вообще нет архитектурно-зависимых файлов (т.е. пакеты для разных архитектур имею абсолютно одинаковое содержимое), то необходимо объявить пакет как независимый от архитектуры, добавив в заголовок spec-файла декларацию "BuildArch: noarch". Если же архитектурно-зависимые файлы все-таки есть (например, какие-то данные могут быть специфичны для каждой арзитектуры; другой типичный пример - проприетарное приложение, которое уже поставляется в виде бинарных файлов бех отладочной информации), то необходимо отключить генерацию debug-пакетов, сбросив определение макроса debug_package в начале spec-файла:
%define debug_package %{nil}
  • скрипты сборки приложения в пакете устроены таким образом, что сразу удаляют отладочную информацию из собранных файлов (например, явно вызывают команду strip либо просто не передают опцию "-g" компилятору). В таких случаях необходимо посмотреть, как заставить скрипты сборки оставить отладочную информацию. Иногда этого можно добиться с помощью переменных среды, а иногда может потребоваться патч, изменяющий сборочные скрипты. Если никакие способы не помогают, то можно отключить генерацию debug-пакетов, как описано выше, но делать так не рекомендуется - эти пакеты очень полезны для анализа ошибок в случае падений приложения.

Остановимся подробнее на втором пункте. Большинство приложений позволяют настраивать передаваемые компилятору опции при старте сборки - например, при вызове configure или cmake. Для генерации отладочной информации для подобных приложений вам не нужно прилагать особых усилий - достаточно вместо прямого вызова configure или cmake использовать соответствующие макросы rpm (в нашем примере - %configure2_5x или %cmake соответственно). Если использование макросов не помогает (либо в проекте не используются стандартные средства типа GNU Autotools или CMake), необходимо изучить схему сборки и посмотреть - нельзя ли на нее повлиять как-то еще - например, специфическими опциями либо переменными окружения. Типичными переменными, которые могут повлиять на сборку, являются CFLAGS, CXXFLAGS и CPPFLAGS. Мы рекомендуем выставить эти переменные в макрос %optflags; при этом может оказаться необходимым перед использованием %%optflags вызвать макрос %%setup_compile_flag (например так сделано в пакете [slock].

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

Бывают ситуации, когда повлиять на сборку извне нельзя никак - в скриптах сборки или файлах типа Makefile инструкции сборки "забиты" намертво. В таких случаях необходимо подготовить патч, добавляющий во все вызовы компилятора опцию -g. Помимо опции -g у компилятора, повлиять на отладочную информацию может компоновщик - например, его опции -s и -S, удаляющие подобные данные из результирующих бинарных файлов. Если такие опции явно передаются компоновщику в скриптах сборки либо файлах Makefile, то необходимо подготовить патч, убирающий их - например, так сделано в пакете [kicad].

Error: Can't locate Some/Perl/Module.pm in @INC

Ошибка означает, что для сборки необходим Perl-модуль Some/Perl/Module.pm, который не был обнаружен в сборочном окружении.

Для исправления ошибки необходимо добавить сборочную зависимость от такого модуля в spec-файл:

BuildRequires: perl(Some::Perl::Module)

Предварительно необходимо убедиться, что такой модуль вообще существует - попробовать его установить с помощью dnf (в rosa2019.1 и новее) либо urpmi (в rosa2016.1):

# dnf install 'perl(Some::Perl::Module)'
# urpmi 'perl(Some::Perl::Module)'

Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с модулем в репозитории РОСЫ.

Обратите внимание, что необходимый модуль может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый модуль необходимо перенести в репозиторий Main.

Package(s) suggested but not available

Данная ошибка может встречаться при сборке расширений языка R. Она означает, что у собираемого пакета есть необязательная зависимость от каких-то других модулей, которые в сборочной среде отсутствуют. В идеале для каждой такой зависимости необходимо прописать BuildRequires и Requires - например, если ошибка относится к модулю "foo", то нужны зависимости от R-foo:

BuildRequires: R-foo
Requires: R-foo

Предварительно необходимо убедиться, что такой пакет вообще есть в репозиториях - вывод команды "urpmq R-foo" должен быть непуст. Если пакета нет, то желательно его сначала собрать и добавить в репозитории. Однако при сборке может оказаться, что он зависит от того пакета, который вы собирали до этого и для которого вы собственно и хотите добавить зависимость R-foo. В этом случае первый пакет можно собрать и без R-foo, закомментировав при этом команду "%{_bindir}/R CMD check %{packname}" в секции %check. После этого можно будет уже собрать R-foo и вернуться к исходному пакету, добавив в него зависимость от R-foo и включив тесты в секции %check

ERROR: dependency(ies) not available

Данная ошибка также может встречаться при сборке расширений языка R, но в отличие от предыдущей, здесь речь идет об обязательных зависимостях сборки. Без них пакет не может быть собран, поэтому вам необходимо добавить в spec-файл соответсвующие BuildRequiers и Requires, а при необходимости предварительно собрать нужные пакеты в репозитории РОСЫ.

hunk FAILED -- saving rejects

Данная ошибка означает, что один из патчей (какой именно - указано в выводе rpmbuild) не может быть применен без изменений к новой версии программы. Обычно это означает, что патч необходимо переделать (предварительно определив - нужен ли он еще), что требует определенной квалификации. Однако иногда такая ошибка возникает из-за "строгости" rpmbuild при применении патчей и проблемный патч может быть исправлен в автоматическом режиме с помощью утилиты rediff_patch.

Для этого достаточно склонировать себе Git-репозиторий, перейти в склонированную папку, поместить туда архив с исходным кодом новой версии и запустит rediff_patch, передав ей нужный патч к качестве аргумента:

$ abf get myrepo/myproject
$ cd myproject
$ wget http://project-upstream.org/new-version.tgz
$ rediff_patch 

Если все сложится удачно, то радом со старым патчем "some_patch_to_rediff" появится новый - "some_patch_to_rediff.new" Если же что-то пойдет не так, то в текущей директории останутся папка "rediff_patch" с подпапками вида "myproject.orig" и "myproject" - содержащие соответсвенно оригинальный исходный код и исходный код, получившийся после попытки применить патч. Во второй папке вы найдете файлы с расширениями *rej - это куски патчей, которые применить не удалось.

package 'foo' not found

Аналогична следующей ошибке

"No package '.*' found"

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

Для исправления ошибки достаточно добавить нужную зависимость сборки в spec-файл:

BuildRequires: pkgconfig(foo)

Предварительно необходимо убедиться, что такая зависимость может быть разрешена - попробовать ее установить с помощью urpmi:

# urpmi 'pkgconfig(foo)'

Если urpmi скажет, что не нашел нужного пакета, то необходимо сначала добавить пакет с соответсвующей библиотекой (как правило, она и называется libfoo) в репозитории РОСЫ.

Обратите внимание, что необходимый пакет может находиться в репозитории Contrib, в то время как вы собираете пакет в репозитории Main, Non-free или Restricted. В таком случае Contrib при сборке не используется и требуемый пакет необходимо перенести в репозиторий Main.

/usr/bin/ld: cannot find -lfoo

Данная ошибка возникает при линковке уже собранных объектных файлов и означает, что линкер не смог найти библиотеку "foo". Для исправления ошибки достаточно добавить зависимость от библиотеки в spec-файл. Чтобы определить, как именно эту зависимость прописать, необходимо сначала поискать devel-пакет для библиотеки libfoo (или lib64foo в 64битной системе) с помощью urpmq:

# urpmq -a libfoo
  lib64foo1
  lib64foo-devel

Интересующий нас пакет - тот, что оканчивается на -devel. Посмотрим, что он предоставляет:

# urpmq --provides libfoo-devel
  lib64foo-devel: devel(libfoo(64bit))
  lib64foo-devel: lib64sasl-devel[== 2.1.25]
  lib64foo-devel: libsasl-devel[== 2.1.25]
  lib64foo-devel: libfoo-devel[== 2.1.25]
  lib64foo-devel: sasl-devel[== 2.1.25-7]
  lib64foo-devel: lib64foo-devel[== 2.1.25-7:2014.1]
  lib64foo-devel: pkgconfig(foo)[== 2.1.25-7]

Из данного набора необходимо выбрать что-то одно. В РОСЕ отдается предпочтение зависимостям вида pkgconfig(...), так что в нашем примере в spec-файл необходимо добавить следующую строку:

BuildRequires: pkgconfig(foo)

Если pkgconfig(foo) не окажется в выводе urpmq, то надо добавить зависимость от foo-devel, а если и ее нет - то от libfoo-devel.

Build.PL: No such file or directory

Такая ошибка означает, что предыдущая версия пакета собиралась с помощью скрипт Build.PL, отсутсвующего в новой версии. Часто встречающаяся ситуация - замена Build.PL на Makefile.PL. Если в архиве с исходным кодом новой версии есть скрипт Makefile.PL, то в spec-файле необходимо произвести следующие замены:

  • "/Build.PL installdirs=vendor" -> "Makefile.PL INSTALLDIRS=vendor"
  • ./Build install destdir=%{buildroot} -> %makeinstall_std
  • perl Build.PL install destdir=%{buildroot} -> %makeinstall_std
  • ./Build test -> %make test
  • ./Build -> %make

Для примера можно посмотреть на пакет ...

Если же скрипта Makefile.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.

Makefile.PL: No such file or directory

Возможна и обратная ситуация - вместо Makefile.PL разработчики перешли на Build.PL или что-то еще. Если в архиве с новым исходным кодом есть файл Build.PL, то необходимо провести в spec-файле замены, обратные приведенным в предыдущем пункте:

  • "Makefile.PL INSTALLDIRS=vendor" -> "./Build.PL installdirs=vendor"
  •  %makeinstall_std -> ./Build install destdir=%{buildroot}
  • (если предыдущая замена не сработала) %makeinstall_std -> perl Build.PL install destdir=%{buildroot}
  •  %make test -> ./Build test
  •  %make -> ./Build

Если же скрипта Build.PL в новой версии также нет, то необходимо смотреть - а что, собственно, есть - файлы CMake, configure или готовый Makefile и модифицировать spec-файл в соответствии с используемой системой сборки.

fg: no job control

Ошибка означает, что внутри spec-файла используется макрос RPM, не поддерживаемый в РОСЕ. Поддерживается или нет каждый конкретный макрос, можно узнать с помощью команды rpm --eval:

$ rpm --eval %macro_name

Если rpm ничего не знает о таком макросе, то результатом выполнения этой команды будет "%macro_name". В противном случае rpm развернет определение макроса.

Установка на Ubuntu

Поддерживаются версии Ubuntu 16.04, 18.04 и 20.04.

Примечание

Чтобы установить PHP 7.4 или 7.3, замените 8.0 на 7.4 или 7.3 в следующих командах.

Шаг 1. Установка PHP (Ubuntu)

sudo su
add-apt-repository ppa:ondrej/php -y
apt-get update
apt-get install php8.0 php8.0-dev php8.0-xml -y --allow-unauthenticated

Шаг 2. Установка необходимых компонентов (Ubuntu)

Установите драйвер ODBC для Ubuntu, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (Linux). Также обязательно установите дополнительный пакет unixodbc-dev. Он используется командой pecl для установки драйверов PHP.

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (Ubuntu)

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv
sudo su
printf "; priority=20\nextension=sqlsrv.so\n" > /etc/php/8.0/mods-available/sqlsrv.ini
printf "; priority=30\nextension=pdo_sqlsrv.so\n" > /etc/php/8.0/mods-available/pdo_sqlsrv.ini
exit
sudo phpenmod -v 8.0 sqlsrv pdo_sqlsrv

Если в системе только одна версия PHP, последний шаг можно упростить: phpenmod sqlsrv pdo_sqlsrv.

Шаг 4. Установка Apache и настройка загрузки драйвера (Ubuntu)

sudo su
apt-get install libapache2-mod-php8.0 apache2
a2dismod mpm_event
a2enmod mpm_prefork
a2enmod php8.0
exit

Шаг 5. Перезапуск Apache и тестирование примера скрипта (Ubuntu)

sudo service apache2 restart

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Установка в Ubuntu с PHP-FPM

Поддерживаются версии Ubuntu 16.04, 18.04 и 20.04.

Примечание

Чтобы установить PHP 7.4 или 7.3, замените 8.0 на 7.4 или 7.3 в следующих командах.

Шаг 1. Установка PHP (Ubuntu с PHP-FPM)

sudo su
add-apt-repository ppa:ondrej/php -y
apt-get update
apt-get install php8.0 php8.0-dev php8.0-fpm php8.0-xml -y --allow-unauthenticated

Проверьте состояние службы PHP-FPM, выполнив следующее:

systemctl status php8.0-fpm

Шаг 2. Установка необходимых компонентов (Ubuntu с PHP-FPM)

Установите драйвер ODBC для Ubuntu, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (Linux). Также обязательно установите дополнительный пакет unixodbc-dev. Он используется командой pecl для установки драйверов PHP.

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (Ubuntu с PHP-FPM)

sudo pecl config-set php_ini /etc/php/8.0/fpm/php.ini
sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv
sudo su
printf "; priority=20\nextension=sqlsrv.so\n" > /etc/php/8.0/mods-available/sqlsrv.ini
printf "; priority=30\nextension=pdo_sqlsrv.so\n" > /etc/php/8.0/mods-available/pdo_sqlsrv.ini
exit
sudo phpenmod -v 8.0 sqlsrv pdo_sqlsrv

Если в системе только одна версия PHP, последний шаг можно упростить: phpenmod sqlsrv pdo_sqlsrv.

Убедитесь, что sqlsrv.ini и pdo_sqlsrv.ini находятся в /etc/php/8.0/fpm/conf.d/:

ls /etc/php/8.0/fpm/conf.d/*sqlsrv.ini

Перезапустите службу PHP-FPM:

sudo systemctl restart php8.0-fpm

Шаг 4. Установка и настройка nginx (Ubuntu с PHP-FPM)

sudo apt-get update
sudo apt-get install nginx
sudo systemctl status nginx

Чтобы настроить nginx, необходимо изменить файл /etc/nginx/sites-available/default. Добавьте index.php в список под разделом со следующим текстом: # Add index.php to the list if you are using PHP:

# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html index.php;

Затем раскомментируйте и измените раздел после # pass PHP scripts to FastCGI server следующим образом:

# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.0-fpm.sock;
}

Шаг 5. Перезапуск nginx и тестирование примера скрипта (Ubuntu с PHP-FPM)

sudo systemctl restart nginx.service

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Установка в Red Hat

Поддерживаются версии Red Hat 7 и 8.

Шаг 1. Установка PHP (Red Hat)

Чтобы установить PHP в Red Hat 7, выполните следующие команды:

Примечание

Чтобы установить PHP 7.4 или 7.3, замените remi-php80 строкой remi-php74 или remi-php73 соответственно в следующих командах.

sudo su
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install https://rpms.remirepo.net/enterprise/remi-release-7.rpm
subscription-manager repos --enable=rhel-7-server-optional-rpms
yum install yum-utils
yum-config-manager --enable remi-php80
yum update
# Note: The php-pdo package is required only for the PDO_SQLSRV driver
yum install php php-pdo php-xml php-pear php-devel re2c gcc-c++ gcc

Чтобы установить PHP в Red Hat 8, выполните следующие команды:

Примечание

Чтобы установить PHP 7.4 или 7.3, замените remi-8.0 на remi-7.4 или remi-7.3 соответственно в следующих командах.

sudo su
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
dnf install yum-utils
dnf module reset php
dnf module install php:remi-8.0
subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
dnf update
# Note: The php-pdo package is required only for the PDO_SQLSRV driver
dnf install php-pdo php-pear php-devel

Шаг 2. Установка необходимых компонентов (Red Hat)

Установите драйвер ODBC для Red Hat 7 или 8, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (Linux). Также обязательно установите дополнительный пакет unixodbc-dev. Он используется командой pecl для установки драйверов PHP.

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (Red Hat)

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv
sudo su
echo extension=pdo_sqlsrv.so >> `php --ini | grep "Scan for additional .ini files" | sed -e "s|.*:\s*||"`/30-pdo_sqlsrv.ini
echo extension=sqlsrv.so >> `php --ini | grep "Scan for additional .ini files" | sed -e "s|.*:\s*||"`/20-sqlsrv.ini
exit

Можно также установить их из репозитория Remi:

sudo yum install php-sqlsrv

Шаг 4. Установка Apache (Red Hat)

sudo yum install httpd

SELinux устанавливается по умолчанию и выполняется в принудительном режиме. Чтобы разрешить Apache подключаться к базам данных через SELinux, выполните следующую команду:

sudo setsebool -P httpd_can_network_connect_db 1

Шаг 5. Перезапуск Apache и тестирование примера скрипта (Red Hat)

sudo apachectl restart

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Установка в Debian

Поддерживаются версии Debian 9 и 10.

Примечание

Чтобы установить PHP 7.4 или 7.3, замените 8.0 на 7.4 или 7.3 в следующих командах.

Шаг 1. Установка PHP (Debian)

sudo su
apt-get install curl apt-transport-https
wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list
apt-get update
apt-get install -y php8.0 php8.0-dev php8.0-xml php8.0-intl

Шаг 2. Установка необходимых компонентов (Debian)

Установите драйвер ODBC для Debian, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (Linux). Также обязательно установите дополнительный пакет unixodbc-dev. Он используется командой pecl для установки драйверов PHP.

Кроме того, может потребоваться создать правильный языковой стандарт, чтобы выходные данные PHP правильно отображались в браузере. Например, для языкового стандарта en_US UTF-8 выполните следующие команды:

sudo su
sed -i 's/# en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/g' /etc/locale.gen
locale-gen

Может потребоваться добавить /usr/sbin в $PATH, так как там находится исполняемый файл locale-gen.

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (Debian)

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv
sudo su
printf "; priority=20\nextension=sqlsrv.so\n" > /etc/php/8.0/mods-available/sqlsrv.ini
printf "; priority=30\nextension=pdo_sqlsrv.so\n" > /etc/php/8.0/mods-available/pdo_sqlsrv.ini
exit
sudo phpenmod -v 8.0 sqlsrv pdo_sqlsrv

Если в системе только одна версия PHP, последний шаг можно упростить: phpenmod sqlsrv pdo_sqlsrv. Как и в случае с locale-gen, phpenmod находится в /usr/sbin, поэтому может потребоваться добавить этот каталог в $PATH.

Шаг 4. Установка Apache и настройка загрузки драйвера (Debian)

sudo su
apt-get install libapache2-mod-php8.0 apache2
a2dismod mpm_event
a2enmod mpm_prefork
a2enmod php8.0

Шаг 5. Перезапуск Apache и тестирование примера скрипта (Debian)

sudo service apache2 restart

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Установка в Suse

Поддерживаются версии Suse Enterprise Linux 12 и 15.

Примечание

В следующих инструкциях замените на свою версию SUSE. Если вы используете SUSE Enterprise Linux 15, это будет SLE_15_SP1 или SLE_15_SP2. Для SUSE 12 используйте SLE_12_SP4 (или выше, если применимо). Не все версии PHP доступны для всех версий SUSE Linux. В http://download.opensuse.org/repositories/devel:/languages:/php указано, какие версии SUSE имеют доступную версию PHP по умолчанию, а в http://download.opensuse.org/repositories/devel:/languages:/php:/ — какие еще версии PHP доступны для разных версий SUSE.

Примечание

Пакеты для PHP 7.4 или более поздней версии недоступны для SUSE 12, а пакет для PHP 8.0 пока не доступен для SUSE 15. Чтобы установить PHP 7.3, замените URL-адрес репозитория в команде ниже следующим URL-адресом: https://download.opensuse.org/repositories/devel:/languages:/php:/php73//devel:languages:php:php73.repo.

Шаг 1. Установка PHP (Suse)

sudo su
zypper -n ar -f https://download.opensuse.org/repositories/devel:languages:php//devel:languages:php.repo
zypper --gpg-auto-import-keys refresh
zypper -n install php7 php7-devel php7-openssl

Шаг 2. Установка необходимых компонентов (Suse)

Установите драйвер ODBC для SUSE, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (Linux). Также обязательно установите дополнительный пакет unixodbc-dev. Он используется командой pecl для установки драйверов PHP.

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (Suse)

Примечание

Если вы получаете сообщение об ошибке вида Connection to 'pecl.php.net:443' failed: Unable to find the socket transport "ssl", измените скрипт pecl в папке /usr/bin/pecl, удалив аргумент -n в последней строке. Этот аргумент запрещает PECL загружать ini-файлы при вызове PHP, что мешает загрузить расширение OpenSSL PECL.

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv
sudo su
echo extension=pdo_sqlsrv.so >> `php --ini | grep "Scan for additional .ini files" | sed -e "s|.*:\s*||"`/pdo_sqlsrv.ini
echo extension=sqlsrv.so >> `php --ini | grep "Scan for additional .ini files" | sed -e "s|.*:\s*||"`/sqlsrv.ini
exit

Шаг 4. Установка Apache и настройка загрузки драйвера (Suse)

sudo su
zypper install apache2 apache2-mod_php7
a2enmod php7
echo "extension=sqlsrv.so" >> /etc/php7/apache2/php.ini
echo "extension=pdo_sqlsrv.so" >> /etc/php7/apache2/php.ini
exit

Шаг 5. Перезапуск Apache и тестирование примера скрипта (Suse)

sudo systemctl restart apache2

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Установка в Alpine

Поддерживаются версии Alpine 3.11 и 3.12.

Примечание

Версия PHP по умолчанию — 7.3. Версия PHP 7.4 или более поздняя может быть доступна в тестовых или пограничных репозиториях для Alpine. Вместо этого можно скомпилировать PHP из источника.

Шаг 1. Установка PHP (Alpine)

Пакеты PHP для Alpine находятся в репозитории edge/community. Проверьте раздел Включить репозиторий сообщества на их вики-странице. Добавьте следующую строку в /etc/apk/repositories, заменив на URL-адрес зеркального отображения репозитория Alpine:

http:///alpine/edge/community

Далее выполните:

sudo su
apk update
# Note: The php7-pdo package is required only for the PDO_SQLSRV driver
apk add php7 php7-dev php7-pear php7-pdo php7-openssl autoconf make g++

Шаг 2. Установка необходимых компонентов (Alpine)

Установите драйвер ODBC для Alpine, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (Linux). Также обязательно установите пакет unixodbc-dev (sudo apk add unixodbc-dev). Он используется командой pecl для установки драйверов PHP.

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (Alpine)

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv
sudo su
echo extension=pdo_sqlsrv.so >> `php --ini | grep "Scan for additional .ini files" | sed -e "s|.*:\s*||"`/10_pdo_sqlsrv.ini
echo extension=sqlsrv.so >> `php --ini | grep "Scan for additional .ini files" | sed -e "s|.*:\s*||"`/00_sqlsrv.ini

Шаг 4. Установка Apache и настройка загрузки драйвера (Alpine)

sudo apk add php7-apache2 apache2

Шаг 5. Перезапуск Apache и тестирование примера скрипта (Alpine)

sudo rc-service apache2 restart

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Установка в macOS

Поддерживаются версии MacOS 10.14 (Mojave), 10.15 (Catalina) и 11.0 (Big Sur).

Установите brew, как описано ниже, если у вас ее еще нет:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Примечание

Чтобы установить PHP 7.4 или 7.3, замените php@8.0 на php@7.4 или php@7.3 соответственно в следующих командах.

Шаг 1. Установка PHP (macOS)

brew tap
brew tap homebrew/core
brew install php@8.0

PHP теперь должен быть указан в пути. Запустите php -v и убедитесь, что используется правильная версия PHP. Если в пути нет PHP или есть PHP неправильной версии, выполните следующие команды:

brew link --force --overwrite php@8.0

Шаг 2. Установка необходимых компонентов (macOS)

Установите драйвер ODBC для macOS, следуя инструкциям в статье Установка Microsoft ODBC Driver for SQL Server (macOS).

Кроме того, может потребоваться установить средства make для GNU:

brew install autoconf automake libtool

Шаг 3. Установка драйверов PHP для Microsoft SQL Server (macOS)

sudo pecl install sqlsrv
sudo pecl install pdo_sqlsrv

Шаг 4. Установка Apache и настройка загрузки драйвера (macOS)

brew install apache2

Чтобы найти файл конфигурации Apache (httpd.conf) для установки Apache, выполните следующую команду:

/usr/local/bin/apachectl -V | grep SERVER_CONFIG_FILE

Следующие команды добавляют необходимую конфигурацию в httpd.conf. Не забудьте указать путь, возвращенный предыдущей командой, вместо /usr/local/etc/httpd/httpd.conf:

echo "LoadModule php7_module /usr/local/opt/php@8.0/lib/httpd/modules/libphp7.so" >> /usr/local/etc/httpd/httpd.conf
(echo ""; echo "SetHandler application/x-httpd-php"; echo "";) >> /usr/local/etc/httpd/httpd.conf

Шаг 5. Перезапуск Apache и тестирование примера скрипта (macOS)

sudo apachectl restart

Чтобы протестировать установку, воспользуйтесь разделом Тестирование установки в конце этого документа.

Тестирование установки

Чтобы протестировать этот пример скрипта, создайте файл с именем testsql.php в корневом каталоге документов системы. Это путь /var/www/html/ в Ubuntu, Debian и Red Hat, /srv/www/htdocs в Suse, /var/www/localhost/htdocs в Alpine и /usr/local/var/www в macOS. Скопируйте приведенный ниже скрипт, заменив имя сервера, имя базы данных, имя пользователя и пароль правильными значениями.

Пример SQLSRV

 "yourDatabase",
    "uid" => "yourUsername",
    "pwd" => "yourPassword"
);

function exception_handler($exception) {
    echo "

Failure

"; echo "Uncaught exception: " , $exception->getMessage(); echo "

PHP Info for troubleshooting

"; phpinfo(); } set_exception_handler('exception_handler'); // Establishes the connection $conn = sqlsrv_connect($serverName, $connectionOptions); if ($conn === false) { die(formatErrors(sqlsrv_errors())); } // Select Query $tsql = "SELECT @@Version AS SQL_VERSION"; // Executes the query $stmt = sqlsrv_query($conn, $tsql); // Error handling if ($stmt === false) { die(formatErrors(sqlsrv_errors())); } ?>

Success Results :

SQL Error:"; echo "Error information:
"; foreach ($errors as $error) { echo "SQLSTATE: ". $error['SQLSTATE'] . "
"; echo "Code: ". $error['code'] . "
"; echo "Message: ". $error['message'] . "
"; } } ?>

Пример PDO_SQLSRV

query($tsql);
} catch (PDOException $exception1) {
    echo "

Caught PDO exception:

"; echo $exception1->getMessage() . PHP_EOL; echo "

PHP Info for troubleshooting

"; phpinfo(); } ?>

Success Results :

fetch(PDO::FETCH_ASSOC)) { echo $row['SQL_VERSION'] . PHP_EOL; } } catch (PDOException $exception2) { // Display errors echo "

Caught PDO exception:

"; echo $exception2->getMessage() . PHP_EOL; } unset($stmt); unset($conn); ?>

Перейдите в браузере на страницу https://localhost/testsql.php (https://localhost:8080/testsql.php в Mac OS). Теперь вы сможете подключиться к базе данных SQL Server или SQL Azure. Если вы не видите сообщение об успешном выполнении с информацией о версии SQL, выполните основные действия по устранению неполадок, запустив скрипт из командной строки:

php testsql.php

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

Introduction

Orchid is a free Laravel package that abstracts standard business logic and allows code-driven rapid application development of back office applications, admin/user panels and dashboards.

Laravel Orchid Platform

Interesting Features

  • Rapid Application Development - Focus to PHP development and don't lose time with HTML, CSS, or JavaScript. Build application logic, not admin panels. Try our quick start guide and kick-start your application's development.

  • Form Builder - Prevent reinventing the wheel or forms. Orchid supports already 40+ form elements "out of the box" and allows you to build all kinds of forms quickly.

  • Fast Loading Times - Enjoy a SPA like performance! Transitions can be made without reloading a page and require no additional code. Thanks to the Hotwire project, Orchid makes this a satisfying experience for you and your users.

  • Access Permissions & Roles - Take advantage of granular access permissions, based on a user’s identity and corresponding role membership.

  • Filtering & Sorting - Offer your users the ability to filter and sort data quickly! Orchid uses an Eloquent based filtering/sorting approach.

  • Fast Full-Text Search - Take advantage of the integrated Laravel Scout based full-text search, that allows searching through all available content, and displaying search results almost instantly.

  • Multiple Notifications Types - Orchid offers various types of notifications and allows your application to keep your users informed appropriately.

Live Demo

Curious but not (yet) in the mood to read the documentation? Click here, to experience a live demo of Orchid.

Getting started

Documentation

  • 🌍 Documentation & Quick Start Guide
  • 🇷🇺 Чтобы ознакомиться с руководством, посетите сайт orchid.software

Blog

Orchid's blog informs about news and announcements around Laravel Orchid, including related projects.

Feedback/Support

We are continually trying to actively include feedback from the community in the development of Orchid. You help us a lot if you give us well structured and detailed feedback.

GitHub

  • Create issues to ask questions or report problems.
  • Participate in disccussions around Orchid and share your ideas/opinions.

Telegram User Groups

  • Global Community
  • Russian Community
  • Spanish Community

Development

Releasese Strategy

We like to keep things as modern as possible and have a "release early, release often" approach to major releases. Meaning, we won't wait an arbitrary number of months to accumulate significant changes and release the next major version. By releasing major versions often, new features will be out earlier, and upgrading between versions will be much easier.

Changelog

We actively and continuously maintain a changelog that informs about Orchid's history of improvements, bug fixes and changes.

Support Orchid

Thanks to our backers 🙏 , Orchid is free for private and commercial purposes. 🎉

Voluntary donations are allowing us to spend more time improving Orchid for everyone! 👍