Linux debian обновление пакета

Глава 8. Инструменты управления пакетами Debian

8.1. Какие программы для управления пакетами имеются в Debian?

В Debian для управления пакетами имеется множество средств, от программ с графическими или текстовыми интерфейсами, до низкоуровневых утилит установки пакетов. Корректная работа всех доступных инструментов зависит от низкоуровневых утилит, и все они представлены здесь в порядке уменьшения уровня сложности.

Важно понимать, что высокоуровневые инструменты управления пакетами, такие как aptitude или synaptic , для управления пакетами используют apt , который, в свою очередь, использует dpkg для управления пакетами системы.

See Chapter 2. Debian package management of the Debian reference for more information about the Debian package management utilities. This document is available in various languages and formats, see the Debian Reference entry in the DDP Users’ Manuals overview.

8.1.1. dpkg

Это основная программа управления пакетами. dpkg может вызываться с многими параметрами. Наиболее часто используемые из них:

• Показать список всех параметров: dpkg —help
• Показать управляющий файл (и другую информацию) для указанного пакета: dpkg —info foo_VVV-RRR.deb
• Установить пакет на жёсткий диск (т. е. распаковать и настроить): dpkg —install foo_VVV-RRR.deb
• Распаковать архив Debian на жёсткий диск (но не настраивать): dpkg —unpack foo_VVV-RRR.deb . Учтите, что в результате данной операции пакет не обязан быть в рабочем состоянии; для правильной работы может потребоваться внесение изменений в некоторые файлы. Данная команда удаляет любую ранее установленную версию программы и запускает сценарий preinst указанного пакета (см. Раздел 7.6, «Зачем нужны сценарии preinst, postinst, prerm и postrm?»).
• Настроить пакет, который был распакован ранее: dpkg —configure foo . Кроме всего прочего, эта команда запускает сценарий postinst указанного пакета (см. Раздел 7.6, «Зачем нужны сценарии preinst, postinst, prerm и postrm?»). Она также обновляет файлы, перечисленные в conffiles . Обратите внимание, что в качестве аргумента для параметра configure указывается имя пакета (т. е. foo), а не имя файла-архива Debian (т. е. foo_VVV-RRR.deb).
• Распаковать файл с именем «blurf» (или группу файлов с именем «blurf*») из архива Debian: dpkg —fsys-tarfile foo_VVV-RRR.deb | tar -xf — ‘blurf*’
• Удалить пакет (но не его файлы настроек): dpkg —remove foo
• Удалить пакет (вместе с файлами настроек): dpkg —purge foo
• Вывести состояние установки пакетов, содержащих в имени строку (или регулярное выражение) «foo*»: dpkg —list ‘foo*’

8.1.2. APT

APT is the Advanced Package Tool , an advanced interface to the Debian packaging system which provides the apt-get program. It provides commandline tools for searching and managing packages, and for querying information about them, as well as low-level access to all features of the libapt-pkg library. For more information, see the User’s Guide in /usr/share/doc/apt-doc/guide.html/index.html (you will have to install the apt-doc package).

Starting with Debian Jessie, some frequently used apt-get and apt-cache commands have an equivalent via the new apt binary. This means some popular commands like apt-get update , apt-get install , apt-get remove , apt-cache search , or apt-cache show now can also be called simply via apt , say apt update , apt install , apt remove , apt search , or apt show . The following is an overview of the old and new commands:

apt-get update -> apt update apt-get upgrade -> apt upgrade apt-get dist-upgrade -> apt full-upgrade apt-get install package -> apt install package apt-get remove package -> apt remove package apt-get autoremove -> apt autoremove apt-cache search string -> apt search string apt-cache policy package -> apt list -a package apt-cache show package -> apt show package apt-cache showpkg package -> apt show -a package

Инструмент apt совмещает функциональность apt-get и apt-cache, а также по умолчанию использует красивый цветной формат вывода, что очень удобно. Для использования в сценариях или для продвинутого использования предпочтительнее использовать apt-get (а иногда он просто необходим).

apt-get provides a simple way to retrieve and install packages from multiple sources using the command line. Unlike dpkg , apt-get does not understand .deb files, it works with the packages proper name and can only install .deb archives from a source specified in /etc/apt/sources.list . apt-get will call dpkg directly after downloading the .deb archives [5] from the configured sources.

Часто используемые команды apt-get :

Источник

Chapter 8. Updating the package

The rewrite of this tutorial document with updated contents and more practical examples is available as Guide for Debian Maintainers. Please use this new tutorial as the primary tutorial document.

After you release a package, you will soon need to update it.

8.1. New Debian revision

Let’s say that a bug report was filed against your package as #654321 , and it describes a problem that you can solve. Here’s what you need to do to create a new Debian revision of the package:

• dquilt new bugname.patch to set the patch name;
• dquilt add buggy-file to declare the file to be modified;
• Correct the problem in the package source for the upstream bug;
• dquilt refresh to record it to bugname.patch ;
• dquilt header -e to add its description;

• dquilt pop foo.patch to recall the existing foo.patch ;
• Correct the problem in the old foo.patch ;
• dquilt refresh to update foo.patch ;
• dquilt header -e to update its description;
• while dquilt push; do dquilt refresh; done to apply all patches while removing fuzz ;

