Желание более свежих пакетов является распространенной проблемой для любой ОС. В последние годы цикл выпуска Debian в среднем составлял 2 года, поэтому к концу этого цикла это, возможно, более насущная проблема. Один из способов смягчить это - перейти к тестированию в конце цикла стабильной версии, когда следующая версия практически стабильна. Из вопроса не ясно, идет ли речь о стабильном и более широком смысле о тестировании и / или о нестабильном. Несмотря на это, наличие самой последней версии может быть проблемой, даже если она работает нестабильно, поскольку самая последняя версия может быть еще не упакована. Разработчики / упаковщики Debian являются добровольцами, поэтому им может быть скучно или они заняты другими делами, в результате чего пакет утомляется.
Для простоты и конкретности в дальнейшем я предполагаю, что план состоит в том, чтобы перенести пакет в стабильный, но он применяется в более общем плане. Итак, вот что я делаю, если я хочу более свежую версию программного обеспечения, которая отсутствует в стабильной, в приблизительном порядке.
Ищите пакет в Debian Backports . Иногда вы можете найти пакет, который является достаточно новым, чтобы удовлетворить ваши цели. Однако часто бывает так, что эти пакеты устарели по сравнению с версией в нестабильной, экспериментальной или апстримовой версиях.
Попробуйте установить пакет непосредственно из тестового, нестабильного или экспериментального. Если стабильная версия не сильно отличается от той версии, с которой вы пытаетесь установить, это может сработать. Вы поймете, что этот подход плох, если система начинает пытаться установить или обновить базовые пакеты с более поздней версии. Предположим, вы пытаетесь установить с нестабильной, то
apt-get install packagename/unstable
это первое, что нужно попробовать. С версиями apt in stable это часто приводит к сбою, так как для этого требуются другие пакеты от unstable, и это заклинание только повышает предпочтение packagenameдостаточно высокого уровня для его установки в unstable. Если вы не понимаете, что это значит, уходите и читайте man
apt_preferences. Продолжайте добавлять зависимости от unstable, убедившись, что он не пытается обновить базовые пакеты. Например, если он начинает пытаться обновить libc6, X, KDE или Gnome, немедленно прервите работу. Обычно хорошо, если он пытается обновить другие пакеты из того же исходного пакета, поскольку они обычно тесно связаны друг с другом. Чтобы увидеть, от какого исходного пакета зависит бинарный пакет, выполните
apt-cache showsrc packagename
Поскольку многое зависит от библиотеки GNU C (libc6), раньше это было проблемой. В последнее время API, похоже, стабилизировался, поэтому теперь чаще можно обойтись без необходимости его обновления. Если пакет удовлетворяет свои зависимости времени выполнения от стабильного, но все еще не работает правильно, сообщите об ошибке. Если упаковщик говорит вам, что это не ошибка, они ошибаются. :-)
Бэкпорт пакета самостоятельно от тестирования, нестабильной или экспериментальной.
Как упомянуто выше, backports является одним из вариантов, но часто эти пакеты устарели по сравнению с версией в нестабильной, экспериментальной или апстримовой версиях.
Часто для этого может потребоваться рекурсивный тип построения цикла зависимости. Сначала вы должны получить зависимости сборки с
apt-get build-dep packagename
Если это не удается из-за того, что одна из зависимостей не является достаточно новой, вам нужно сначала создать резервную копию этой зависимости. Это может выйти из-под контроля. Я обычно сдаюсь, если мне приходится иметь дело с более чем 2 уровнями рекурсии. Тем не менее, обратите внимание, что реальные зависимости не обязательно такие жесткие, как указано, т.е. более старая версия может работать. Упаковщик часто не пытается найти самую старую версию зависимости сборки (или даже времени выполнения), которая будет работать.
Проверьте наличие пакетов из соответствующего апстрима. В идеале они должны соответствовать вашей версии дистрибутива, но вы также можете перестроить их при необходимости.
Создавайте пакеты для версий программного обеспечения, более поздних, чем самые последние пакеты в тестировании / нестабильном / экспериментальном. Это может быть относительно сложно, но все же иногда удивительно выполнимо. Первое, на что следует обратить внимание: если вы пытаетесь упаковать более свежую версию пакета, который уже находится в Debian, вы уже начинаете с большого преимущества, а именно, что у вас есть существующий пакет для работы. Просто делать
apt-get source packagename
и apt-getзагрузит соответствующий пакет с исходным кодом, включая подкаталог debian, в котором находится пакет. Кроме того, обратите внимание, что в наши дни эта упаковка часто находится в каком-то репозитории verson control (git кажется популярным в Debian), и stable apt (в настоящее время 0.8.10.3 ) услужливо сообщает вам, где это происходит, когда вы вызываете
apt-get source. Вам следует обратить на это внимание, поскольку упаковщики могут иметь более свежие версии упаковки, чем соответствует любой выпущенной упаковке. Например.
$ apt-get source mercurial
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/python-apps/packages/mercurial/trunk
В качестве альтернативы, вы можете просто использовать
apt-cache showsrc mercurial | grep Vcs
перечислить хранилище.
Если пакет сильно устарел, вам, возможно, придется внести изменения в
пакет, обновить примененные исправления, но обычно это хорошая отправная
точка. Похоже, что Debian находится в процессе стандартизации управления пакетами в
quilt в формате dpkg-source 3.0 (quilt) , что помогает в обновлении патчей.
В заключение я приведу реальный пример того, как я перенес пакет Debian в
pgf . Последняя упакованная версия pgf была 2.00 в 2008 году, и с тех пор 2.10 была выпущена. Смотрите обсуждение в Пожалуйста, обновите до последней стабильной версии pgf (2.10) , и мою ошибку с патчем, pgf: patches против пакета 2.0 Debian . Как оказалось, упаковка pgf в Debian была очень простой, и мне просто пришлось изменить одну строку в упаковке 2.10, чтобы она работала. Я также подавил все
жалобы Lintian , но это было строго необязательно.
Вы, конечно, можете создавать свои собственные пакеты, и это будет работать. Однако я бы рекомендовал сначала использовать бэкпорт, если там есть то, что вы хотите.
Backports поддерживается Debian, и вы получаете обновления для них.
источник
Построение ваших собственных пакетов - это путь (ИМХО). В зависимости от возраста версии пакета Debian и того, что изменилось, это может быть так же просто, как заменить имя файла исходного архива в описании пакета, и в худшем случае вы все равно можете использовать его как шаблон для своей собственной версии.
источник
Что вы делаете, если вам всегда нужна последняя версия?
Как уже упоминалось , используйте backports.
Бэкпортировано только небольшое подмножество пакетов Debian, поэтому я предлагаю вам использовать Debian Testing . Он предлагает хороший баланс между стабильностью и свежестью, и в некотором смысле напоминает динамичный дистрибутив.
Если вы немного смелее, используйте Debian Unstable . Утверждается, что он достаточно стабилен. Некоторые даже заявляют, что он более стабильный, чем "стабильные" релизы других дистрибутивов. В любом случае, в Unstable обычно появляются новые версии пакетов. Обычно они проводят там около 10 дней, чтобы провести тестирование, прежде чем перейти к тестированию.
Даже используя эти два, вы все равно можете не иметь последних версий. В этом случае взгляните на Debian Experimental . Обычно он используется, когда новые пакеты слишком разрушительны для обычных архивов (Unstable and Testing).
Если у Experimental все еще нет достаточно новых версий программного обеспечения, посмотрите PPA в Ubuntu . Я видел там более свежие версии программного обеспечения, чем то, чего нет во всех вышеуказанных архивах. Однако используйте его с осторожностью, поскольку Ubuntu не на 100% совместим с Debian (но в большинстве случаев проблем быть не должно).
Если вышеперечисленное не сработает, я думаю, просто создайте свои собственные пакеты, как уже упоминалось .
источник