Как сохранить мою систему Debian с последними пакетами?


9

Большая часть «программного обеспечения», которое я устанавливаю на своем сервере, должна быть последней версией (Java, Tomcat, MySQL-Cluster). Поэтому мне никогда не везет, что есть готовые пакеты Debian (в дистрибутиве). Поэтому все программное обеспечение загружается с веб-страницы проекта и создается из исходного кода.

Теперь мой вопрос: как правильно установить их в моей системе Debian?

Моя основная проблема заключается в том, что при установке их непосредственно из исходного кода они не включаются в управление пакетами (с помощью aptitude). Похоже, что Checkinstall на самом деле не рекомендуется использовать, и у него также есть недостатки. Является ли единственный правильный способ справиться с этим путем создания моих собственных пакетов с помощью dh_make и dpkg-buildpackage?

Что вы делаете, если вам всегда нужна последняя версия?

Ответы:


10

Желание более свежих пакетов является распространенной проблемой для любой ОС. В последние годы цикл выпуска Debian в среднем составлял 2 года, поэтому к концу этого цикла это, возможно, более насущная проблема. Один из способов смягчить это - перейти к тестированию в конце цикла стабильной версии, когда следующая версия практически стабильна. Из вопроса не ясно, идет ли речь о стабильном и более широком смысле о тестировании и / или о нестабильном. Несмотря на это, наличие самой последней версии может быть проблемой, даже если она работает нестабильно, поскольку самая последняя версия может быть еще не упакована. Разработчики / упаковщики Debian являются добровольцами, поэтому им может быть скучно или они заняты другими делами, в результате чего пакет утомляется.

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

  1. Ищите пакет в Debian Backports . Иногда вы можете найти пакет, который является достаточно новым, чтобы удовлетворить ваши цели. Однако часто бывает так, что эти пакеты устарели по сравнению с версией в нестабильной, экспериментальной или апстримовой версиях.

  2. Попробуйте установить пакет непосредственно из тестового, нестабильного или экспериментального. Если стабильная версия не сильно отличается от той версии, с которой вы пытаетесь установить, это может сработать. Вы поймете, что этот подход плох, если система начинает пытаться установить или обновить базовые пакеты с более поздней версии. Предположим, вы пытаетесь установить с нестабильной, то

    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, похоже, стабилизировался, поэтому теперь чаще можно обойтись без необходимости его обновления. Если пакет удовлетворяет свои зависимости времени выполнения от стабильного, но все еще не работает правильно, сообщите об ошибке. Если упаковщик говорит вам, что это не ошибка, они ошибаются. :-)

  3. Бэкпорт пакета самостоятельно от тестирования, нестабильной или экспериментальной.

    Как упомянуто выше, backports является одним из вариантов, но часто эти пакеты устарели по сравнению с версией в нестабильной, экспериментальной или апстримовой версиях.

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

    apt-get build-dep packagename    
    

    Если это не удается из-за того, что одна из зависимостей не является достаточно новой, вам нужно сначала создать резервную копию этой зависимости. Это может выйти из-под контроля. Я обычно сдаюсь, если мне приходится иметь дело с более чем 2 уровнями рекурсии. Тем не менее, обратите внимание, что реальные зависимости не обязательно такие жесткие, как указано, т.е. более старая версия может работать. Упаковщик часто не пытается найти самую старую версию зависимости сборки (или даже времени выполнения), которая будет работать.

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

  5. Создавайте пакеты для версий программного обеспечения, более поздних, чем самые последние пакеты в тестировании / нестабильном / экспериментальном. Это может быть относительно сложно, но все же иногда удивительно выполнимо. Первое, на что следует обратить внимание: если вы пытаетесь упаковать более свежую версию пакета, который уже находится в 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 , но это было строго необязательно.


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

@ Чепанг: Хороший вопрос. Теперь нормально?
Фахим Митха

Да, намного лучше.
Чепанг

5

