Не удалось найти пакет по регулярному выражению linux

Причина появления ошибки «Не удалось найти пакет…» на ОС Debian

Здравствуйте. Моё знание UNIX систем нельзя назвать хорошим, единственное что я могу по-сути, это запустить веб-сервер, хотя когда мой сервер начали активно форсить, пришлось немного подумать о безопасности. Поэтому я и решил написать статью о denyhosts, но когда создавал виртуальную машину совсем забыл, что denyhosts ещё не добавлен в репозитарии Debian 8, так что столкнулся с ошибкой «Не удалось найти пакет…» или «Unable to locate package…» в английском варианте.

В принципе ничего страшного нет, все решается добавлением новых источников в source.list, чем мы сейчас займёмся. Но также есть ещё возможные ошибки: проверьте правильно ли вы указали имя пакета для установки или входит ли данный пакет вообще в общие репозитории (возможно данные пакет устанавливается путем скачивания исходников).

Итак, для редактирования списка репозиторий необходимо открыть source.list, для этого вводим команду (если вы находитесь из под пользователя, то конечно же добавляем sudo):

Где nano — это мой любимый текстовый редактор (apt-get install nano), используйте тот, который вам нравится.

Откроется текстовый редактор со списком репозиториев.

Что за что отвечает:
deb — это бинарные пакеты, deb-src — пакеты с исходниками (если нужно пересобрать пакет);
*ссылка* репозитория;
jessie — название выпуска Debian, на виртуальной машине у меня стоит Debian 8 — Jessie, ранее были Debian 7 — Wheezy, Debian 6 — Squeeze. Также можно использовать название ветки stable, unstable, testing и т.д. (подробнее о выпусках можно прочитать на википедии);
main — основная секция репозитория; contrib — пакеты в этой части распространяются владельцем авторских прав на условиях свободной лицензии, но зависят от несвободного программного обеспечения; non-free — лицензии пакетов в этой части содержат условия, ограничивающие использование или распространение ПО.

В общем обо всём этом вы можете прочитать на крупных форумах, нас же интересует конкретика, поэтому прописываем две строчки:

Это добавит ссылку на главный репозиторий Debian. Он работает всегда. Также можно заметить, что я добавил ссылку на архив с пакетам для прошлых версий debian, это всё из-за того, что denyhosts ещё не допущен до Debian 8. При необходимости меняем jessie на свою версию системы. При желании остальное можно отключить, поставив # в начале строчки (это полезно, если у вас лимитированный трафик).

Теперь записываем изменения, нажав Ctrl+O на клавиатуре и нажав Enter, для подтверждения текущего имени файла.

И закрываем редактор, клавишами Ctrl+X.

Теперь вводим команду:

Это обновит список доступных пакетов.

И вводим команду по установке необходимого пакета.

Вроде всё. Надеюсь эта статья оказалась вам полезной, нажмите одну из кнопок ниже, чтобы рассказать о ней друзьям. Также подпишитесь на обновления сайта, введя свой e-mail в поле справа или подписавшись на группу во Вконтакте и канал YouTube.

Спасибо за внимание

Источник

Ошибка unable to locate package в Ubuntu

Один из многих способов установки программного обеспечения в Ubuntu – команда apt-get или apt. Установка пакетов с помощью пакетного менеджера намного удобнее и безопаснее, чем поиск и загрузка программ в интернете. Открыв терминал, вы должны вызвать утилиту apt с параметром install написать название программы, чтобы установить ее.

При использовании этой команды иногда возникает ошибка E: Unable to locate package. Ошибка не нуждается в пояснении. Linux-система не может найти пакет, который вы пытаетесь установить. Но почему так? Почему она не видит пакет? Рассмотрим несколько способов решения данной проблемы. В этой статье мы рассмотрим как исправить ошибку Unable to locate package error в Ubuntu.

Ошибка Unable to locate package error в Ubuntu

Дальше пошагово рассмотрим процесс устранения ошибки.

1. Проверьте имя пакета

Это первое, что вы должны сделать. Может, в названии пакета опечатка? Если вы пытаетесь установить vlc и написали vcl, то непременно ничего не получится. Опечатки – распространенная проблема, так что убедитесь в том, что вы не допустили ошибок во время ввода имени пакета.