One tricky case can occur when you make a local package, to experiment with the packaging before uploading the normal version to the official archive, e.g., 1.0.1 — 1 . For smoother upgrades, it is a good idea to create a changelog entry with a version string such as 1.0.1 — 1~rc1 . You may unclutter changelog by consolidating such local change entries into a single entry for the official package. See Section 2.6, “Package name and version” for the order of version strings.

8.2. Inspection of the new upstream release

When preparing packages of a new upstream release for the Debian archive, you must check the new upstream release first.

Start by reading the upstream changelog , NEWS , and whatever other documentation they may have released with the new version.

You can then inspect changes between the old and new upstream sources as follows, watching out for anything suspicious:

$ diff -urN foo-oldversion foo-newversion 

Changes to some auto-generated files by Autotools such as missing , aclocal.m4 , config.guess , config.h.in , config.sub , configure , depcomp , install-sh , ltmain.sh , and Makefile.in may be ignored. You may delete them before running diff on the source for inspection.

8.3. New upstream release

If a package foo is properly packaged in the newer 3.0 (native) or 3.0 (quilt) formats, packaging a new upstream version is essentially moving the old debian directory to the new source. This can be done by running tar xvzf / path / to / foo _ oldversion .debian.tar.gz in the new extracted source. [78] Of course, you need to do some obvious chores:

• Create a copy of the upstream source as the foo_ newversion .orig.tar.gz file.
• Update the Debian changelog file with dch -v newversion — 1 .

• Add an entry with New upstream release .
• Describe concisely the changes in the new upstream release that fix reported bugs and close those bugs by adding Closes: # bug_number .
• Describe concisely the changes to the new upstream release by the maintainer that fix reported bugs and close those bugs by adding Closes: # bug_number .

If the patch/merge did not apply cleanly, inspect the situation (clues are left in .rej files).

• dquilt push -f to apply old patches while forcing rejects as baz .rej .
• Edit the baz file manually to bring about the intended effect of baz .rej .
• dquilt refresh to update the patch.

This process can be automated using the uupdate (1) command as follows:

$ apt-get source foo . dpkg-source: info: extracting foo in foo-oldversion dpkg-source: info: unpacking foo_oldversion.orig.tar.gz dpkg-source: info: applying foo_oldversion-1.debian.tar.gz $ ls -F foo-oldversion/ foo_oldversion-1.debian.tar.gz foo_oldversion-1.dsc foo_oldversion.orig.tar.gz $ wget http://example.org/foo/foo-newversion.tar.gz $ cd foo-oldversion $ uupdate -v newversion ../foo-newversion.tar.gz $ cd ../foo-newversion $ while dquilt push; do dquilt refresh; done $ dch . document changes made

If you set up a debian/watch file as described in Section 5.21, “ watch ”, you can skip the wget command. You simply run uscan (1) in the foo — oldversion directory instead of the uupdate command. This will automagically look for the updated source, download it, and run the uupdate command. [79]

8.4. Updating the packaging style

Updating the package style is not a required activity for the update of a package. However, doing so lets you use the full capabilities of the modern debhelper system and the 3.0 source format. [80]

• If you need to recreate deleted template files for any reason, you can run dh_make again in the same Debian package source tree with the —addmissing option. Then edit them appropriately.
• If the package has not been updated to use the debhelper v7+ dh syntax for the debian/rules file, update it to use dh . Update the debian/control file accordingly.
• If you want to update the rules file created with the Makefile inclusion mechanism of the Common Debian Build System ( cdbs ) to the dh syntax, see the following to understand its DEB_* configuration variables.

You should check DEP — Debian Enhancement Proposals and adopt ACCEPTED proposals.

You need to do the other tasks described in Section 8.3, “New upstream release”, too.

8.5. UTF-8 conversion

If upstream documents are encoded in old encoding schemes, converting them to UTF-8 is a good idea.

iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt 

LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \ -cols 70 -dump -no-graph -T text/html \ < foo_in.html > foo_out.txt 

8.6. Reminders for updating packages

Here are a few reminders for updating packages:

• Preserve old changelog entries (sounds obvious, but there have been cases of people typing dch when they should have typed dch -i .)
• Existing Debian changes need to be reevaluated; throw away stuff that upstream has incorporated (in one form or another) and remember to keep stuff that hasn’t been incorporated by upstream, unless there is a compelling reason not to.
• If any changes were made to the build system (hopefully you’d know from inspecting upstream changes) then update the debian/rules and debian/control build dependencies if necessary.
• Check the Debian Bug Tracking System (BTS) to see if someone has provided patches to bugs that are currently open.
• Check the contents of the .changes file to make sure you are uploading to the correct distribution, the proper bug closures are listed in the Closes field, the Maintainer and Changed-By fields match, the file is GPG-signed, etc.

[76] To get the date in the required format, use LANG=C date -R .

[77] If you use the dch -r command to make this last change, please make sure to save the changelog file explicitly by the editor.

[78] If a package foo is packaged in the old 1.0 format, this can be done by running zcat / path / to / foo _ oldversion .diff.gz|patch -p1 in the new extracted source, instead.

[79] If the uscan command downloads the updated source but it does not run the uupdate command, you should correct the debian/watch file to have debian uupdate at the end of the URL.

[80] If your sponsor or other maintainers object to updating the existing packaging style, don’t bother arguing. There are more important things to do.

[81] You can split big.diff into many small incremental patches using the splitdiff command.

Источник