Потрібні новітні пакунки - це поширена проблема в будь-якій ОС. Цикл випуску Debian за останні роки становив у середньому 2 роки, тож наприкінці цього циклу це, мабуть, більш актуальна проблема. Одним із способів їх пом'якшення є перехід до тестування до кінця циклу стабільного випуску, коли наступна версія майже стабільна. З питання не зрозуміло, чи йдеться про стабільне, загалом, про тестування та / або нестабільність. Незважаючи на те, наявність найновішої версії може бути проблемою, навіть якщо вона працює, якщо вона нестабільна, оскільки найновіша версія може бути ще не упакована. Розробники / пакувальники Debian - це добровольці, тому їм може бути нудно або зайнято іншими справами, в результаті чого пакет знемагає.
Для простоти та конкретності я припускаю, що з цього випливає, що план полягає в тому, щоб підтримувати пакет стабільним, але він застосовується більш загально. Отже, ось що я роблю, якщо хочу отримати більш новітню версію програмного забезпечення, яка не є стабільною, у приблизному порядку.
Шукайте пакет у Debian Backports . Іноді ви можете знайти пакет, який є досить недавним, щоб задовольнити ваші цілі. Однак часто трапляється, що ці пакети застаріли в порівнянні з версією в нестабільній, експериментальній або вище за течією.
Спробуйте встановити пакет безпосередньо з тестового, нестабільного або експериментального. Якщо стабільний не сильно відрізняється від версії, яку ви намагаєтесь встановити, це може працювати. Ви знаєте, що такий підхід поганий, якщо система почне намагатися встановити або оновити базові пакети з останньої версії. Припустимо, ви намагаєтесь встановити з нестабільної, то
apt-get install packagename/unstable
це перше, що потрібно спробувати. При версіях apt в стабільній системі це часто провалюється, оскільки для цього потрібні інші пакети від нестабільних, і ця заповнення лише підвищує перевагу packagenameдостатньо високої, щоб встановити її в нестабільній. Якщо ви не розумієте, що це означає, підіть і почитайте man
apt_preferences. Продовжуйте додавати залежності від нестабільних, переконуючись, що вони не намагаються оновити базові пакети. Наприклад, якщо він починає намагатися оновити libc6 або X або KDE або Gnome, негайно скасовуйте роботу. Зазвичай це добре, якщо він намагається оновити інші пакунки з того самого вихідного пакету, оскільки вони, як правило, щільно з'єднані між собою. Щоб побачити, від якого джерела пакунків залежить двійковий пакет, зробіть
apt-cache showsrc packagename
Оскільки багато матеріалів залежить від бібліотеки GNU C (libc6), це раніше було проблемою. З недавніх пір API, здається, стабілізувався, тому тепер частіше можна відійти від необхідності його оновлення. Якщо пакет задовольняє залежність від стабільності роботи, але він не працює належним чином, подайте помилку. Якщо пакувальник скаже вам, що це не помилка, вони помиляються. :-)
Підкріпіть пакунок самостійно від тестування, нестабільності або експериментальності.
Як згадувалося вище, резервні сторони є одним із варіантів, але часто ці пакети застаріли порівняно з версією у нестабільній або експериментальній чи вище за течією.
Це часто може вимагати рекурсивної речі побудови циклу залежності. Спочатку потрібно отримати залежності побудови
apt-get build-dep packagename
Якщо це не вдається, оскільки одна із залежностей не є достатньо недавньою, вам потрібно спочатку підтримати цю залежність. Це може вийти з-під контролю. Я зазвичай відмовляюся, якщо мені доводиться стикатися з більш ніж двома рівнями рекурсії. Зауважте, що реальні залежності не обов'язково є настільки жорсткими, як зазначено, тобто. може працювати старша версія. Пакувальник часто не намагається знайти найстарішу версію залежності побудови (або, справді, під час виконання), яка працюватиме.
Перевірте наявність пакетів з відповідного висхідного потоку. В ідеалі вони відповідатимуть вашій версії розповсюдження, але ви, можливо, також зможете відновити їх.
Створіть пакети для версії програмного забезпечення пізнішої, ніж найновіші пакети тестування / нестабільні / експериментальні. Це може бути досить складно, але все ж іноді напрочуд можливо. Перше, що слід зазначити, це те, що якщо ви намагаєтесь упакувати більш нову версію пакету, який вже є в Debian, ви вже починаєте з великою перевагою, а саме, що у вас є існуюча упаковка, з якою ви працюєте. Просто роби
apt-get source packagename
і apt-getзавантажить відповідний вихідний пакет, включаючи підкаталог debian, де живе упаковка. Крім того, зауважте, що в наші дні ця упаковка часто знаходиться всередині якогось сховища версії управління (git здається популярним у Debian) та стабільного 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, схоже, знаходиться в процесі стандартизації управління пакетами на
ковдру в форматі dpkg-source 3.0 (quilt) , так що це допомагає при оновленні патчу.
Я закінчу прикладом із реального життя, як я підтримував пакет Debian у
форматі pgf . Остання упакована версія pgf була 2,00 у 2008 році, і з того часу випущено 2,10. Дивіться дискусію в « Будь ласка, оновіть до новітньої стабільної версії pgf (2.10) , і мою подальшу помилку з патчем, pgf: патчі проти упаковки Debian 2.0 . Як виявляється, упаковка pgf Debian була дуже простою, і мені довелося просто змінити одну лінію в упаковці 2.10, щоб вона працювала. Я врешті-решт припинив усі скарги на
літнійські країни , але це було суворо необов'язково.