2. Обновите кэш репозиториев

Если вы в первый раз запустили систему после установки, следует написать команду update:

sudo apt update

Данная команда не обновит Ubuntu полностью. На деле, команда apt update составляет локальный список доступных для установки пакетов.

При использовании команды install, менеджер пакетов apt просматривает кэш, чтобы получить информацию о пакете и его версии, а затем скачать его из репозиториев в сети. Если пакета в кэше нет, система не сможет его установить.

Кэш в только что установленной системе изначально пуст. Именно поэтому вам стоит запустить команду apt update сразу после установки Ubuntu или других дистрибутивов, основанных на Ubuntu (например, Linux Mint).

Даже если система не новая, кэш apt вполне может оказаться устаревшим. В любой момент не лишним будет его обновить.

3. Убедитесь, что пакет доступен в вашей версии Ubuntu

Отлично! Вы проверили название пакета, и оно верно. Вы запустили команду update, чтобы обновить состояние кэша, но все ошибка unable to locate package все еще присутствует. Вполне возможно, что пакет попросту недоступен. Но вы следуете инструкции с какого-то сайта, и у всех получается установить его указанным образом. В чем может заключаться проблема?

Есть два варианта. Либо пакет доступен в репозитории Universe, который в вашей системе не включен, либо пакета вовсе не существует для вашей версии Ubuntu.

Первый шаг – проверьте, какая версия Ubuntu у вас запущена. Откройте терминал и введите следующую команду:

В результате вы увидите версию Ubuntu и ее кодовое название. Именно кодовое название нам важно больше всего. Как видите, мы используем Ubuntu 18.04 с кодовым именем bionic. У вас может быть иначе, но суть должна быть понятна. Как только вы получили сведения о версии и названии, откройте сайт Ubuntu Packages.

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

Вам будет показано, доступен ли пакет для вашей версии Ubuntu, и если это так, то вместе с этим отобразится репозиторий, в котором он находится. Мы искали средство создания скриншотов Shutter и вот, что вышло для Ubuntu 18.04 Bionic:

В нашем случае, название пакета точно совпало. Это значит, что пакет shutter существует для Ubuntu 18.04 Bionic, но в репозитории Universe.

Если необходимый пакет доступен для вашей версии Ubuntu, но в Universe или Multiverse, эти репозитории необходимо включить:

sudo add-apt-repository universe multiverse

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

sudo apt update

Теперь установка пакета должна пройти гладко.

Ничего не работает, что делать?

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

Возьмем в качестве примера Shutter. Это отличное средство создания скриншотов для Linux, но его несколько лет не обновляли, поэтому в Ubuntu 18.10 и более новых версиях оно не поддерживается. Как же его установить? К счастью, один сторонний разработчик создал собственный репозиторий (PPA) и установить программу можно с помощью него. Искать пакеты и PPA, в которых они находятся, можно на сайте Launchpad для Ubuntu.

Учтите, что не стоит подключать неофициальные PPA к списку репозиториев. Лучше пользоваться теми, которые есть в вашем дистрибутиве.

Если нет даже PPA, зайдите на официальный сайт программы и проверьте, нет ли там описания альтернативных способов установки. У некоторых проектов есть .deb или AppImage файлы. Другие перешли на Snap пакеты.

Иными словами, проверьте на официальном сайте, не изменился ли метод установки приложения.

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

В заключение…

Теперь вы знаете как исправить ошибку unable to locate package Ubuntu. Если вы начали пользоваться Linux недавно, все может казаться очень непонятным. По этой причине мы освещаем подобные темы, чтобы вы могли лучше разобраться в том, как работают те или иные аспекты вашей системы.

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

Источник

Wine не ставится из реп.

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

sudo apt-get install wine1.3 или как там

покажи aptitude search wine

apt-cache search wine

Нету его в testing, нету.

И шо, теперь только с сайта?

sudo apt-get install wine1.4

На сайте сказано:

Debian Linux Download Debian packages — binary .debs for Debian Sid

Значит, я так полагаю, мне не подходит?

Wine есть только в Stable и Unstable.

На сайте сказано:

Debian Linux Download Debian packages — binary .debs for Debian Sid