Вы, конечно, можете создавать свои собственные пакеты, и это будет работать. Однако я бы рекомендовал сначала использовать бэкпорт, если там есть то, что вы хотите.

Backports поддерживается Debian, и вы получаете обновления для них.


3

Построение ваших собственных пакетов - это путь (ИМХО). В зависимости от возраста версии пакета Debian и того, что изменилось, это может быть так же просто, как заменить имя файла исходного архива в описании пакета, и в худшем случае вы все равно можете использовать его как шаблон для своей собственной версии.


1

Что вы делаете, если вам всегда нужна последняя версия?

  1. Как уже упоминалось , используйте backports.

  2. Бэкпортировано только небольшое подмножество пакетов Debian, поэтому я предлагаю вам использовать Debian Testing . Он предлагает хороший баланс между стабильностью и свежестью, и в некотором смысле напоминает динамичный дистрибутив.

  3. Если вы немного смелее, используйте Debian Unstable . Утверждается, что он достаточно стабилен. Некоторые даже заявляют, что он более стабильный, чем "стабильные" релизы других дистрибутивов. В любом случае, в Unstable обычно появляются новые версии пакетов. Обычно они проводят там около 10 дней, чтобы провести тестирование, прежде чем перейти к тестированию.

  4. Даже используя эти два, вы все равно можете не иметь последних версий. В этом случае взгляните на Debian Experimental . Обычно он используется, когда новые пакеты слишком разрушительны для обычных архивов (Unstable and Testing).

  5. Если у Experimental все еще нет достаточно новых версий программного обеспечения, посмотрите PPA в Ubuntu . Я видел там более свежие версии программного обеспечения, чем то, чего нет во всех вышеуказанных архивах. Однако используйте его с осторожностью, поскольку Ubuntu не на 100% совместим с Debian (но в большинстве случаев проблем быть не должно).

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


Люди, которые говорят, что нестабильная версия Debian более стабильна, чем остальные дистрибутивы, в лучшем случае шутят. Нестабильные изменения каждый день, стабильный - это фиксированный репозиторий. Нестабильный вариант не означает, что он будет зависать, но это означает, что разработчики вносят множество изменений в пакеты. Стабильный означает, что он выпущен, и будут добавлены только исправления безопасности. У меня никогда не было странных сбоев, работающих нестабильно. Я видел, как пакеты обновлялись и возникали проблемы с зависимостями после обновления, но будьте осторожны ;-) То, как все это сравнивается со "стабильными" выпусками других дистрибутивов, мне не подходит. Там нет "более стабильной" в этом контексте. Это меняется или нет.
Арджан Дриман

@ArjanDrieman: на самом деле эти люди не шутят, и в этом контексте они ссылаются на то, что они более устойчивы к сбоям.
Чепанг

Они все еще шутят в лучшем случае. Я действительно видел, как люди шутили по этому поводу. Пламя микрораспределения ;-) Я использовал несколько дистрибутивов с течением времени, и у меня никогда не было странных сбоев, запускающих какие-либо другие, Люди, которые говорят, что серьезно не могут подкрепить это исследованиями или статистикой. Это может быть невежество, высокомерие, предубеждение, что угодно ... но разве это лучше, чем шутка? Можете ли вы сказать мне, кто эти таинственные "некоторые"? Так что я могу попросить их об их исследовании? «Некоторые даже заходят так далеко» ... это слова ласки. Что бы вы хотели получить в ответе, фактах или распространенном мнении и неоднозначных утверждениях?
Арджан Дриман

1
@ Арджан Дриман: Я на самом деле согласен с нестабильным, может «иногда» оправдать свое имя. Вы торгуете стабильностью за то, что приближаетесь к краю, любой, кто утверждает, что это не так, в лучшем случае неискренен. В целом он на удивление стабилен, но стабильность - не самый высокий приоритет для нестабильных. Я также склонен согласиться с вами в отношении «скользких» слов. Это почти защитный механизм, так как любое абсолютное / прямое утверждение немедленно подвергается нападению.
JM Becker
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.