Значит, я так полагаю, мне не подходит?

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

Боюсь, что да. Хотя, дебиан не практиковал долгое время. Попробуйте подключить по какому-то манулу(загуглите смешение веток) репозитории Unstable и поставить оттуда.

А ежели потребует чего свежего? Мне по зависимостям весь сид тянуть? О_о.

Подходит. Testing от Sid отличается несильно.

Это только на первых порах, потом sid уходит далеко вперёд.

С большой вероятностью потребует. 🙂 А ты как хотел? И рыбку съесть, и. 🙂

Мда. При первой же возможности свалю обратно на gentoo. Она себе такого не позволяла.

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

Зачем он нужен из официальных репозиториев та? Подключай aptosid, frickelplatz.de или убунтушные или качай отсюда:

Почитай о разработке деба. В момент релиза stable (и только в этот момент) testing==sid. А потом их пути потихоньку расходятся.

ну всё равно они совместимы. никогда не приходилось половины сида докачивать.

facepalm.png Ну давай ссылку. Хотя её в природе не существует, чего уж там.

Вот у меня сейчас testing и немного sid (и иногда experimental), и я слежу за движением интересных мне пакетов начиная с ранних этапов — из sid они приходят через стандартные десять дней. Дольше обычно всякие вещи вроде xserver-xorg-video-nouveau и прочие «трудные» пакеты.

А теперь подумай, как в замороженный тестинг могут попадать апдейты из сида.

wheezy разве уже заморозили?

А кто говорил про заморозку? 🙂

В момент релиза stable (и только в этот момент) testing==sid. А потом их пути потихоньку расходятся.

Пути расходятся при заморозке, но заморозка не релиз. Вот вскоре после релиза testing и sid как раз возобновляют движение с небольшим временным интервалом.

Цель тестинга — стать замороженным, чтобы потом получился стейбл.

Спасибо, конечно, но этот незатейливый факт мне известен примерно со времени моего знакомства с Debian.

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

Молодец, а теперь прочитай то, что я писал выше:

Это только на первых порах, потом sid уходит далеко вперёд.

Правда, похоже на то, к чему ты пришёл?

В момент релиза stable (и только в этот момент) testing==sid. А потом их пути потихоньку расходятся.

Это неверно. Верным высказывание станет только при замене «релиза stable» на «заморозки testing». Нарисуй на бумажке таймлайн, тогда всё станет на свои места.

Поставил бинари от sid. Вроде ничего не потянули. Сегодня ночью докачается DII и утром/днем посмотрю, как будет запускаться.

То есть я хочу сказать, что ты упорно путаешь заморозку и релиз.

В нестабильном старый вайн (1.1.3 если не ошибаюсь). Легче самому собрать его, или поставить отсюда http://dev.carbon-project.org/debian/wine-unstable/

Не, я их упорно не путаю. Ты меня упорно не хочешь понять.

Разъясню ещё раз позицию: в момент релиза (ну хорошо, не в момент, а на следующий день) в тестинг сгружается весь сид. Поэтому они равны. А потом расходятся.

Разъясню ещё раз позицию: в момент релиза (ну хорошо, не в момент, а на следующий день) в тестинг сгружается весь сид. Поэтому они равны. А потом расходятся.

Да. Но расходятся всего лишь на десять дней. Это типичный график, хотя и не фиксированный жёстко: http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html, пункт 3.1.7. То есть растущего отставания здесь нет (для большинства пакетов).

И так до заморозки. После заморозки расхождение начинает расти дальше условных 10 дней.

Ну я и говорил о заморозке.

После заморозки расхождение начинает расти дальше условных 10 дней.

хрен там, в сид тоже апдейты почти перестают попадать. Я на него перешел примерно за год до релиза сквиза, и точно помню, как при update обновленных пакетов приходило 2-3 вместо обычных 20-30

Пугает меня фраза на сайте, что последние сборки являются unstable и лучше ставить из реп

лучше поставить playonlinux, там разные программы запускать под разными версиями wine (смотреть по appdb, где какая программа точно работает).
А то дело такое, регрессии постоянные, да и «стабильные» версии не очень-то и стабильные в этом плане.

Источник